Understanding IndyCar Telemetry and Setup Data

Most people looking at IndyCar for the first time focus on the cars themselves — the 2.2-liter twin-turbo V6s, the 550 horsepower, the wings, the aerodynamics. That's fine. But the actual information that matters is sitting in the data streams coming out of each car during practice and qualifying. If you're trying to analyze how these cars behave or predict race strategy, the telemetry is where everything starts. I spent three seasons working with an IndyCar outfit in the NTT series, handling data analysis between sessions. One of the things nobody tells you about IndyCar tire management is that the tires are not inflated the way you'd expect for a road course. The Dallara IR-18 chassis uses spec Goodyear tires, and the front tires carry roughly 16 to 18 pounds of pressure while the rears sit closer to 22 to 25. That gap is intentional — it's how the car gets rotation into corners. But here's the thing that catches people off guard: those pressures change dramatically once the tires reach operating temperature. By the time you're on racing line, the fronts can climb to around 35 psi and the rears to nearly 40. If you're reading telemetry from warm-up laps and assuming those starting pressures are representative, your setup predictions will be off by a meaningful margin.

Getting Started with IndyCar Data Analysis

The first step is knowing where the data lives. In official IndyCar competitions, every car is equipped with a spec data acquisition system that logs at least 100 Hz across dozens of channels. Things like suspension travel, ride height, steering angle, throttle position, brake pressure, individual wheel speeds, and lateral and longitudinal G-forces. The spec system was put in place around 2012 when Dallara became the sole chassis supplier, and it standardized what teams could collect, which ironically made independent analysis more feasible because the format didn't vary between teams. If you're looking to work with this data yourself, the most practical route is through the timing and scoring files that IndyCar publishes after every session. Those aren't the raw telemetry files teams use internally, but they contain lap times split by sector, GPS-based position data, and speed trap readings. From there you can reconstruct a decent picture of what's happening lap to lap. For anything deeper, you'd need access to the actual CAN bus data that runs through the spec ECU, and that's where it gets complicated because IndyCar controls distribution of that material under competition rules. I've had people ask me about downloading full telemetry packages for analysis, and the short answer is that there isn't a public download link. The data is proprietary to the competing teams and the series. What does exist publicly is the timing scorecard, onboard video feeds, and some published sector data. From those sources you can still do useful work. I once built a tire degradation model for a road course using only the published sector times across 40-lap stints combined with pit stop windows from the timing sheet. It wasn't perfect — the model assumed uniform degradation across all positions on track, which is wrong, especially when traffic slows certain cars down — but it got me within about five percent of the actual tire wear curve when I later compared it against what a team engineer confirmed informally.

Reading Lap Time Data Without Raw Telemetry

When you only have timing sheets, you work with what you have. Sector splits are the most useful piece. A typical IndyCar track has three sectors defined by the timing beams. The time difference between sector one and sector two tells you whether a driver is carrying speed through the middle section or making up time in the final sector. That's basic but it's also underutilized. Most casual observers look at the overall lap time and stop there. What's more revealing is comparing sector performance across multiple consecutive laps during a qualifying run or a race stint. If you see a driver's sector two time degrading by fractions of a second lap after lap while sector one stays flat, that's a strong indicator the middle section of the track is wearing the tires differently — usually because it has more cornering load or higher surface abrasion. At places like Road America or the Chicago street course, this pattern shows up consistently. At superspeedways like Indianapolis Motor Speedway, the sectors tend to stay stable because the tire load is mostly straight-line with minimal lateral stress. Another thing I learned the hard way is that speed trap numbers can be misleading. The official speed trap is measured at a single point on the track, usually near the end of the longest straight. A car might show a high trap speed but still be losing time because it's carrying too much speed into the final corner and lifting early. Trap speed doesn't tell you about corner exit velocity. For that you need to look at the sector times in combination with the known track layout. If you know where the braking zones and acceleration zones fall, you can approximate where time is being gained or lost even without raw telemetry.

Get the Full Details

Alex Palou wins 3rd IndyCar race of 2025 at Barber Motorsports Park | wthr.com
Alex Palou wins 3rd IndyCar race of 2025 at Barber Motorsports Park | wthr.com

Common Mistakes People Make with IndyCar Data

The biggest mistake I see is treating all tracks the same way when analyzing data. IndyCar runs on a mix of street circuits, road courses, and ovals, and the data characteristics of each are wildly different. An oval lap is mostly about straight-line speed and braking efficiency. A street circuit like Long Beach is all about corner entry speed and stability under heavy steering input. If you apply an oval-derived model to a road course, it falls apart immediately. I had a colleague who tried to predict tire life at Barber Motorsports Park using a model built from Nashville Superspeedway data. The predictions were off by nearly 30 percent. Don't do that. A second mistake is ignoring traffic. IndyCar races have close packs and frequent lapping situations. When a car is stuck behind another, its sector times degrade not because the car or tires are worse but because it can't get the racing line it needs. A lap where a driver is in clean air will always look faster than a lap with traffic, even if the car is set up identically. If you're analyzing stint data, flag each lap for traffic presence. It's tedious but it makes the difference between a model that predicts correctly and one that doesn't. The third mistake is assuming that qualifying setup and race setup follow the same logic. They don't. Qualifying is about single-lap speed — minimum downforce loss, maximum straight-line velocity, aggressive suspension settings that sacrifice stability for grip. Race trim is the opposite. You need tire life, fuel tolerance, and stability through traffic. The setups can diverge significantly, and the data reflects that. I've seen cars run 20 to 30 pounds more rear downforce in the race compared to qualifying, which is a huge difference in cornering balance. If you're only looking at qualifying telemetry, you're not seeing what actually matters for the race.

Practical Steps for Working With IndyCar Information

Start by downloading the timing and scoring PDFs from the official IndyCar website after each session. Those are free and publicly available. Pull out the sector times for the top 15 finishers across all practice, qualifying, and race laps. Put them into a spreadsheet. Track how sector times change lap over lap during a stint. Note any pit stops and correlate them with the subsequent lap times. That's it. That's the foundation. From there you can add onboard video if you want to cross-reference what a driver is doing in specific corners with their sector performance. The video feeds are also available through the series' official channels. One workaround I developed for when I needed better than sector-level granularity was to use the onboard GPS coordinates that sometimes appear in published broadcast data. These aren't as precise as the raw CAN bus data, but they gave me position estimates every few seconds, which I could then combine with speed trap readings to estimate average speed over specific track segments. It took about 15 minutes per session to process, and the resulting approximations were good enough for strategic discussions. Not race-winning accurate, but close enough to spot trends. The limitations are real. Without access to the spec ECU data stream, you can't see suspension deflection, ride height changes, or individual wheel loads. You can't tell exactly when a car is bottoming out or how the aerodynamic balance is shifting through a corner. You're working with outcomes — lap times and sector splits — rather than causes. That's fine for general analysis and strategy discussion. It's not fine if you need to diagnose a specific handling issue or replicate a team's setup changes. For that level of detail, you need the official data release, which is restricted to competitors and licensed media partners.

Still, the publicly available information is enough to understand the sport at a much deeper level than most casual viewers ever get to. Sector analysis, tire degradation modeling based on lap time trends, and comparing qualifying versus race trim patterns will give you a solid framework. The data doesn't lie. You just have to know how to read it and where its gaps are.

IndyCar 2021: Team Penske, Jimmie Johnson, Indy 500 key top stories
IndyCar 2021: Team Penske, Jimmie Johnson, Indy 500 key top stories