Electronic Data Logging
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 electronic 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 longitudinal g forces the car is experiencing. It is a solid-state device, so there is no recording media to worry about, and it has sufficient 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 suitable 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 brakes with his right foot, 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.
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.
But perhaps the most useful aspect of the data logger is that it is not subject to the vagaries of human memory. The driver may swear up and down that "he didn't lift at that corner" but the logger knows the truth - and being able to identify the truth - and act on it in terms of development - pays huge dividends to both car development and driver development alike.
2010 Comment: of all the places where we were ahead of our time, this one ranks #1. The data logger went into the car about one-third of the way into 1999 and was used constantly through 2005. Aside from the rare occasion where I forgot to activate it before a run, I recorded, analyzed, and annotated every single run I ever made.
The ability to call up the data from an event for later review paid for itself over and over and over again. I'm still learning lessons from this data a decade after the fact.
And yet, the number of teams running data loggers in 2010 can probably be counted on one hand. The only real exception appears to be video capture systems (Randy seems to be doing well with Chase Cam) but that appears to be more about capturing video for later broadcast on YouTube than any sort of rigorous data capture and analysis program.
Look folks, this stuff is so much cheaper, faster, and easier to use these days that there's really no excuse for not running a logger. If you aren't, you're quite simply throwing time away.
