Scary Cabin

Back in the late 80’s and early 90’s the Sacramento TSD rally scene was quite active. There were multiple rally clubs and typically at least one rally a month (The Friday Night Rally Series) along with various weekend rallies. Some of the folks involved were also involved at the national SCCA level. They typically used a “rally computer” to accurately track their distance and compute how close they ran to the ‘perfect’ time.

One bright fall Saturday, my rally partner, Jim and I ran a tour type T&D rally from Sacramento to Reno. Official mileages were given for every RI so it was possible to do manual calculations without the need for odometer correction calculations. We decided to try this armed with only a 4-function calculator, a pen and a pad of paper. This kept Jim very busy for most of the day and he didn’t get to see much of the scenery. After it was over, me being a software engineer, thought, “It would be pretty simple to write a computer program to handle all the calculations”. And thus, The Rally Computer program was born. I had a Zenith Supersport laptop computer that I had won in a raffel and it wasn’t being used for anything else so that made a perfect test machine. This was an 8088 based machine with 640K of memory, a floppy disk drive (3.5”!), a B&W LCD display, and a very large battery pack.

I started by writing some routines to handle time manipulations. I needed routines that could subtract and add two time values, convert a time (HH:MM:SS) to number of seconds, and convert a number of seconds to a time value. Delving into the Microsoft C documentation, I found a routine, _dos_gettime (), that would read the current time from the operating system and return it in a time structure. The time structure held hours, minutes, seconds, and hundredths of seconds. Perfect! I wrote all of the time functions to use the time structure.

The first version of the program would prompt for the mileage at the end of the odometer check. It would compare the official mileage with the stock odometer reading and calculate the correction factor. It would then ask for the out time. For the rest of the leg, it would prompt for a speed and a stock odometer reading and calculate the perfect time to that point. It would also mark the time-of-day when the ‘’ key was pressed and compare that time with the perfect calculated time and display the difference as an early/late number of seconds. By entering this information for each speed change, we would know how far off we were at that point. This worked OK but we soon found out that it was definitely not perfect. If we made any errors, either in entry or by going off course, there was no way to correct them. After almost every rally we would find something that didn’t work quite right or if changed, would make it easier to use. After almost 2 years of adding features, making changes, and redesigning it is finally to the point were we felt it was competitive with commercial rally computers.

So far all I’ve talked about is the software. After a while it became apparent that reading and interpolating the stock odometer and then entering that into the computer was a major cause of errors. The next step was to add some hardware that could sense the number of wheel rotations and calculate the mileage. This would eliminate errors caused by miss-reading the odometer and by typo’s while entering it. It would also free up the navigator as trying to type all those numbers while bouncing around could be a trying experience. We investigated various methods of getting data into the computer. Making the computer count pulses would take too much of the processors time and we didn’t think it would be able to keep up. The Zenith doesn’t have any card slots so a simple I/O board was out of the question. We decided to build an intelligent electronic odometer and interface it to the computer with an RS-232 interface. The next step was to come up with a way to count wheel revolutions. I had a speedometer/odometer for my bike that used a magnet on the wheel and a reed switch to generate pulses. We decided to try and connect a $35 bicycle speedometer/odometer (CatEye) to the car. We mounted the reed switch on the top of the back brake caliper. There was a bolt holding a heat shield that worked perfectly. We then glued a magnet to the inside of the wheel and once it was aligned, spinning the wheel did cause it to pulse. We then ran the wire up to front seat and connected it to the display module. The CatEye is capable of working with a wheel diameter from 20 to 28 inches and my car tires were about 23 inches. It actually worked, we were able to read distance down to 1/100th of mile and speed, at least we could until we exceeded the units speed limitation. If we went over 60 MPH the unit would stop reading correctly. Of course, why would we ever want to go over 60 MPH on a rally? After more testing we determined that the problem was in the CatEye display unit and not in the switch sensor. It was time to build the odometer. We did some preliminary designs using an 87C51FB micro-controller, a couple of binary counters, and a display unit. Everything looked good but it would be expensive and complicated to build. I poured through the Zenith hardware reference manual looking for a simple way to do byte size I/O. The printer port looked promising. It had a 1 byte output port and 6 input bits. After experimenting with it I found I could transfer 8 bits out and 5 bits in. Maybe we could do something with this after all. I told Jim I would need a 20 bit binary counter with latchable outputs. He said, no problem, we can put that on a single EPLD chip. So he did. We have a 68 lead PLCC chip with a 20 bit counter, latched and multiplexed outputs. The counters clock is tied to the reed switch so that every pulse increments the count by one. By setting the latch line high and setting a 3 bit value to the bank we want, we can read all 20 bits, 4 bits at a time using simple I/O calls on the computer. We had our odometer.

At some point, the big Zenith laptop was replaced with a smaller, lighter 80386 based notebook which we used until the rallying scene mostly died out in the Sacramento region . We used this not only to run rallies, but to help with the creation of rallies. Since we could log everything, it was easy to pre-run a rally and log the perfect times for each instruction and leg.

Around 2002 I started to revive the software. As computers were getting more powerful, it seemed like it should be possible to eliminate the counter hardware and just count the pulses with the computer. I did some experiments using the parallel port interrupt line and a simple Linux kernel module around 2003 but never finished it into a working version.

In 2007 I acquired an Intel Poulsbo based tablet. This had a 800×480 display and could run Linux. I thought this might make a good rally computer. At the time, my wife and I were creating rally events for the local Miata club so I thought getting The Rally Computer working again might help with those. The two challenges were how to count the pulses and updating the code to work with the GUI based touchscreen. Since I wanted to do this in Linux, GTK+ / Glade make the most sense for the GUI. I created a layout and ported over some of the basic functionality. Since the tablet doesn’t have a parallel port, would a USB parallel port adapter work? What about a USB mouse button? I did some tests where I wired up the mouse button to the hall effect speedometer sensor and had mixed results. The pulse counting was a bit flaky. Life took over and I never did debug the problems.

Fast forward to 2016. Computers and cars have progressed quite a bit. Small hobbyist computer boards with multiple I/O’s, good displays, Wi-Fi, and Bluetooth are available cheap. For $40 or less you can get a Raspberry Pi that’s many times more powerful than the Zenith Super Sport of 1988. Cars all have various speed sensors that are used for traction control and ABS brakes. All it took was one trigger to start the thought process of what it would take to bring The Rally Computer into the 21st century.

It didn’t take long to finish up most of the software conversion to GTK+ but the real challenge is still getting accurate distance data. A RPI has multiple GPIO pins and those could be used to implement a pulse counter in a Linux kernel module without too much effort. The source for the pulses could be one of the car’s VSS sensor leads but that would involve cutting and tapping a wire the ECU. A less invasive approach would be to go back to the original reed switch and epoxied magnets. Both of these solution will only work with the specific car that has the modifications. Is it possible to access the VSS signal from the OBD2 connector that’s been mandated since 1996? Time to experiment. ELM327 based OBD2 dongles are dirt cheap, like less than $10. There are numerous examples of connecting one to a RPI via Bluetooth or USB on the web. The ELM327 datasheet is available and describes how to communicate with it in great detail. Sounds like a plan.

With a bit coding to create an test application that connects to the ELM327 and pulls various sensor data, we’re ready to experiment. It looks like the VSS signal is not available, at least not through the standard PID’s. But the vehicle speed (in kph) is available. Tracking the vehicle speed over a very short period of time can provide distance data. But is the speed data accurate enough and can the ECU be queried quick enough to make this a practical plug-n-play solution? The test application has been able to pull speed data at approximately once every .6 seconds. The speed data is in integer kph and ranges between 0 and 255kph (0 -159mph).

The next step will be hook up the GUI app to the ELM327 and run some real-world tests to see how it behaves when the vehicle is driven normally. To do this, the RPI will need some type of local display and input. There’s a nice 800×480 7” touch screen display available for $65 that seems perfect for the job.

If this works, it will be nice plug-n-play solution that should work with almost any vehicle 1996 or newer and it can all be powered from a USB port in the car. Total cost:

RPI model 3 - $40
7” display - $65
ELM327 - $10
Total = $115