Data Logging

One of my biggest "un-secrets" ("un" because I made no effort to hide it) was the fact that I ran a data logger in the car almost from Day 1. It went into the car in the second half of 1999, when I had made the transition to Street Prepared, because I was having a hell of a time figuring out what the car was doing (and in large part, what I was doing) and I needed help.

Installing the logger was a bit of a grey area, rules-wise. Byron Short's GEEZ (sadly, now defunct) and the venerable Valentine G-Analyst were the only devices explicitly allowed by the rules, but gauges were open - so I configured the outputs on my unit (an Edelbrock QwikData) as a sequential shift light, hooked up to a pair of high output LEDs on my dash, and the unit became a shift light capable of recording 20-odd channels of data. Sammy Strano sold it to me, and he knew where it was going (and I even recorded him at a McKamey school session - and posted the analysis on Team.Net) so it's not like this was any big secret.

But actually using the system for vehicle and driver development... that appears to have been a major innovation. Lots of people bought data systems of various complexity, and then only used them halfheartedly. That doesn't work. You only get the benefits of a data system if you use it every single time the car turns a wheel, and you take the time to do an analysis on every single run, make notes, and record observations.

This takes an enormous amount of self-discipline, as the analysis is rarely all that exciting, and it takes a couple of hours to do at the requisite level of detail. But done right, it can reveal all sorts of interesting things that directly improve the performance of both car and driver.

The key point here is that the driver's ass-dyno is usually dead wrong for analyzing car performance, especially in autocross where the driving portion of the event is over in a flash. Road racing, with multiple laps, gives an opportunity to the driver (and the car) to get into a rhythm and pick up on subtle differences lap to lap - not so autocrossing where you have ten times more driver inputs per second to deal with and where the total time spent driving may be less than a single lap of a road course. The only way to be sure that you know what just happened is to have some device recording what is going on for quiet and sober (rather than drunk on adrenaline) analysis later on.

"I was flat out all the way through that slalom!" - no you weren't Skippy, it says so right here on the throttle trace that you lifted at the third cone. Etc etc etc. Do NOT kid yourself on this; you simply cannot be successful at car development without a data system.

Buying a System

OK, so I've convinced you, and you want to buy a data system. What exactly do you need?

The good news is that you don't need a super high dollar system in order to reap benefits; even a simple system, used diligently, will pay enormous dividends (and the most high-zoot, high-dollar system, used indifferently, is a waste of money).

But the most important part of the system is the SOFTWARE, and that's the hardest part to evaluate; it doesn't transfer over onto a spec sheet very well. The only way to really get a feel for how good a given system is is to download their software (all serious systems allow free trial periods with their software) and play with it for a while. Take their sample data, and do an analysis session with it, and learn what you like and dislike.

I was lucky: the Edelbrock system software sucks golf balls through garden hose (you get some basic strip charts and histograms, and that's it) but my EFI system came with data analysis software that had been developed for Ford's WRC team, and it was phenomenal. I was able to write a perl program that converted the Edelbrock data files into DLOG99 data files, and I was able to use the cheap but powerful Edelbrock hardware with the very much more capable (and normally very much more expensive) GEMS analysis software. That's what really made the difference for me.

Incidentally, a slightly feature-reduced version of this analysis software is the data logging software used by the AEM EMS.

Do not underestimate the importance of getting good analysis software; you will be spending a lot of time using it, and the easier and more powerful it is, the more likely you are to actually use it - and the more productive your analysis sessions will be. The first time you bring up a differential time trace (showing the difference in elapsed time between two runs) which graphically displays where you were faster or slower on those two runs, relative to each other... that'll make all the effort worthwhile.

At the time of writing, Motec's software is probably the best in terms of power and ease of use, although I also really like GEMS. The downside of course is that to get access to this software, you need to shell out the big bucks for their hardware....

If you find a system that you think might work for you, TRY THE SOFTWARE FIRST and make sure you're not getting a pig in a poke. Don't be sucked in by shiny happy hardware specs; use the software!

As far as essential features go, the software should be able to do the following:

  • Overlaid strip charts;
  • Histograms;
  • X/Y plots;
  • Basic track mapping using accelerometers (this is just for reference during analysis; you won't be analyzing the driving line with this);
  • Differential time plots; and
  • Math channels, including calculus (differentiate/integrate).

As far as hardware is concerned, this is what you need:

    BARE MINIMUM SETUP
    • Vehicle Speed (usually off the speedo sensor)
    • Throttle Position (off the ECU's Throttle Position Sensor)
    • Brake Position (can be a pressure sensor, or just a tap into the brake lights)
    • Engine RPM (off the tach)
    • Longitudinal Acceleration
    • Lateral Acceleration
    • Steering Angle
    • (optional) Z-axis Acceleration
    • At least 100Hz sample rate (500Hz downsampled to 100Hz for smoothing works well)
    • Enough memory to get a full ProSolo heat recorded

    The nice thing about this setup is that most (sometimes all) of the sensors come with the car for free as part of the EFI system. The only usual exception is the steering angle sensor, but sometimes you get lucky and the OEM has one there.

NEVER buy sensors from the system provider; they can be had for fractions of the price from other suppliers.

    With this setup, you have everything you need to do driver evaluation and training, and you can infer a lot of car development from it as well.

    SUSPENSION DEVELOPMENT SETUP
      Add to the Bare Minimum:
    • 4 X Suspension Position Sensors
    • (optional) 4 X Wheel Speed Sensors
    • (optional) Yaw Rate Sensor
    • (optional) 3 X Infrared Tire Temperature (per wheel)

    The important sensors here are the Suspension Position Sensors - with them, you can do all your shock development in a way that takes the driver completely out of the loop. Couple the data here to a 3D suspension model, and you can watch suspension geometry changes in real time. All the other things are Nice To Haves that offer some good information, but aren't important enough to mortgage your house to get.

    Suspension Position Sensors Mounted
    ENGINE DEVELOPMENT SETUP
      Add to Bare minimum:
    • Fuel Pressure Sensor
    • Manifold Pressure Sensor
    • Injector Duty Cycle (tap into an injector driver)
    • Wideband Oxygen Sensor
    • At least one Exhaust Temperature Sensor (ideally one per cylinder)
    • Air Inlet Temperature
    • Voltage
    • Oil Pressure
    • Water Temperature
    • Oil Temperature

If you are doing your own EFI programming, the Wideband O2 Sensor is absolutely essential.

    USEFUL MATH CHANNELS
    • Shock Velocity (requires calculus on Suspension Position)
    • Roll Angle (subtract left side Suspension Position from right side - not really the angle, but shows roll amount. Comparing roll front to rear can be instructive.)
    • Gear/Clutch Slip (Engine RPM / Wheel Speed) - shows the current state of your clutch
    • Delivered Horsepower (uses Engine RPM, vehicle weight, Longitudinal G, wheel speed) to compute the amount of HP actually delivered to the wheels. Not error proof by any stretch, but it can be surprisingly accurate on flat sections - and can be made more accurate by compensating for pitch/incline angle by looking at Z-axis G and correcting.
    • Differential Throttle (Steering Angle) - how smooth is are the driver inputs? Shows up jerky steering/throttle like a sore thumb.

Once you are done building the system, you get to do stuff like this.

And that's hardly the limit... let's just say that I was able to do back-to-back A-B-A testing with every setup change I ever made, and could see the results right there in the data. This eliminated 99% of the guesswork in both my car development work and my own driver development, and this is THE SINGLE BIGGEST REASON why I was able to develop an unproven, untried car in a series that allowed such a huge variety in setups, running against the very best drivers in the sport, so quickly. Not that I didn't have my share of mistakes and missteps... but the data doesn't lie, and a driver/engineer willing to look at the data with an open mind will learn a metric assload in a very, very short period of time.

Oh, and there's no better bullshit detector than putting someone in a car with the logger running.....

Using a proper data logging system is THE key to rapid and successful car and driver development.