Example of the power of the Propeller

Jim Fouch · 2006-10-12 04:05

As some of you may have known I've been working very hard for about a month or so to make a new project using the Propeller. This is not a finished product yet, but I was able to put about a 1,000 miles on it this last weekend·without any problems. I still need to tweak some of the readings. Actually slow it down a bit and average some of the readings.

Here is a link to a video demo...· www.fouchsoftware.com/seemeride/Samples/DigitalDisplay/DigitalDisplay.wmv

There is also some info on my we site at www.seemeride.com

This was alot of work. And I owe some thanks to people on this site for answering a few questions. I also owe a hugh thanks to Parallax for creating a great processor, and releasing the source code to some really great modules.

This has been a dream of mine for 10-15 years to put a computer on a motorcycle. The Propeller is the first processor to allow the power in a small enough package.

This is not all done with a single Propeller. There is another processor (I don't want to mention it here.) I plan my production unit to be 100% Parallax processor(s). Only the Speed, Tach & Water Tempeature are being read by the other processor.

Thanks,

Jim

Martin Hebel · 2006-10-12 04:13

Very impressive Jim! Blinker signals even [noparse]:)[/noparse] Very nice!
-Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control
AppBee - XBee ZigBee / IEEE 802.15.4 Adapters & Devices

cgracey · 2006-10-12 05:22

This is great!!!

This really uses the capabilities of the chip. Is there any limitation to bringing the tach, water temp, and speedo into the Propeller, too? Are you out of I/O pins yet? Out of cogs, or ram? Maybe a little assembly language object could get you over the hump.

Parallax needs lots of these kinds of aps to point people to so that they can get a picture of what they might achieve, themselves.

Way to go, Jim!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

parsko · 2006-10-12 06:28

Jim,

I must say, I am VERY impressed myself as well. I like how you laid out the screen, especially the tach. Have you anymore details on the hardware used? I ditto Chips questions regarding the resources you have used. Is your setup mostly SPIN code, or have you incorporated any assy routines?

Do tell sir!!!

-Parsko

Graham Stabler · 2006-10-12 09:34

It would be tempting to add a push button switch to flip between the display and a rear mounted CCD camera for easy "rear view mirror" action.

Graham

Jim Fouch · 2006-10-12 10:32

Thanks for all the kind comments.

So far all of my code is in Spin. I'm using 6 cogs... TV, Graphics, Valentine One, one to watch my Fuel injectors & Speed Pulses, one for·my DataPump (Serial) from the other processor. And one for my top program.

I have a DS1620 for my air temp & a DS1302 for my clock & Battery backed up ram (Odometer, Trip Odometer,·Fuel Injector Time used and any user settings)

My second processor has A/D and floating math that I want to bring into the propeller. I'm really looking forward to the new Prop Proto board.

I have about 4 Propeller pins left and about 5 of 16 left on the other processor. I think I can get the DS1620 & the DS1302 to share Data & Clock pins, but havent tried very hard yet.

I will have to say It was very cool to use this display on a recent trip. Just knowing that I haven't yet sratched the surface of what can be done with this type of setup. I still have ~1700 longs left over. I want to let the users download their own startup screens. Maybe include manufacture logos.

I started with the graphics demo as my base project. I soon found out that double buffering was not going to allow me to do what I wanted because I ran out of ram 1/2 way through the design. So I took the approach that I would not clear the screen every time. I keep track of the last value for every item being displayed, and only repaint the areas that have changed. It's alot more work, but I save 12288 bytes that way.

I have ~200 hours into this design so far and have a working prototype. Not too bad.. considering I'm not an EE.·

I've attached a picture of the first time I hooked it to the bike....

Graham Stabler · 2006-10-12 11:28

And what about a Memsic accelerometer for road incline, calibrated in percent. You could also show your bank angle and get a foot-peg down warning [noparse]:)[/noparse] That's two pins a and a cog.

I think you can pat yourself on the back.

Graham

parsko · 2006-10-12 11:33

Graham,

You forgot to mention the compass module!!!· It could use the same COG and pins!

http://www.parallax.com/detail.asp?product_id=29123

-Luke

Jim Fouch · 2006-10-12 11:50

I have used Memsic before on my video projects. If you check the sample videos on my site (www.seemeride.com) there is a G-Force on the video overlay. All options are open. I'm thinking a second Propeller is in order. Since the price drop, this is a good thing.

Lawson · 2006-10-12 18:38

dude! that's cool.
looks like your gear monitoring code is a bit jumpy.· I may have a bit of psudo code that'll help a bunch with that.· It's from a relay based position controller I wrote in a BS2. (god the BS2 is slow, I just bearly managed to get it to update the servo loop at 70hz with stall detection and RC servo pulse command input)

first off CASE is a godsent for this.

(note this is all in an infinitely repeating, paced scanning loop)
(ADCgear is what i'll use for the input variable, assumed 0-700, 100units each for N to 6th gear)
(be shure to initialise "gear" to some number 0-6 before you enter the scanning loop)

(read in the current value of ADCgear)
CASE gear
· 0
··· (do stuff for neutral here)
··· if ADCgear > 125 then gear := 1
· 1
··· (do stuff for gear 1 here)
··· if ADCgear < 75 then gear := 0
··· if ADCgear > 225 then gear :=2
· 2
··· (do stuff for gear 2 here)
··· if ADCgear < 175 then gear := 1
··· if ADCgear > 325 then gear := 3
· 3
··· (do stuff for gear 3 here)
··· if ADCgear < 275 then gear := 2
··· if ADCgear > 425 then gear := 4
· 4
··· (do stuff for gear 4 here)
··· if ADCgear < 375 then gear := 3
··· if ADCgear > 525 then gear := 5
· 5
··· (do stuff for gear 5 here)
··· if ADCgear < 475 then gear := 4
··· if ADCgear > 625 then gear := 6
· 6
··· (do stuff for gear 6 here)
··· if ADCgear < 575 then gear := 5

(now do other stuff and loop)

what a structure like this gives you.· First each gear now has a "schmitt-trigger" between all·gear changes. IE ADCgear has to go some amount over the gear to gear threashold before a shift up is dectected, and conversly ADCgear has to drop some ammount below the threashold before a down-shift is detected.· Second, using the CASE statement to impliment this state-machine makes the code fast and efficient. (i.e. only the code from the current state is executed each loop)· Third, this will give great noise rejection without time averaging or other things that slow down the system response.· Fourth? it's just darn easy to setup.· Fifth, multiple "state-machines" like this can coexist in a single loop as long as the don't try to use eachother's state variables. (aka easy "multiprocessing")

Good luck and happy coding!
Marty

Post Edited (Lawson) : 10/12/2006 6:46:44 PM GMT

Jim Fouch · 2006-10-13 01:59

Marty,

My code is similar to what you posted. I do need to slow it down a bit.

One of the problems is that I take the ratio from Tach Pulses & Speed Pulses and use that to calculate the gear. The issue is that when the clutch is in and the bike is coasting it will run through many gear ratios. I have code added that stops it from showing unlikley gears. Like 6th gear at 20 mph.

I need to average the speed, Temps and Voltage. They read way too fast now. I'm thinking of taking a rolling average of maybe 1 second.

I still need to do alot of tweaking. But there is almost no limit to what can be done.

thanks,

Jim

Oliver H. Bailey · 2006-10-13 02:06

Hi Jim,
200 Hours for a working prototype and your not an engineer. That makes a statement about both your skils and the ease of development with the propeller. Out of curiosity, how many support components (resistors, caps, etc.) have you had to use in your design.

Oliver

Jim Fouch · 2006-10-13 02:35

200 hours is my total investment. About 50 hours of that is in the fitting and trial & error stuff. I'd say I have about 100 hours in programming the Propeller. I can't say enough good things about this processor and even more about Parallax. This forum is also a great source for ideas and help.
I'm not sure how many parts I have on the prototype....LOL
I'm on the road now. But I have zenner diodes on most all the inputs from the bike to limit the voltage to safe levels. I also use 10K resisters to interface my other processor's 5V to the Props. I'm using a DS1620 & DS1302 for time & Temp. I'm using the other processor for A/D to read bikes Temp & do Pulse Width on the Speed and Tach Pulses.

I'd say all together I'm using another 35 or so resistors & diodes. A 5V regulator to power both processors. I'm also using a few Optos for the fuel watcher. I don't have that area 100% yet. But, the basic idea is to monitor the duel stage FI for open times of the injectors (I'm only watching one of the 4 cylinders). I will fill the tank up and reset a counter. Then I will accumulate the open time of the injectors. Once I have driven ~100 miles or so (~75% of a tank) I will note the value of the FI Accumulator, and the amount of fuel required to fill the tank back up. This will give me a constant fuel/time unit to caculate the FULL tank. Once the user resets the fuel tank. I will start with that FULL tank Accumulator and count down to an Empty tank. This should be pretty accurate. I'll have to see. This is where the Propeller is so awsome...You simily write another cog to watch the FI pulses. I think that only took me like 15 minutes to write the code.

''*****************************
''*        Fuel Watcher       *
''*  (C) 2006 Fouch Software  *
''*****************************
'' This Object is designed to watch both the Fuel Injectors (Primary & Secondary) and Speed Pulses
Var
  Long Stack[noparse][[/noparse]60]       
  byte cog
  Byte  Temp[noparse][[/noparse]11] 
    
CON
OBJ
  
Pub Start(PrimaryPin,SecondaryPin,SpeedPin,GlobalPointer): Success | i
  Stop
  Success := (Cog := CogNew(Run(PrimaryPin,SecondaryPin,SpeedPin,GlobalPointer), @Stack) + 1)
Pub Stop
  if cog
    CogStop(Cog~ - 1)
Pub Run(PrimaryPin,SecondaryPin,SpeedPin,GlobalPointer)|Count, OldState  
  
  ' Make All Pins Inputs
  DirA[noparse][[/noparse]PrimaryPin]~
  DirA[noparse][[/noparse]SecondaryPin]~
  DirA[noparse][[/noparse]SpeedPin]~
  
  OldState:=INA[noparse][[/noparse]SpeedPin] 
  Repeat
    Count := Count + (INA[noparse][[/noparse]PrimaryPin])
    Count := Count + (INA[noparse][[/noparse]SecondaryPin])
    
    If Count=>1000
      Long[noparse][[/noparse]GlobalPointer] := Long[noparse][[/noparse]GlobalPointer] + 1 ' Pass up the Units
      Count:=0
    If INA[noparse][[/noparse]SpeedPin]<>OldState
      OldState:=INA[noparse][[/noparse]SpeedPin]
      Long[noparse][[/noparse]GlobalPointer+4] := Long[noparse][[/noparse]GlobalPointer+4] + 1 ' Incrment the Odometer
      Long[noparse][[/noparse]GlobalPointer+8] := Long[noparse][[/noparse]GlobalPointer+8] + 1 ' Increment the TripAOdometer
      Long[noparse][[/noparse]GlobalPointer+12] := Long[noparse][[/noparse]GlobalPointer+12] + 1 ' Increment the TripBOdometer

The LCD TV is powered straight from the bikes 13.8V system. Right now I'm using a TV I salvaged from some surplus 5" G2G video game TV's I got from Tiger Direct a while ago. They are nice in the fact that all the circuits needed fit into a nice 5" square. If anyone knows where I can source a decent LCD with composite in for ~$50-$100 I'd love to know. This unit has on screen controls for Color & Brightness.
I'm having problems with the neutral input from the bike. There is a stearing diode in the bike that is used to keep the bike from starting if it's not in neutral before you start. This causes the low to be ~1.1 volts. I tried to pull it high and I could not ever get a low. A friend of mine helped me by making a circuit that would pull it low also. We were able to get a low of ~.65V and a high of ~2.6V. This is when the bike is running ~12-14 Volts. But when I turn on the bike w/o the motor running I'm only @ ~10-11V and the high is not high enough. I'm almost ready to give up and just read it with an A/D port and be done with it.· ;-)

Lawson · 2006-10-13 16:51

The neutral-input that you are sensing.· Do you have to pull it high? or is it a signal that swings from ~1.1v to 12v? (or whatever the batery is at right now)·· If the neutral-input nautrally pulls itself up, simply adding a diode followed by a pull-down resistor will drop the LOW signal down to a usable level.· If it needs a pull-up resistor, I'd use a comparator (or op-amp, or CMOS logic at 12v, or a transistor inverter, or....) to read the voltage.· (with an appropriate resistor bridge to set the HI/LO transition voltage)

hm... sensing gears using the wheel speed and engine tach.· Do you have any way of telling when the clutch lever is being pulled?· Because that would make it easy to freeze the gear estimator when the bike was coasting.· I had assumed that the motorcycle had some kind of·sensor in the transmission that dectected·what gear it was in·

·opps!··If·Tach/Speed·is really stable over a wide speed range for each gear then the gear estimate jitter could be reduced by only changing the displayed gear when Tach/Speed was really close to the ideal Tach/Speed value for the new gear.· If the decision to change gear is then required to happen·"n" concecutive times by code before the display is actually changed I think that a stable gear display could be acheved.· (yech! running 7 accumulators that decrement to a min limit when not in a gear, and incriment to a max limit when·in a gear is·just going to be·some ugly code.)

The Fuel watcher looks like a slick piece of code.··BUT how·fast is the loop executing?··Right now there is no pacing section in the scanning loop so the unit conversion from the acumulator to time·will change every time the code is changed in the scanning loop.· A WAITCNT statement should be added at the start or end of the scanning loop to make the loop execution time independent (within limits) of the code in the scanning loop.· This may be a really good·application for·the COGs two timers.· They can be setup to only count up·(or down)·when a pin is·HIGH (or·LOW)·and would provide a massive boost in precision.· Again though, the code that reads off the value of each timer and clears the timers would have to run at a consistent time interval (ie use WAITCNT for pacing) to avoid the need to re-calibrate the fuel watcher with every code change.·

My to cents,
Marty

Jim Fouch · 2006-11-08 02:29

Incase anyone is interested I posted some new video of the Bike Display. This one shows it in action while the bike is actually being driven. It's the video clip on the right is the new one. http://www.seemeride.com

I still need to average the Speed/Battery Voltage/Air Temp. Some of my problem is the ADC on the second chip is using the VDD as a reference. I'm in the process of interfacing to a MCP3304 8 channel ADC. Anyone done this yet with the Propeller?

Bill Sturm · 2006-12-24 03:57

If you are still looking for a supply of LCD displays, try EarthLCD. They stock large qtys of surplus LCD screens.

El Paisa · 2006-12-24 13:30

Take a look at Earthlcd.com, ezLCD-004 v2.9

6 inches size, 320x240 resolution, 16 bit color palette, 1 MB eeprom for graphics/bmps, SD card reader, touch screen, USB/RS-232/IC2 inputs.

·

Example of the power of the Propeller

Comments