Odometer, other data, and OLED display

[86atc250r]

Hello all,

I've got one simple picaxe project under my belt (stepper drive for washing machine timer replacement) - time to learn a little more and do something a bit more interesting.

I have an older customized car that has been outfitted with a modern engine. I've taken the original speedometer and replaced it's old mechanical cable driven drive with a modern stepper drive from a Lexus that accepts a 5v pulse signal from the on board computer.

The above rendered the old mechanical odometer inoperable. My plan is to get a 4D systems OLED display and mount it at the bottom of the speedometer to display various data. The plan is to have an odometer, trip meter, maybe digital speed readout, possibly other sensor data, as well as turn & bright lights indicator icons (because the originals are difficult to see when the wheel is tilted to driving position) --- I also am planning on a selectable display (and trip reset) via momentary pushbutton switch.

The speedometer signal is a 5v square wave that at 150mph (240kph) pulses at a frequency of about 200hz - I'm figuring this will be my upper boundary.

Displaying various data on the OLED seems pretty straight forward, as does gathering most of the information (ADC for various sensors, digital input for turn and bright indicators).

The question I have is, what would be a good strategy for the odometer?

The signal feeding the speedo is 4531 pulses per mile. I'm almost thinking a dedicated controller or chip of some sort would be best suited to collecting these pulses and recording them as miles.

Anyone have any thoughts? Is a picaxe suited to this task or is there a better option for the odometer/pulse counting portion? Should I be looking at a single or two chip solution? I'm planning on using a 20X2 picaxe as my main interface to the OLED.

 

[hippy]

Welcome to the PICAXE forum.

At 120mph, that's 150 pulses per second, a pulse every 6ms, so a single PICAXE should be able to handle the odometer, a 20X2 maybe could handle all of it. The real issue comes in getting data out to display; as that may take time you cannot be doing other things. A dual-PICAXE system may be a good idea, one accumulating data and passing it on, the other taking latest data and more leisurely updating the display.

 

[krypton_john]

The display might only need to be updated say, twice a second, which should allow plenty of time to sample all the data in between updates?

 

[retepsnikrep]

I have a speedo and odometer on my project which has a similiar vehicle speed pulse frequency to yours.

My speedo code is here

CheckSpeed:					;Pulsin measures VSS pulse. If no pulse result will be 0 

	pulsin SpeedSensor,1,VarB		;Measure length of a VSS pulse in 5us (8mhz) units (Timeout 0.32768s)
	if VarB = 0 then JumpSpeed		;If VarB = 0 pulsin has timed out and vehicle is moving at < 1.5mph
	VarB = VarB / 11			;Divide VarB by 11 to enable results to fit into 16 bit Integer Maths
	VarB = 7908 / VarB + 1			;Returns speed in mph accurate to 1 mph Approx!

JumpSpeed:					;Jump here to avoid calculation errors

`Display Speed

	serout Video,Baud9600,(27,83,0,6,"Mph ",#VarB,"   ")	;Video Display

I can't remember how many pulses per mile mine was, but it was around 4000, which works out at about 66hz at 60mph. I'm sure you can fiddle with the figures to get the right speed.

 

[86atc250r]

Thanks for all the timely responses!

Yes, I think a 500ms display update time would be quite sufficient.

retepsnikrep - the original PPM was 4000 for this engine/transmission combo as well. Between using a stepper/speedo driver from a different vehicle manufacturer, and grafting it to the scale of my old speedometer, I was surprised to find that the PPM figure was as close to 4000 as it was.

Luckily, my engine control software allows me to adjust the speedo output independently of what the engine control module uses for it's internal calculations (which is 4000 PPM).

Anyhow

The three most pressing issues in my mind right now are related to the odometer function.

First - methods on accurately tracking mileage. At first I was thinking direct counting of the pulses, but would measuring pulsewidth every x milliseconds, then figuring the average distance traveled between samples be an "as accurate" method using far less resources?

Second - strategy for saving the mileage for the odo and tripmeter through a power down.

As for saving the mileage - from what I understand, I will need to build a circuit that holds enough charge to properly power down the OLED after the ignition has been turned off, at this point I could store the value in non-volatile memory and minimize the number of writes.

Thirdly - dealing with 32bit numbers - I've found Jeremy Leach's math library, still trying to figure out how to use it.

 

[BeanieBots]

First - methods on accurately tracking mileage. At first I was thinking direct counting of the pulses, but would measuring pulsewidth every x milliseconds, then figuring the average distance traveled between samples be an "as accurate" method using far less resources?

Absolutely NOT.
Counting pulses will be the most accurate.
Measuring the pulsewidth introduces errors of time. Doing it every X milliseconds introduces more timing errors AND quatising errors. Calculating, with limited resources could produce rounding/quantising errors. Calculating an average will introduce even more errors.

With any form of measurement in any application, it is always better to work with the raw data and units of measurement. Whenever anything is converted or has extra elements added in, unnessesary errors will be introduced. This is an absolute fundamental of any datalogging.

My suggestion would be to use the pulses to trigger an interrupt and thus keep a direct tally of distance measured and stored as a count of those pulses.

To keep a non volatile record, you will need to detect power supply drop and as you say, have enough energy stored to then make a write to EEPROM.
As this is destined for use in a car, you will need sufficient reservoir energy to cope with brown-outs (eg engine cranking for several seconds) anyway, so that should not require any additional circuitry above the existing supply design except perhaps a means of detecting power fail which could be a simple ADC input from the power input diode.

 

[hippy]

At first I was thinking direct counting of the pulses

That's what I'd do. Count pulses, then every 4531 pulses increment a mile counter and reset the pulse counter, tenths of miles will be the pulse counter divided by 453 ...

GotPulse:
pulseCount = pulseCount+1
If pulseCount >= 4531 Then
miles = miles + 1
pulseCount = pulseCount - 4531
End If
tenthsOfMile = pulseCount / 453
SerTxd( "Odometer = ", #miles, "." , #tenthsOfMile )

 

[86atc250r]

Would direct pulse counting be something better suited to a dedicated picaxe, something like an 08M - or would the 20X2 be able to handle this as well as the other duties (sampling of other data & outputting to display).

If a second chip was used, what would be the preferred communications between the two -- serial?

I'll be ordering various picaxen very soon, so implementing a two pixaxe design will not be a big deal if it will give me more flexability and power.

In fact, if I do two of them, would I be better suited to have a small unit like an 08M drive the display and the more powerful unit like the 20X2 gather & process the data?

 

[86atc250r]

That's what I'd do. Count pulses, then every 4531 pulses increment a mile counter and reset the pulse counter, tenths of miles will be the pulse counter divided by 453 ...

GotPulse:
pulseCount = pulseCount+1
If pulseCount >= 4531 Then
miles = miles + 1
pulseCount = pulseCount - 4531
End If
tenthsOfMile = pulseCount / 453
SerTxd( "Odometer = ", #miles, "." , #tenthsOfMile )

Excellent! Thanks for the detailed example. I love the simplicity.

Fact is, I probably don't really need to worry about 32 bit math in this application. The chances of me going over 60K miles in this car anytime in the near future are slim... I suppose if the time came, it's just a matter of reprogramming or resetting.

 

[MPep]

In fact pulse counting is a very common technique.
On ships, they use a Log (which can either use a spinning wheel through the water or a Doppler Log).
The logs generally output 200 pulses per nautical mile. Some are 400PPNM
Of course they can also use GPS, but for recording into the Voyage Data Recorder (VDR), they tend to use 200PPNM.
A VDR is basically like a Flight Recorder.

 

[retepsnikrep]

The reason I didn't use the 'Count' command is that it ties up the chip in the 'COUNT' command for the relevant period, the 'PULSIN' command only ties up the chip for the duration of the pulse which allowed me to carry on processing. I agree 'Count' would be better if you can spare the processing time. A dedicated 08M counting pulses and forwarding data to another chip is a good idea.

 

[hippy]

Going over 65,535 isn't really a problem when counting; just keep track of miles and thousands of miles. Whenever miles hits 1000, rest that, increment the thousand's of mile count. It then comes down to just getting the display right.

This variant will count tens of thousands of miles and miles ...

miles = miles+1
If miles >= 10000 then
tenThousandMiles = tenThousandMiles+1
miles = 0
End If
BinToAscii miles, b1,b2,b3,b4,b5
SerTxd( #tenThousandmiles, b2, b3, b4, b5, ".", #tenthsOfMile )

It will howevr fail after 655,359,999.9 miles ;-)

 

[86atc250r]

Well, that should cover me for a while then!

I need to get in the mindset of working out clever solutions for the limitations

Thanks again - I'll be ordering parts today!