Once you know what you are doing, it is not that hard to properly use the computer. Nevertheless, it can be a harsh mistress.

After using the computer for a while, I realized that there is a problem with the computer. It is TOO ACCURATE! It probably is more accurate than the math used by the rallymaster in calculating the "correct" times. This is because the rallymaster takes an odometer reading at each CAS change point. He probably uses a rally computer for these measurements. These computers generally truncate the display at 2 or 3 decimal places. If the rally master used 3 decimal places for the math, then the time errors that are created by the truncation are minimal.

More often, however, the rallymaster truncates the odometer to 2 decimal places. This means that every actual (geographical) CAS change point is on average ½ of a one-hundredth of a mile more than the distance used in the calculations. This means that the actual distance you need to drive is on average 26.4 feet greater than the rallymaster calculated. At a CAS of 30mph, you have to drive an extra 0.6 seconds to cover that distance that the rallymaster failed to account for. Therefore on average, for each CAS change (when the rallymaster uses 1/100th truncated odometer readings) you are behind by 0.6 seconds. If there are 15 CAS changes in a leg, then you will be slow by 9 seconds!! And you thought you were exactly on time!!

Even if the rallymaster uses odometer measurements truncated to 1/1000th, you will still be slow by 0.9 seconds.

On an Alfa Elite, it is possible to correct for this by changing the CAS on the computer at the last even 1/100th of a mile within the last 52.8 feet, then HOLDing the display at the geographical CAS change point. Look at the distance you covered after the cas change point, and subtract a DT of that amount. This will subtract the distance and the corresponding time at the current CAS. The problem is that the Alfa only does a DT based on the current CAS, and you need to do a DT based on the previous CAS, unless you make your CAS change at the odometer-based location, not at the geographical location

Well, my eye and hands are not good enough to accurately estimate the last 52.8 fee t, and hit the CAS change at exactly a round 1/100th of a mile on the odometer.

An alternative technique, which is easier and on average works OK, is to subtract a DT of 0.005 miles some time soon after a CAS change. This simply corrects the average error. It will rarely be exactly right, but it is better than nothing, and it is easy.

BUT… since you have a computer with microsecond reflexes, it is quite possible to have the computer make the proper DT corrections for you. You simply make the CAS change at the geographical change point as you usually would do. Then the computer will look at the odometer at the time of the change, and subtract the fraction of a mile beyond an even 1/100th. It will then subtract time based on the PREVIOUS CAS! Your time error is correctly as perfectly as it is possible to do.

I had briefly discussed this issue with Mike (the proprietor of Small Systems), and he was aware of the problem. His navigator is good enough to do an accurate DT correction by eye. Therefore it was never a high priority for him.

At this point I stopped consideration of this problem until such a time as he released an update of the software.

A year or two passed, and I ran across a BX-24 microcontroller. My eyes were opened about the power of modern microcontrollers. I realized that this device might be powerful enough to actually be the guts of a rally computer. I wrote some initial code and soon realized that the device just did not have enough I/O pins, nor enough external interrupts to do the job without substantial amounts of external hardware. Also, it had rather limited amounts of program and data memory. There is now a family of ZX microcontrollers (www.zbasic.net) that offer much more power than the BX family.  Unfortunately, even these are not quite enough for this job.  Close, but not quite enough without a lot of extra support hardware.  I am not sure that these high-level devices are fast enough either.  Again, close, but probably not fast enough.

The hardware on which the ZX family is based IS fast enough, and some of the devices are big enough too!