The Development of a Rally Computer

TSD RALLY COMPUTER PROJECT

To find out more about the wonderful world of TSD rallying, go to Rally Central, or www.tsdroadrally.com

In TSD rallying you need to have a very accurate method of measuring distance (ODOMETER), and you also need similar accurate method of measuring time (CLOCK). Then, given a specific speed (CAS), you can convert distance into time. Having done that, you can compare that calculated time to the actual time and determine whether and how much you are ahead or behind the proper time.

There are several rally computers available. I think that the best is the Alfa Elite made by Small Systems Specialists. I own one of these and it is great. If only I could think on my feet as fast as it does. It truly proves the principle of "garbage in, garbage out". Errors in making settings will result in big time errors.

For several reasons, mostly just for the fun of it, (see some of my reasons here), I decided to try to design my own rally computer.

Since I think that the Alfa Elite is the best TSD rally computer on the market, I decided to try to mimic its "look and feel". It is such a good rally computer, it would be very hard to improve on it (except for the one function discussed in my "reasons"). All I know about the innards of the Alfa is what the user manual tells me. It uses a Z-80CPU and is programmed in Z-80 assembly.

After some investigation of possible computer processor options, I settled on the Atmel AVR series of 8-bit RISC microcontrollers. These seem to have a good balance of speed and built-in functions. Additionally, they have a variety of sizes to meet the needs for almost any number of I/O pins and memory.

The Atmel ATMega128 has 128K program memory, 4K of SRAM, and 4K of EEPROM. It has 52 I/O pins which include 8 external interrupts, 8 analog-to-digital channels. It also offers hardware support for all sorts of interfacing to the external world such as UART, I2C, SPI, and others.

I concluded that this device probably has the power to do the job. I bought a development board and started developing. I decided to program in C. C code is easier to maintain and generates instructions that are almost as compact as ASM. I had once programmed PCs in ASM, but went to C rather quickly. I used that experience for this project. A completely free C compiler is available for the AVR ATMega family of microcontrollers, and it is powerful and very easy to use.

The Alfa uses 2 large LCD displays. I found similar looking displays by Optrex. Recently Optrex came out with super-high contrast versions of these displays. I used this type. All the rest of the stuff is routinely available from sources like Radio Shack, Digikey, and Jameco. [I will have a list of parts here]

I used a schematic and PCB layout program called EAGLE. It is freeware, and it very nice to use. After creating a handmade circuit board, I finalized the PCB design and sent the design to a PCB house to fabricate. A short time later I had the rally computer board plus a bunch of other little boards.

DETAILS OF THE SYSTEM

· 16MHz Atmel ATMega128 microcontroller, any smaller AVR would not be sufficient.

· 64-pin carrier for the CPU for simple upward expandability, though there seems no need right for more power right now

· Grayhill 12-ley keypad, though I am considering am ITT/C&K membrane keypad for future development

· Two Optrex high contrast 16x2 character displays (main unit and driver's display). Vacuum Fluorescent displayer are even better, but pricy.

· Dallas Semiconductor temperature-compensated precision real-time clock (accurate to 1min/yr)

· Ferro-electric non-volatile memory (FRAM) for all settings and current readings

· Special carrier for the RTC and FRAM for simple upgrades, though in the future this will probably be on the main board

· Power Trends 6101A high-efficiency power supply; a custom design could be used for slightly less money

· 100 entry user log (expandable to over 900 entries, which is probably overkill. A cheaper FRAM chip would probably be adequate!)

HOW IT WORKS

First, the computer gets its odometer signal from a Hall-effect sensor. This sensor's output goes low (technically it is "open drain"), when exposed to a strong south magnetic pole. This signal goes through a RC filter (filters out signals above about 65hz, which corresponds to about 130 mph when using 2 magnets on the axle, and this is able to be changed in the PCB hardware). This signal goes to a Schmitt Trigger inverter. The Schmitt Trigger creates hysteresis so that the inverter will not experience high frequency on-off switching (easily in the megahertz range) when the signal is in the gray zone between "low" and "high".

This signal goes to one of the external interrupts on the processor. In case you didn't know, "interrupts" are signals to a CPU causing it to pause its current task, and begin processing other programming. When that special interrupt routine is complete, the CPU will resume its paused task where it left off. The rally computer has several other signals which create interrupts: 1024hz clock, CAS change switch, driver's interval switch (and sensor-change switch, not currently implemented).

The CPU counts the number of sensor "ticks". You will have already set-up the conversion factor of "ticks-per-mile". You also will have set the CAS, so it knows "miles-per-hour", therefore it can convert the sensor ticks to computed hours/minutes/seconds (HMS). The computer will show you the true time (RTC), and the calculated time (CTC). If you are going too slow, then the CTC will be behind the RTC. The opposite will be true if you are going too fast. When you change the CAS, then the computer will convert the recorded number of sensor ticks to miles and add that to the cumulative odometer. It also adds the HMS of those ticks to the cumulative CTC. The computer also shows a variation of these data on the driver's display. That is all there is to it!

The rest of the problems are dealing with a reversed direction (for off-course situations), rolling over the days, mid-rally factor changes, and the like.

Initially, I used an internal timer for the real-time clock. It was easy to do because it was based on the 16MHz CPU clock. It was convenient because it could be divided down to create a true 1 millisecond clock tick. Unfortunately, the crystals used for the CPU clock are not all that accurate, and have significant temperature sensitivity. So, I discovered the Dallas Semiconductor DS3231 Precision Real-Time Clock. It is highly accurate, to about 1 minute per year, and it also can be configured to output a clock pulse. I used this pulse on the CPU to count time. Unfortunately, the DS3231 is designed to output a signal at a multiple of 1024Hz instead of 1000Hz. I guess it could be called "a binary millisecond". Therefore, I can not measure MILLISECONDS precisely. This is not a big problem, but it held me back from adding the ability to use "cents" (hundredths of a minute) as a time-keeping option until only recently. Now cents are completely supported. Some rallies use Hours, Minutes, Hundredths of a minute instead of Hours, Minutes, Seconds. Using cents is somewhat tough at first, but it makes the math SO easy if you work in decimal minutes entirely (no hours, no seconds). In the high-resolution time mode as implemented in the Alfa, I need to update the RTC (and the CTC, ODO) 1000 times a minute. In other words, the updates need to occur 60 milliseconds (literally faster than a speeding bullet). The high resolution display in seconds mode only updates every 100 milliseconds. [For you techies, I figure the bandwidth of the display in 4-bit mode is about 200,000 characters per second, including control data. Every 60 milliseconds there are 19 characters sent to the display, and probably about that number of control bytes. This makes 36 bytes every 60 milliseconds, or about 634 bytes per second. While it seems as if sending that much data that often is a lot, it is well below the bandwidth of the display.]

Also, initially, I used the CPU's on-board EEPROM to store settings. However, I wanted to also store all the current data (Odometer, CAS, sensor tick count, and others) every second so that in case of a power failure, only the last second is lost. However, EEPROM writes are ridiculously slow, and there is a 100,000 iteration write limit before the EEPROM "wears out". FRAM is a new non-volatile memory that is accessed the same way as EEPROM, but the writes are very fast, and there is effectively an infinite number of re-writes allowed. In 100 years of continuous use, the FRAM will not "wear out". Of course, both the FRAM and the RTC require extra hardware. Fortunately, they both can share the same communications bus, so the extra complexity is minimized.

I am considering producing this hardware in kit form. If you can solder the surface mount parts (not all that many of them) then you can make one of these. I am also considering producing them in a somewhat more complete form. But, as a totally complete unit, the Alfa Elite is actually a reasonably good deal. Small Systems Specialists is not going to get rich on these things! I just wish I knew where he got his enclosures and the front panels fabricated! I think that the Davies Molding 260K (with threaded inserts) enclosure is a decent size.

I also found Front Panel Express. They are able to fabricate really high quality front panels. Probably you would want to use Lexan or their standard "Perspex" (Lucite?) and have the engraved lettering done in mirror-image on the back. Then you will need to protect the LCD window and over-spray paint the back side with black. This ought to work very well. This would not be cheap, though!

I have gotten a sample of the Davies Molding 260-series box and it seems to be thoroughly acceptable. The size of the box is excellent as far as length and width go. The depth is ample without being excessive. I will proceed with fabrication of a front panel now that I have the exact specifications for the dimensions of the front panel.

I have just completed a site-by-side comparison of my design versus the Alfa Elite and found them to be in exact agreement regarding distance and calculated time when the calibration is set the same (note: my calibration is measured in ticks per mile, and the Alfa is based on miles per tick.)

What this means is that this software is now ready for actual usage. The interface reasonably mimics that of the Alfa, and the measurements exactly mimic the Alfa. One difference I did find is that it seems that my rally computer's power supply is somewhat more robust regarding voltage input than that of the Alfa. After many hours of running, the Alfa display occasionally glitched, probably representing a voltage issue whereas my design worked flawlessly. Another possibility is the input filtering is somewhat different. I do know that my input filtering is stronger than that of the Alfa causing an upper speed limit (currently) of approximately 130 mph with two magnets on an axle. A different filtering would be required if the sensor were placed on a drive shaft or if 4 magnets were utilized. The only change would be placing a smaller capacitor in the low-pass filter stage, an easy change to make when originally assembling the circuit board. It is somewhat less simple once the circuit board is entirely assembled, but still quite feasible. I may change the design so it has less of a low-pass filter and can be used for significantly higher frequency sensor ticks without any modifications. My original design used a fairly strong low-pass filter so give the best possible noise suppression. I was able to know this because I knew specifically what frequency of sensor ticks I was likely to be getting (2 ticks per tire rotation, about 60 Hertz at 120 MPH).

When the front panel is tested, I think that the project is now ready to be offered to the public as a kit requiring complete assembly, a kit with the circuit board assembled, or as a complete assembled unit. I have not determined the cost yet, but it would appear to be less than the cost of the Alfa system.

I have just layed-out the front panel design for a sign-maker to create a self-adhesive vinyl decal that could be placed on a plain Lexan sheet, probably at less cost than the Front Panel Express design, but not significantly less expensive.