One of the primary difficulties involved with developing an autocross car is the relative lack of track time. Unlike a road race or rally car, you're not running for hours at a time. In fact, the total run time at an event varies from as low as 90 seconds to perhaps as much as 640 seconds.

This isn't very much time to try and analyze all the various performance-influencing factors, especially in the "heat of battle" at an event. There's no time for an extensive driver debrief between each run, and on course, there is so little time between corners that it's hard for the driver to remember what the car was doing in each individual portion of the course.

In order to get the information the race engineer needs to do development work, there needs to be some means of recording data off the car. Furthermore, the system needs to be reliable enough and simple enough that using it becomes an ingrained portion of the run routine.

Enter the data logger.

The data logger is an electronic device, wired into the car, that records a number of operating channels. It also contains a pair of accelerometers that can record the lateral and longnitudal g forces the car is experiencing. It is a solid-state device, so there is no recording media to worry about, and it has sufficiant memory to record an entire event's worth of data. Furthermore, recording is a function of a pushbutton switch on the dash - when the switch is "on", the logger records.

This system is simple enough that it is almost driver-proof - "almost" in that the driver still has to remember to turn it on and off. ("on" is easy, but for some reason, "off" is tougher to remember)

After the event (or between heats in a multi-heat event) the data is downloaded from the logger unit into a laptop for storage and analysis.

This solution is far superior to laptop-based logging products. Not only is the sample rate higher, as the dedicated logger isn't forced to try and read all its data through a single serial line, but it is far more robust and simple to operate. Securing a laptop in the often violent environment of the race car is tough enough - securing it firmly enough and in a location where the driver can manipulate the program interface is another challenge entirely. And locating a laptop that is hardened enough and has a display suitible for reading in direct sunlight can be an expensive proposition.

Far better to remove the laptop from recording duties, hand this task off to the dedicated logger, and let the laptop serve strictly as an analysis device.

Our current data logger is an Edelbrock QwikData 16 channel unit.

The following is a screenshot of a portion of a run, recorded at the 2001 Peru National Tour, on Sunday. This particular event is noteworthy in that it was the event in which we tried Hoosier tires for the first time.

This corner is the long, sweeping "turnaround" at the far end of the Peru site. There is a lot of information here in this graph. Shown are Engine RPM (dark blue), Brake (light blue), Throttle (green), Boost Pressure (medium blue), Lateral G (red), and Vehicle Speed (purple)

Some bits of information are immediately obvious. For example, the driver is a right-foot-braker, so the lag time between releasing the throttle and applying the brake shows up as a gap between the throttle trace and the brake trace. As well, turbo lag is clearly indicated by the length of time between throttle application and the boost trace stabilizing.

But there is more subtle information hidden here as well.

[ more analysis to follow ]

By doing a histogram of the RPM trace of the entire course, we get the following:

This histogram shows the RPM percentages that was used during the run. As such, it highlights which part of the powerband is in greatest use, which in turn suggests areas for further development. From this histogram, we see that the engine spends most of its time operating in the 3800 - 4900 RPM range, with a secondary peak at 5300 RPM. From this, we can determine that improvements to torque at about 4700 RPM will reap the biggest benefits in terms of time, but also that the engine sees more high-RPM use than low.

As such, we can safely trade a little low-end (sub 3000 RPM) for high-end, because we spend more time there.