Skip to main content
Blog
Between runs:
what a race engineer analyzes when the car returns to the pits
While the car is back in the pits, the
lap times stop, but the clock keeps ticking
While the car is back in the pits, the lap times stop, but the clock keeps ticking for the team. Lap times, sectors, tires, driver feedback, setup, track conditions — everything comes together to answer two questions: what happened, and what should be done before the car goes back out?
During every race weekend, when the driver gets out of the car, a key part of the engineer’s job begins: reconstructing what happened during the last run, interpreting the available information, comparing it with previous sessions, and deciding what to do before the next run. In just a few minutes, the engineer has to combine objective data with the driver’s feedback, relate the changes made to conditions that are evolving at the same time, and make the right call to keep the setup moving in the right direction.
The challenge is that none of those decisions comes from a single metric. Between one run and the next, the engineer has to determine which information matters, what may be affecting the result, and what needs to be checked again on track. With time working against them, analysis has to quickly turn into a plan of action. So what does an engineer actually look at before the car goes back out?
Where was the time gained or lost?
When the car returns to the pits, the first instinct is usually to look at the lap time. It is the most visible number and the quickest way to see whether there was an improvement, but on its own it explains very little. To understand what really happened, the engineer needs to break the lap down into sectors, compare it with other laps, and see whether the difference consistently appeared in the same part of the track.
Consistency matters too. One exceptional lap may reveal potential, but it does not necessarily mean the car has improved in a repeatable way. Rather than focusing only on the final number, the analysis needs to understand how that lap time was built and where around the circuit the differences began to appear. A lap tells you how much. The sectors start to tell you where.
What did the driver feel?
The stopwatch tells one part of the story. The driver’s perception tells another. The engineer needs to bring both together to better understand how the car behaved during the run.
Saying the car “won’t turn,” for example, still leaves too many questions unanswered. Does the problem appear on corner entry, mid-corner, or exit? Does the car lose stability under braking? Does it struggle for traction on throttle? Does it become more difficult to drive as the laps go by?
The more precise the description, the more useful the feedback becomes. The driver’s feeling starts to become technical information when it can be tied to a specific moment in the lap and related to what the car was doing at that point.
What condition were the tires in?
Comparing two runs without considering the tires can lead to the wrong conclusions. A different set, a change in pressure or temperature, accumulated mileage, or tire wear can significantly change the way the car behaves, even when the setup itself remains unchanged.
That is why the engineer needs to know the condition of each tire set when evaluating an improvement or a loss of performance. Tire condition is part of the context of every comparison and can explain differences that might otherwise be attributed directly to the setup.
Before attributing an improvement to the setup, you need to know which tires it was achieved on.
What changed from the previous run?
Between one run and the next, the team may adjust different setup variables: an anti-roll bar, camber, damping, ride heights, tire pressures, or other parameters. But recording what changed is only the beginning.
The real question is whether the car responded in the direction the team expected. An adjustment may solve the problem it was intended to fix while creating a new issue somewhere else in the lap. It may improve the car on corner entry but hurt traction on exit, or help in a fast corner while compromising a slower section.
So the analysis is not simply about checking whether the lap time came down. It is about understanding what effect the change produced and whether that effect matched the reason the change was made in the first place.
Did the car change, or did the context change?
Between two runs, the setup is not the only thing that can change. Ambient and track temperature, wind, grip level, traffic, fuel load, tire condition, and even driver execution may all be different.
That forces the engineer to determine, as far as possible, how much of the result can be attributed to the change made to the car and how much came from the conditions in which that result was achieved. It is not always possible to separate the two completely, but ignoring the distinction can lead the team to interpret something as a technical improvement when it was actually influenced by a faster track or more favorable conditions.
What do we do before going back out?
Everything analyzed up to that point ultimately leads to a decision. Keep the setup, revert a change, try a different direction, change tires, adjust pressures, alter the fuel load, ask the driver to try a different reference point, or simply confirm that what is already working should stay as it is.
The difficulty is that those decisions have to be made against the clock. Between one run and the next, the goal is not to review every piece of information available, but to identify what matters for answering the question that counts at that moment: what happened, and what should we do before the next run?
The better the engineer understands what has just happened, the clearer the next step becomes. Because often, the next improvement does not appear while the car is on track. It starts taking shape during those few minutes in the pits when it is time to interpret, compare, and decide.
That same logic is behind RaceData: bringing lap times, setup, tires, driver feedback, and files from each run together within the same context. Not to make the decision for the engineer, but to make sure the information they need is there when it is time to decide.