Telemetry and Data Analysis Introduction

During every GP broadcast, we see the drivers sat in the car in the pits, reviewing print outs of the telemetry from previous laps. Using them to understand the car and how to extract better laptimes from it.
Earlier this year an F1 fan offered me a set of telemetry sheets, they found discarded in a Monaco pit garage. These sheets compare the laptime of two team mates around a lap. With this unique opportunity we can start to understand how the driver benefits from this data.

So I had Brian Jee, a ChampCar/IndyCar Data Acquisition/Electronics Engineer to look at the sheets and explain what the data was and how the drivers can review it to see where they lose time compared to their team mate. Brain has written this following analysis to introduce us technical F1 fans to the world of Telemetry and Data Analysis

In order to maintain the teams anonimity, I have deleted the teams, driver, lap time and session details. Please do not speculate as to which team this belongs to, or I will have to remove this thread.

Telemetry and Data Analysis Introduction
Before we can begin to discuss analysis of the data presented on this sheet, we must first understand its origin and purpose.
The software that created this sheet is called ATLAS, an acronym for Advanced Telemetry Linked Acquisition System, developed by McLaren Electronic Systems (MES). ATLAS has become the standard data acquisition package in the F1 paddock due to the use of an FIA spec MES engine control unit on all cars. The entire data acquisition package consists of on-board car data logging electronics and transmitter radio, transmitting data via radio frequency to telemetry receivers in the garages. The receivers decode the data and operate as central servers of the decoded data to distribute it over a local ethernet based network. Any appropriately configured PC computer, running ATLAS software, can simply connect to the network and receive data from the telemetry receiver server. The simple ethernet architecture of the data distribution network also lends itself to an ease of sending the live telemetry back to the factory to engineers and strategists. Data is referred to in two forms; “Telemetry” is live data, and “Historic” is logged data or also backfilled telemetry. The hardware and infrastructure of the system is beyond the scope of this discussion, but is fundamental to understanding how an engineer would receive the data and with what tools he or she would interact with it.

Within ATLAS, we can loosely compare it to Microsoft Excel in reference to its working surfaces. In Excel, most people are familiar with the spreadsheet, as a whole, referred to as a “workbook.” Within that “workbook” are multiple “worksheets” containing any number of user created charts and information. Organization of the working surfaces of ATLAS is similar in that an ATLAS “workbook” contains multiple “pages” organized in a similar Excel tabular graphic user interface. Each page contains user created “displays” on which to analyze data. The printed sample of data we are here to discuss is actually a single selected “display” printed from a “page” in an ATLAS “workbook”, in the same manner that an individual chart can be printed from Excel.

At the top of this printed display we see, ‘StatLapOverlay Monaco.’ This user configurable information is used to aid in organization and titling. StatLapOverlay quickly informs us that this display is a comparison of two different laps. Furthermore, the date, time of day, and event location is noted as well, indicating where and when this comparison was made, not to be confused with where and when the data was necessarily logged.

This particular type of display is referred to as a “waveform.” A waveform display presents data relative to time or distance as the domain of the plot. Most commonly, data is analyzed on a lap to lap basis, most often the fastest laps of a particular outing or session. Here, that is indeed the case as we have data from two cars overlaid in reference to lap distance on the x-axis. Each car’s respective data is identified by color. Here, blue colored data traces from one car are compared to red colored data traces from another car. It is important to keep in mind that the blue car is the primary datum in this comparison and the red car is referenced relative to the blue car. We will discuss the importance of this key element later.

Now we turn our attention to the bottom of the sheet where we find lists of “parameters” in the area known as the “legend.” Each individually named parameter represents the calibrated output of a unique and individual on-board sensor. Additionally, a parameter may represent a “function parameter”, a mathematical output based upon sensor outputs input into mathematical calculations. If a parameter is present in any of these lists at the bottom of the display, its associated trace is displayed in the waveform above.

To the right of the parameters are a red column and a blue column of values. The parameter value column colors are in respect to the parameter traces of their relative color in the waveform above. Within the ATLAS software, the values change as a vertical line cursor moves across the waveform, allowing the user to identify exact values of points on traces. The values we see here are simply where the cursor happened to lie when the display was printed. The vertical line cursor is noted in the illustration below. Within ATLAS, the cursor is scrolled across the waveform by simply moving the mouse from side to side or using the keyboard arrow keys for finite movement.

Now let’s examine the parameters we are presented with. To begin, each parameter is prefixed with a letter denoting the type of unit of measurement of the calibrated output from the sensor with which it is associated. We have the following prefixes:
v = Velocity, positional displacement over a given time
N = Number, quantitative indication
r = Percentage, relativity to a total
a = Angle, geometric displacement about a vertex
p = Pressure, force applied to a reference
M = Magnitude, scalar identity
B = Bit, bit indicator. For example, binary 1 or 0 indicates on or off
T = Time

Continuing examination of the parameters:
vCar Velocity of the vehicle. Units: kph
There are individual rotational speed sensors on each wheel, but due to speed differentials between each wheel due to slip, turning through a corner, and wheel lockup, they do not represent the velocity of the vehicle. Thus, the individual wheelspeeds are input into “function parameter” calculations to accurately determine the velocity of the car, compensating for differences in individual wheel rotational displacement.

NGear The engaged gear number of gears 1 through 7, with neutral gear represented by number 0

rThrottlePedal Throttle pedal position. Units: Percent
The calibrated position output of the throttle pedal is represented as a percent of total driver application mechanically available. Thus, 0% means no driver application, and 100% means maximum driver application.

aSteeringWheel Rotational angle of the steering wheel, relative to steering rack position.
Units: degrees.
In a 0 degree position, the steering wheel is in an exact “straight ahead” position and the steering rack is centered accordingly.

pBrakeR Hydraulic pressure applied to the rear brake system, measured at the hydraulic output of the rear brake master cylinder. Units: Bar

MDiffDemand Torque applied to the differential. Units: Nm

MKERSDemand Torque applied both to and from the KERS MGU. Torque is applied to the MGU under braking for energy harvesting. Torque is applied from the MGU during KERS boost application. Units: Nm

BNRearWingStateControlMode A bit indicator used to identify DRS activation status.
Units: Active or Inactive

TDiff A function parameter that compares laptime as a function of track distance. It facilitates analysis of laptime relative to track position between a datum lap and any other given lap
The nature of these given parameters identifies this waveform as a classic “driver comparison.” All of the driver’s inputs into controlling the car are present and organized in a specific manner that allows them to quickly identify where on track they are gaining or losing time relative to a datum. For example, a driver may be able to quickly identify a specific portion of the track containing a comparative loss of laptime and easily identify that they are braking 10 meters too early into a corner compared to a teammate.

The other information we see above the parameter value columns are user specific identifiers of the data sessions in question, such as date, event location, and driver name.

A track map of Monaco is located in the lower right corner of the display. A dot moves along the track map relative to the vertical line cursor position as a function of track distance, as it moves across the waveform. The location of the dot on the map is a visual aid in assisting the user in quickly identifying the on-track location of trace characteristics. In addition, we see that corners are identified as green and straights are yellow. These features are further visual aids in assisting the user in ease of identifying on-track location of activity in the data traces. The ATLAS software automatically generates the map based upon lateral acceleration and track distance logged data. The green corners are calculated and determined against thresholds of lateral acceleration.

Lap comparison
Now, let’s turn our focus to the waveform plot. The most essential part of the plot is the x-axis. The x-axis scale is user configurable in units of either time or distance. Time or distance will begin at zero origin at the left side of the plot at the beginning of a lap at the track timing line, increasing towards the right, ending at the end of the lap at the timing line. This example of data represents Monaco and as such, we see the x-axis scale begins at 0 meters on the left and ends approximately after 3200 meters on the right. A total lap distance at Monaco is approximately 3340 meters. All data will be defined as a function of the x-axis, indicating where and when a point of data occurred. Most commonly, the x-axis is defined by distance due to the importance of understanding the physical track location of an occurrence in the data and the distance the car travels relative to any occurrence. Scales of distance also facilitate the comparison of cars and drivers. For example, distance will allow us to see how much further into a corner one driver brakes, compared to another driver. We will examine such an example as we continue on with our discussion.
As we examine individual traces in the waveform, let’s begin from top to bottom.
The first trace at the top is rThrottlePedal with its vertical scale identified on the right of the waveform in units of percentage from 0.0% off throttle to 100% full throttle. We can see the negative slopes of when the driver releases the throttle on corner-entry, completely off the throttle mid-corner, and returns back to full throttle through corner exit with positive slopes.
For closer examination, let’s look at the exit of turn 8, Portier, leading towards the tunnel. Achieving a good exit from turn 8 is crucial to laptime because it exits onto a long straight through the tunnel. Red driver tries to re-apply throttle too aggressive on corner-exit, inducing a moment of snap oversteer and subsequently had to lift slightly to regain control of the car at approximately 80% throttle. Blue driver was much more controlled and reapplied throttle in a much more linear controlled fashion, with three instances of slight modulation, and did not have to lift on exit.

The second trace is vCar with its vertical scale identified on the left of the waveform in units of kph from 0.0 kph to 360.0 kph. Trace maximums define the maximum velocity achieved on entry into a corner with subsequent negative slopes of velocity during braking on entry. Trace minimums identify the mid-corner minimum apex speeds and lead to the positive slopes of acceleration on corner-exit and carried throughout the straights.
For closer examination, let’s take a look at turn 1, Saint Devote, through to turn 3, Massenet. Blue carries much more mid-corner speed through turn 1, and maintains the speed advantage through corner-exit and all the way along the straight to turn 3. On entry to turn 3, Red brakes earlier than blue and once again carries less speed into the corner on entry, all the way through mid-corner. Since Red is mid corner at lower speeds, he is then able to apply a return to throttle earlier than Blue on exit.

The third trace is Tdiff with its vertical scale identified on the entire length of the right hand side of the plot, in units of seconds, from -2.400 seconds to 2.400 seconds. This trace is automatically created and calculated by ATLAS whenever layers of data are overlayed. The parameter is always referenced from one layer of data to another. In our example, we see that the color of the trace is blue, indicating that the blue layer of data is our concern and the red layer of data is our reference datum.
The trace begins each lap on the left hand side of the wave form aligned at 0.000 seconds on its scale. As the trace is drawn across the x-axis, it naturally takes on positive or negative slopes and displacement from 0.000 seconds of beginning time. Positive time differentials indicate the driver was slower than the reference driver in displacing a given track distance. In contrast, negative time differentials indicate the driver was faster than the reference driver in displacing a given track distance. The trace is scaled larger than the other traces across the entire waveform, not only to visualize its slight nuances easier, but also because this single trace defines the utility of the entire display. A driver or engineer will be able to quickly identify the greatest time differentials in TDiff and know to focus attention on data where that difference occurs. In our sample, we see that Blue completed the lap at -1.650, meaning Blue’s total laptime was 1.650 seconds faster than Red.
For closer examination, let’s again take a look at turn 1, Saint Devote, through to turn 3, Massenet. Looking for significant TDiff time differentials, we can quickly visualize two occurrences at turn 1 and turn 3 and focus our attention there. The TDiff scale identifies that Blue gained 0.38 seconds through turn 1 and an additional 0.27 seconds through turn 3. From what we learned from examining the vCar trace, we know that Blue was carrying approximately 10kph more speed through both corners, lending to his 0.65 seconds total gained through both corners. As Red’s driver or engineer, they now know that focusing attention on improving the driver or car for the demands of corner 1 and 3 will yield a gain of at least 0.65 seconds. Subsequently, they will try to understand why Blue and Blue’s car is able to achieve those gains and learn from them accordingly, relative to car setup and driving characteristics.

The fourth trace is BNRearWingStateControlMode, indicating DRS activation. The output of the channel is ‘Active’ or ‘Inactive’ and thus binary in nature. When represented as a trace, we see that it is not transient in nature, as compared to vCar or rThrottlePedal. Along the trace, maximum linear values represent DRS activation and minimum linear values represent the rear wing flap in a normal state with inactive DRS. The binary nature of the trace also lends itself to a lack of need for a vertical scale on the left or right side of the plot.
Continuing examination of turn 1, through to turn 3, we see both drivers activated DRS on exit of turn 1 all the way to corner entry braking of turn 3. Both drivers obviously use DRS to capitalize on decreasing drag for as much distance as possible while at full throttle acceleration through the ‘kink’ of turn 2 and into turn 3.

The fifth trace is MKERSDemand, indicating KERS discharge boost and energy harvesting recovery under braking, defined by force in units of newton metres. The purpose of this trace is qualitative in nature only to identify when the KERS system is discharging or recharging. Therefore, a vertical scale is not necessary on the left or right side of the plot to indicate exactly how much force is applied to or output from the KERS system. Minimum values illustrate KERS energy recovery under braking as rotational force applied to the MGU. Maximum values illustrate KERS energy discharged as rotational force applied to the engine crankshaft from the MGU. As with DRS, KERS is most advantageous for lap time in activating when exiting a corner that leads to a long straight. Torque is the key advantage of KERS, so energy discharge should be activated as soon as possible on corner exit.
In discussion of MKERSDemand, we will examine turn 1, from corner entry through to exit. The illustration will also include the pBrakeR trace at the bottom of the waveform, of which we will discuss later, but require now to illustrate energy recover under braking. All you need to keep in mind now about pBrakeR is that the positive slope indicates brake pedal application and negative slopes indicate brake pedal release.

The sixth trace is MDiffDemand, indicating the force applied to the differential, with its vertical scale present on the right side of the waveform, ranging from 0.0 newton meters to 2000.0 newton meters. Discussing the function and operation of electromechanical control of the differential far exceeds the scope of this discussion of an introduction to telemetry. In addition, without full knowledge of the mechanical and electronic control settings of these particular differentials in question, we are unable to engage in a reasonable analysis without assumptions. Therefore, we will simply note the major characteristics of the trace without analyzing the differences between Red and Blue.
Maximum linear values of 2000.0 Nm is present when the car is generally accelerating and traveling in a straight line and maximum torque is being applied by the differential to both wheels, such as in a spool. Negative slopes represent slowing down under braking and turning in towards the apex of a corner as force applied to the differential is decreased and the differential is thus differentiating rotational speed and force between the two wheels to allow the car to rotate. Positive slopes represent when the exiting the corner, turning away from the apex and returning to full throttle. On corner exit, the differential must not only apply as much torque as possible to accelerate the car, but still allow the wheels to separately differentiate in order for the car to continue to rotate out of the corner. Minimum linear values occur at the apexes of a corner, illustrating full open differentiation between both rear wheels in allowing maximum rotation of the car.
In discussion of the MDiffDemand trace, we will again examine turn 1. The illustration will include aSteerWheel, just below MDiffDemand, of which we will discuss later. The only thing to keep in mind about aSteerWheel for now is that concave or convex maxima or minima represent the apex of a corner.

Now we will continue to specifically discuss the seventh trace, aSteerWheel, indicating the angular displacement of the steering wheel by the driver, in units of degrees. The trace’s vertical scale is found on the left side of the waveform plot ranging from a minimum of -100 degrees to 100 degrees. Trace values at or near zero represent the steering wheel in a normal straight position in addition to the car traveling straight. Positive slopes indicate the driver turning right, whereas negative slopes indicate the driver turning left.
Since we are already familiar with the aSteerWheel trace at turn 1, we’ll continue to examine that trace bit further, but also include rThrottlePedal.

Recall from our discussion of rThrottlePedal, when Red attempted an over-aggressive return to throttle on the exit of turn 8. Now that we have discussed aSteerWheel, let’s look back at how that effected steering input.

The eighth trace is Ngear, indicating the engaged driven gear in the gearbox. Ngear’s vertical scale is located on the left side of the waveform plot, ranging from 0 neutral gear to 8th gear. Of course the gearbox only contains 7 forward gears, but the 8 is simply for scalar reference. The trace is “stepped” in nature due to the linear and transitionally steady state nature of gear engagement and selection between gears.
Since we have already discussed the vCar trace relative to turn 1, we will continue to do so and now and include NGear in illustration.

Furthermore in examination of NGear, we can take a look at the impressive downshifting characteristics of an F1 car on entry to the Nouvelle Chicane after exiting the tunnel.

Our ninth and final trace is pBrakeR at the bottom of the waveform plot, representing hydraulic pressure applied in the rear brake circuit. Its vertical scale is on the right side of the plot, ranging from 0.00 Bar to 125 Bar.
It isn’t of concern which pressure trace is used from which hydraulic brake circuit, front or rear, because we are not concerned with defining exactly how much force is applied in any given circuit. We only need to know in what manner the driver applied and released brake application, from a purely qualitative perspective. In the case of this driver comparison waveform, a driver or engineer will be primarily concerned with the shape of the braking trace and the relative track location at which initial brake application begins. Obviously, it is optimal to brake as late as possible into a corner and carry the maximum amount of speed to the apex, carried though to exit. In comparing two drivers with similar cars and setups, both drivers would be expected to brake just as deep into a corner as one another. It is common and essential for drivers to examine comparative braking characteristics to understand why they may not be braking as deep or as hard into a corner as their teammate.
The initial positive slope of a brake application trace is steeply sloped approaching the maximum peak because it is optimum in car performance to reach maximum brake application while maximum corner entry speed and thus maximum aerodynamic downforce is available to assist in braking stability.
Continuing to utilize turn 1 as our example of analysis, we will now include the pBrakeR trace in illustration.

Now that we have applied most of our efforts towards examining turn 1, we can summarize that Blue had to accomplish a lot to gain 0.38 seconds TDif, all in one corner. We learned from our analysis that Blue was more aggressive on entry with higher minimum corner speed and turning in towards the curb as early as possible. His success early in the corner allowed him to return to throttle earlier and activate both KERS and DRS earlier as well, all paying dividends towards lap time.
The reality of this particular dataset is that it was logged during FP1, in which teams treat as a test session, in addition to the green track lacking sufficient grip. Furthermore, we are unaware of mechanical or aerodynamic setups, fuel loads, and tire configurations. Without knowing the parity of the cars, it is impossible to compare the performance of the drivers. A major indicator of non-parity between the cars is the final TDiff comparison between the drivers indicating a lap time difference of 1.650 seconds. We can only realistically compare two drivers in similar cars if they are within a few tenths of each other. In addition, from a full perspective of the lap as whole, Red definitely does not appear to be driving in a manner to set fast lap times, reaffirmed by the significant TDiff time difference. If we were to delve deeper into analysis, we increase the need for more specific details about these two cars and drivers, so as not to make incorrect assumptions about either.
When analyzing data, it is important to remember not to perceive or analyze it as if it was repeatable laboratory data. Race car data analysis is much more complicated than that. Beyond the mechanical variances of the car and environmental discontinuities of the track, the driver is a human being who adapts, makes mistakes, and never drives a lap exactly the same as a previous one. For example, if a driver complains of corner entry understeer, it won’t be literally evident in the data because they would have adapted through driving or adjusting available settings. Properly configured data never lies, but it is only truly a useful tool when combined with discussions with the driver and fundamental engineering knowledge. There is much more to be learned from this waveform, but we don’t have all day long to explain it all.

About Brian Jee
Twitter: @brianjee
Indianapolis based Brian is an Ex Race Engine builder/machinist. But more recently a ChampCar/IndyCar Data Acquisition/Electronics Engineer. Brian is looking for opportunities to use his experience to work in F1.