So, the world needs another digital speedo project eh?

Not really, but the ones I can find either cost a fortune, have tiny unreadable displays, or both. Anyway where's the fun in buying something ready made?

Plus I have some requirements that don't appear to be met by current versions, so here's the general feature list.

BIG display, must be viewable in an instant without having to take my eye of the road for longer than absolutely necessary. To this end I'm using 2.3" 7-segment LEDs for the main display.

Trip meters. Must have six trip meters. Why so many? I find that I'd like to keep tabs on the following .

1. Distance since last oil change
2. Distance driven on left fuel tank.
3. Distance driven on right fuel tank.
4. Total distance travelled today or to be travelled to a given destination.
5. Distance travelled since lunch, morning tea, whatever.
6. Distance travelled since that sign that read "15k to rest area".

Hold trip meters. Any trip meter must be able to be held at the current value. This allows me to take a detour up a track without stuffing my daily reading, for example I know it's 345k to my destination today but I want to duck up a 13k road to have lunch at a waterfall. By holding trip meter #4 until I return to the main road I don't have to spend the rest of the day subtracting 26 from the daily reading.

Pulse source. Must be able to accept pulses from either the drive shaft or a wheel. I'll be using the drive shaft but just in case I decide to sell one it should be able to handle other options.

Wheel sizes and pulse frequencies

The most common method used to calculate speed when retrofitting to an older vehicle is to count the number of wheel revolutions and basically multiply that count by the wheel circumference.

Nothing wrong with that, but with large wheels and slow speeds it can take 10 seconds or more for the wheel to rotate and therefore to get a pulse, then if you want to average 5 or 10 readings to help reduce jitter obviously it will take 5-10 times as long to update the display.

My preference it to count pulses from the tailshaft however this can have the opposite problem of too many pulses at high speeds. The trick is to either find some middle ground, or dynamically change the counting method according to the speed.

Below is a graphic of my spreadsheet showing some of the combinations for my wheel size. If you're happy to download the real Excel spreadsheet feel free to do so.

So what are some of the issues?

Let's assume that we want to count the period between pulses in a nice time base like multiples of microseconds (uS) or milliseconds (mS) and we're using a 16-bit timer with a maximum count of 2^16 or 65,536.

At the extremely slow end of the above tables, counting in periods of 10uS we can see in the first red rectangle that the count at 1kph is 172,309 which is over twice the available count of 65k so we would have to trap and accumulate the overflows. No big deal but any resultant number won't fit into an integer which may be a pain when working in assembler but not in C.

At the other end of the scale, counting in mS and driving at 100kph we only get a count of 17 and given that all digital systems have jitter we may get 16 at one count then 18 for the next one. That's roughly a ±5% error so the display could bounce between 90 and 95 or even 100 when we haven't changed speed at all.

The highlighted rows are those I consider to be the best compromises for each of three scenarios, which is to say large truck-sized wheels and diff ratios of 7.22 (Wothahellizat), 3.5 (probably more normal), and 1 (sensor mounted on the wheel so the diff ratio is moot).

The top highlighted row is really the one I'm interested in because that features the numbers appropriate for my truck. So if I count 100uS periods I get a value of 17231 @ 1kph and 172 @ 100kph. The first number doesn't overflow the counter, and the second still has enough magnitude to reduce the affects of jitter to about ±0.57%.

There are many valid variations here, for example I could decide that I'm not interested in displaying speeds < 5kph, in which case I can move up one row and count 10uS periods for max/min values of 34462 and 1723, both of which are better numbers than the ones I've chosen. But I lose the very slow speeds and with my truck they will be useful.

I could also change the counting frequency at slow speeds or accumulate overflows at high speeds and I still may do that, but I'll see how the gadget works first.

Measuring rolling radius

To calibrate a speedo you can of course just drive for X distance and count the pulses, and I'll be doing that as well when in "calibration" mode, but meanwhile I need reasonably accurate figures.

To know how far a wheel has travelled in a single rotation you need to know it's "rolling circumference" and to calculate that you need the "rolling radius".

The rolling radius is not simply the radius of the tyre, it's the distance from the centre of the hub to the ground with weight on the tyre, as shown in the following diagram where the outer red circle depicts the radius of the tyre, but the grey circle shows the rolling radius.

Note that the tyre is flattened at the bottom so the rolling radius is measured from the hub centre to the ground. Note also that this distance will change with tyre pressure, load, temperature etc which probably explains why no speedo is dead accurate.