On-Track

My Homemade Data Acquisition System, circa 2001

Originally, I conceived my DA system (which I called On-Track) more as a tool for rider development than as a tool for vehicle development.  However, because of my involvement with the Tul-aris project, in which DA was used almost exclusively for vehicle development, I began to see the usefulness as more of a 50/50 split.

The only commercial use I ever envisioned for my system was at racing schools.  For example, the instructor would have a DA system fitted to his bike and follow the student around.  Afterwords, you could overlay graphs of the student's laps along with the instructor's laps when he was circulating at his own “race pace.”  Very enlightening.  However, when commercial GPS data loggers became dirt cheap, it made more sense to rent a system that could simply be “duct taped” to the student's bike for an entire day of instruction.

Analysis Software

All my analysis software was written in Turbo C under DOS.  Although it was relatively easy for me to build hardware and write firmware, the analysis software was much more time-consuming.  It was readily apparent that my software was very crude in comparison to commercial Windows programs even in the early 2000s.  For example, I displayed everything on a 640 × 480 pixel screen.  I would literally take digital photos of a CRT computer screen to have a permanent record of graphs.  One photo below shows an early experiment with my GPS track mapper.

Because I used a “distance base” rather than a “time base”, all inputs were sampled every time the front wheel made one complete revolution (about every 6 feet).  This lent itself to efficient data storage as events are automatically sampled more frequently at higher speeds. 

A distance base also permits you to easily overlay the data from one lap on top of another (as the track is always reasonably close to the same length, but lap times can vary considerably.)  I say “reasonably close” because the path taken (line) around the track obviously somewhat affects the length of the track.  Perhaps counter-intuitively, faster riders tend to make the track longer than the same track for a slower rider.  

The downside to using a distance base rather than time base is when measuring things like suspension travel.  At slow road speeds, the suspension can move fast enough that the data is “aliased,” that is, not sampled frequently enough to give an accurate depiction of what is happening.

The photo below shows MPH graphed against track position (front wheel revolutions).  Thus, a conceptual map of the track emerges - peaks are straightaways, and troughs are the corners.  You can count peaks and troughs from the lap marker beacon to determine speed anywhere on the track.  

By having two moveable cursors on the MPH (road speed) graph, it was easy to compute deceleration and (acceleration too) over any chosen interval.  I found it is most convenient to scale this result in terms of gravitational acceleration.  Thus, a typical acceleration might be 0.5 g.  In the early 2000s, world-glass GP racers could decelerate at average rates of over 1.0 g (1.2 g peaks).  For amateurs, an average deceleration of anything over about 0.8 g requires a great deal of concentration.

Hardware

The photo below shows the four data acquisition boxes I built.  Three were actively used on bikes and a fourth was rotated in/out of the lab for development.  The basic box was very general-purpose and could deal with three specific type of data: analog voltages, digital levels, and timestamps.  I then fabricated small ancillary boxes for specific signal conditioning tasks, like thermocouple amplifiers, 2T and 4T ignition coil isolation, and a wideband oxygen sensor interface. 

For example, my thermocouple amplifiers had a gain of -100.  The minus sign means the voltage is inverted.  This was done because inverting amplifiers are “better” than non-inverting amplifiers and by simply connecting the thermocouple “backwards”, everything works out properly.

An RJ45 connector permitted serial data transfer to the computer and flash programming of the uC.  A DB-37 connector provided inputs and power to the logger.  There were two LEDs for user feedback to verify operation.  The one marked FW flashed every time the front wheel made a revolution.  Likewise, the LED marked RPM flashed every time an ignition spark was detected.   

The system was based around a Mitsubishi M16C microcontroller running at 16 MHz.  This was a very sophisticate microcontroller (some called it a computer-on-a-chip) in the early 2000s.  However, it was also quite inexpensive because Apple used it in huge quantities.  The microcontroller's program memory is reprogrammable in circuit.  That means I could download new firmware, as needed, very easily.  That's a feature we take for granted today, but it was not the case in the early 2000s.

The acquired data was stored in a 512 kB static memory.  This was sufficient to hold 30 to 40 miles' of collected data.  Once collected, the data was downloaded into a PC via the computer's serial port at 115200 baud.  It could take several minutes to get the data out of the DA unit into the PC.  The USB flash drive was still years away.

The stored data came in three varieties:

1. TIMESTAMP  This was a count of the number of 2-microsecond “ticks”.   Time data was used to keep track of things like wheel speed, engine RPM, and lap times. 

2. ANALOG  Voltages were quantized with 10-bit resolution (1 part in 1024).  Analog data is used to track things like throttle position and EGT.  I only stored 8-bits of data (1 part in 256), however intended to eventually store all 10 bits.  8-bit data was accurate enough for most measurements, but I could only resolve thermocouples to about 8 degrees F.   With 10-bit data, the resolution would have been 2 °F. 

3. DIGITAL  An “on” or “off” state.  Digital inputs were used to sample things like when the lap marker beacon is encountered.  Since I needed a place to store the lap marker's digital input, I decided to use the remaining bits in that byte to store other things as well.  They are listed below:

• Lap Marker

• Front Brake Applied

• Rear Brake Applied

• User Marker (horn button)

• Gear Change Up

• Gear Change Down

• Clutch Disengaged

• Debugging (microcontroller reset)

Unfortunately, most of the digital items did not prove very useful.  The same information could almost always be acquired via other means.  The sole exception I found was to use a digital input to observe activation of a TZ250 power jet solenoid – but that could have been done with an analog channel as well.

Homemade TPS

Getting throttle position data from a fuel-injected vehicle is trivial because a TPS is already part of the system.  It's then a simple matter to tap into the vehicle's wiring harness and pick off voltage from the potentiometer's movable contact.  Even a few carbureted motorcycles have a TPS as part of their ignition system.  However, most carburetors do not have a TPS, and you are forced to get creative.  Mechanical cables pulling on linear or rotary potentiometer immediately come to mind, but are somewhat cumbersome.   

The approach I show below is reasonably straightforward.  It's very light and mostly contained inside the handlebar.  The downside is that it's unlikely to survive a right-side crash.  Fortunately, I never had to test its crashworthiness. 

The 5k ohm potentiometer I used in 2002 was manufactured by ETI Systems in California.  It appears they are still being made by a Canadian company called Precision Electronics Corporation.  Their part number is RV6NAYSD502A. 

The potentiometer fit inside a steel sleeve which was held in the handlebar by 3 setscrews, located 120 degrees apart.  An aluminum “knob” attached to the throttle tube using silicone sealer, and a long setscrew contacts the potentiometer's shaft. (If you are outside the USA and wonder what a setscrew is, think grub screw.)