Home Up
Product Support
Who is Bill Mitchell?
| |
Fundamentals of Data Acquisition - part 3
[ Home ] [ Up ] [ Fundamentals - part 1 ] [ Fundamentals - part 2 ] [ Fundamentals - part 3 ] [ Fundamentals - part 4 ] [ Fundamentals - part 5 ] [ Data Acquisition Procedures ] [ Force-Based Roll Centers ]
How to Do Data Acquisition
In the last few issues we described data acquisition systems and the questions they can, and can not, answer. This column will describe basic procedures: how to do data.
Proper data acquisition begins before the team leaves the shop. The entire system should be tested before the car goes onto the transporter. The system should be started and all sensors manipulated.. Turn the steering wheel, move the throttle, shake the accelerometer (g force) box and jump up and down on each end of the car. Download the data and verify all sensors. Engine changes and between race maintenance can damage sensors or cause connectors to be unplugged. Discovering this in the shop is preferable to losing time or data at the track. Simulating wheel speed is the toughest challenge. You may need to attach a magnet to an electric drill in order to simulate wheel speed. This is easier than trying to physically spin the wheel fast enough to register on the data acquisition system.
The next check occurs when the engines are being warmed up at the track. This has two purposes. It is one more verification of the system. It is also a backup for the system engineer. If you don't get speed or engine rpm data when the car does go out, you can say you did everything possible to assure the validity of the system before the car left the pits. Data is not as crucial as a wheel falling off, but you should take as much care with the data as the mechanics do with wheels.
The next step is to zero the sensors. This can be done on the set-up pad when the car is as level and as still as it will ever be. This allows you to calibrate the accelerometers and determine the static suspension settings. Also record the rollout (circumference) of all tires. The rollout of the rear tires effects the relationship between engine rpm and actual speed. The rollout of the front tire effects your speed data (assuming speed is measured as front wheel rpm). It can be very deceptive to pick up one mph only to discover you put on tires which were one-half percent smaller.
The data system should be turned on EVERY time the car leaves the pits. Even if the driver is just going out for two slow laps to see if anything falls off and get the sleep out of his eyes, collect data. If the driver must turn the data system on, get him in the habit. This allows additional verification of the system and sensors. You won't spend much time looking at this data, but it helps verify the system. It also helps to keep the connection between the engineer's written notes and the data. It can be very confusing when the engineer has 17 sessions and the data shows 16. The data will be worthless unless you can match the engineer's setup with the appropriate data. This sounds simple, but it can be a problem. The best way to avoid a mismatch is for engineer, crew chief, and data analyst to record the time of day of each session.
You also collect data every session in case of a blow up. If an engine expires during a warmup session you will want to know if it was over-revved or if temperatures or pressures were out of range. Data will not repair a broken engine but it will help understand what happened and perhaps avoid a reoccurrence.
When the car returns to the pits the data must be down-loaded. This involves a cable or PCMCIA card. Some teams may perform analysis in the pits during the session. Working under the extreme time limitations of a practice or qualifying session pretty much limits the analyst to answering specific questions, such as maximum speed and rpm in various turns. A well-functioning team will have procedures well established and always answer the same questions.
More complicated data analysis must wait until you return to the paddock. In the data analysis office (usually the front of the truck) I use three Compaq computers for analysis. A Compaq 6000 desktop with a large monitor is used for driver debriefing and discussion. This monitor must be visible to every one in the room, which can include all drivers, an engineer, the team manager, and occasional guests. A good debrief requires discipline and concentration on the task at hand. One of the biggest dangers is "victory disease", which was one of the factors which sunk the Japanese Navy in WW2. The euphoria following a pole can ruin a debriefing session. The team must remember that a successful qualifying session is not a race win; it is time to lock in an advantage and produce a victory on race day.
Race data should be recorded and studied, but many teams do not do this. You can deduce a great deal about engine performance by looking at maximum speed: did it rise as the fuel was burned off or did it fall as the engine got more miles on it?
A Compaq Armada 4120T laptop is used for downloading data, number crunching, sensor verification and preparation. While the primary computer is being used to compare the fastest laps of two drivers, this computer is churning through the entire session to look for over-revs and other pre-programmed information. This information must be presented to the crew chief as soon as possible after the session. It does no good to tell the crew chief of a over-rev ten minutes before the car must qualify. I have done this. The consequences are not pleasant.
The third computer is used for notes and report writing. It is important to have a written report of the events of the weekend. Did all of the sensors work every time? Were there any problems with the system? Did you have to break into your spares to replace any sensors or get blank disks or extra printer paper? Careful notes of this will allow you to insure the spares are replenished before the next race. You should treat spares as carefully as the team does spare engines, gearboxes and bodywork. A small bag of spare cables, blank disks, disk labels, pens, paper clips, stapler and other assorted odds and ends is essential. The absence of a spare cable may not cost you a race, but having inexpensive spares at hand makes you look professional and avoids embarrassment. Did you ever try to find blank disks in a public park in Brisbane, Australia?
A lack of data will not cost you a race. But think about the consequences of WINNING a race without data. This is not good for the data analyst.
The third computer is overkill and I wouldn't go out and buy a third computer just to take notes. But since I have the computer for software development I use it for report preparation. It is very convenient to record the results of every session (quickest lap, maximum speed, highest engine rpm, driver comments) as well as the questions asked and answers provided. If you answered a question by comparing lap 6 of session 3 with lap 4 of session 5, make a note of that in your report. If you print a graph to demonstrate that answer, print a second copy for your report.
I operate from a three page TODO list, which served as the outline for this column. This list begins with cleaning the work area (tires are stored on the work surface during transit) and even details what cables are to be connected to what computers. This is overkill, but every entry is the result of something which WASN'T done some time. The TODO list also serves as a reminder to get the analyst warmed up.
Reminders help avoid lapses.
Link to Tech Reports
Link to part two Fundamentals - part 2
Link to part 4 Fundamentals - part 4
|