Product Support

Who is Bill Mitchell?

Fundamentals of Data Acquisition - part 2

[ Home ] [ Up ] [ Fundamentals - part 1 ] [ Fundamentals - part 2 ] [ Fundamentals - part 3 ] [ Fundamentals - part 4 ] [ Fundamentals - part 5 ] [ Data Acquisition Procedures ] [ Force-Based Roll Centers ]

What You Can (and Can't) do with Data Acquisition

Previously we discussed what teams can measure with their data acquisition systems (speed, engine rpm, temperatures and pressures). This month we will deal with the tougher question of what teams DO with this information.

I remember an early discussion with a team which was considering buying a car to move up into a new series. When asked how they would set up this complex car, they replied, "We will buy a computer system and let it tell us how to set up the car." Wrong. Data acquisition is a tool for the engineer, not a replacement. Properly used it can assist the engineer or crew chief; but it is not some magic font of all knowledge. Setting up a race car is a very complex task which must be performed under considerable time pressure. The human mind is still better than the computer.

Another time I remember working with a team new to data acquisition. After a session I produced a graph of speed and RPM. They asked to see the plot which would show understeer and oversteer. This was a very reasonable request. After all, it is the first question asked of a driver. Surely the computer could do at least this. Wrong. There wasn't then, and I do not think there is today, a reliable way of measuring understeer and oversteer. A lot of analysts have their pet ways of detecting oversteer (the steering wheel being turned to the right in a left hand turn is a good example of extreme oversteer) but there is no uniform method of measuring understeer/oversteer.

Part of this problem relies in the inherent difference between a test driver and a race driver. A test driver is trained to repeat standard maneuvers and detect the response of the car. A successful race driver DEALS with the handling problems of the car. If the car is understeering he may use more throttle to counter the understeer, and perhaps even make the car appear to oversteer. This type of man-machine interaction is very difficult to unravel and properly measure.

Those questions represent the limitations of data acquisition. Now let's discuss what you can do with data acquisition. The first thing you do with the data is answer certain set questions. You begin with the temperatures and pressures. Is anything out of range? If so, where and when. If the water temperature is too hot was it getting hotter throughout the session or only after the pit stop? Did it cool off when the car was near top speed (possibly indicating a blockage of a radiator). Was there sufficient oil pressure? If not, did the low pressure occur only in left hand turns?

Next you look at the speed and engine rpm. What is the engine RPM at the fastest part of the lap? Do you need more gear? If the top speed has suddenly fallen off, can that explained by a wing change or is your motor going off tune? How much engine rpm are you using the at the slowest part of the track? How much engine rpm are you using when the driver begins to accelerate? How much rpm when the driver gets to full throttle?

There was a time when one of the mental tests of a driver was to recall the engine rpm in each turn. That is no longer necessary. Now the data reveals the minimum rpm, the rpm where the driver begins to accelerate, and the rpm at full throttle. This gives you ample information to make gearing decisions, but you can still have a twenty-minute discussion on whether to change third gear 200 rpm. If you went 163 mph during qualifying, how fast will you go in the race? Will you go slower because you will have either more fuel or worse tires during the race compared to the optimum low fuel/new tires during qualifying? Or will you go faster due to the draft? And what if race day is twenty degrees hotter?

Then there is the question of over-revs. The telltale on the tach will (perhaps) reveal the maximum engine rpm encountered during the session. But if there is a 450 rpm over-rev, did it occur during a down-shift or was a gear missed during an up-shift? Did the over-rev last two-tenths of a second under power or was it one engine revolution when the rear wheels lost traction over a bump?

Those are the predictable questions to be answered after each session. After they are answered, and they must be answered each and every time the car goes out, you begin to mine the data for additional information. Every event will yield different questions. Some weekends it will be a mysterious misfire. Another weekend it will be a loss of top speed.

Consider a CART race at Long Beach a few years ago. We had the same engine/chassis combination as half the field and were lodged in mid-field after qualifying. Suddenly the team manager came up with radar speeds at the end of Shoreline Drive: we were eleven mph slower than similar cars. This led to intensive analysis of the data. We discovered that in top gear the car was literally slowing down every time the suspension encountered a bump. From this we concluded that at maximum speed, where aerodynamic downforce lowered the car, we were rubbing the bottom of the car on bumps. This drag (literally) was limiting our top speed. The solution was to raise the car enough to avoid sliding the car along the track.

The chief mechanic, who had been replacing the rub strips after each session, was not surprised by this decision. He did not even ask why it had taken so much computer analysis to uncover the problem he had been complaining about after each session.

This example is perhaps a good indicator of the value of data. It may not provide unique information which is not available elsewhere, but it does provide more detail and explanation. This may lead to certain decisions, or may re-enforce decisions made from other information. Either result is useful. When making decisions under extreme time-pressure additional supporting information gives confidence and, more importantly, helps avoid mistakes that lead you down the wrong road, which inevitably leads to defeat.

In summary, data acquisition is a valuable tool when used by an experienced analyst. But it is not an Aladdin's Lamp which fulfills every wish. Getting value out of the data requires an investment of time and effort. Waiting until the end of a two-day test and then asking "what does the data say" is a waste. The data analyst must know what questions the team is trying to answer and what they are doing to the car. Then the analyst can look for answers to specific questions in the data. Data will not win any specific race, but it is a tool which can be of value to a winning team.

Link to Tech Reports

Link to part one Fundamentals - part 1

Link to part three Fundamentals - part 3