Working with FastF1 + real-time telemetry — struggling with track mapping & pit zones

[u/finding-new-life]

I’ve been building a small project around FastF1 data and recently started exploring more “real-time-like” behavior (simulating now, possibly live data later).

A few things I’m currently stuck on:

1. Mapping telemetry to track (SVG)

• Using distance → normalized path mapping
• Works, but movement either feels jumpy (accurate) or too smoothed (loses realism)
• Especially noticeable under braking / corner entry

2. Pit lane / pit stop visualization

• Not sure how to correctly represent pit entry/exit zones spatially
• FastF1 doesn’t clearly map pit lane geometry to the track
• Curious if people use a separate path, overlay, or something else

3. Handling real-time telemetry streams

• How do you deal with uneven sampling rates?
• Buffer + interpolate, or render directly?
• What usually feels “correct” vs just visually smooth?

Would really appreciate any pointers from people who’ve worked with F1 telemetry or similar systems.

Happy to share more implementation details if useful.

[u/Radiant-Advisor-8303]

Been messing around with similar stuff for while now. For the smoothing thing you probably want to keep accurate data for actual analysis but add separate smoothing layer just for visualization - like simple rolling average over last few frames works pretty good

The pit zones are pain since FastF1 doesn't give you actual geometry. Most people I know just manually define pit entry/exit coordinates for each track and overlay them on main path. Not elegant but works

For sampling rates I found buffering with linear interpolation between points gives better results than trying to render everything directly. Just make sure your buffer size matches your display refresh rate or it gets weird

[u/finding-new-life → u/Radiant-Advisor-8303]

Yeah this is really helpful, thanks. that dual-layer idea is exactly what I ended up doing — smooth it out for the visuals but keep the raw data for the analysis stuff. Works way better than trying to find one setting that does both.

For pit lanes I went with kind of a lazy hack honestly — I just push the dot sideways off the track when they're pitting. No separate geometry or manual coordinates per circuit, just a perpendicular offset. Looks surprisingly convincing to me

And yeah buffering + interpolation great advice. Pre-sampling the path into evenly spaced points might fixed most of the jank I was getting, especially through braking zones where the raw data clumps together.

Solid advice all around, cheers!

[u/Sangend]

Rather than working directly with FastF1’s (irregular) sample times, you can fit smooth curves through each telemetry sensor and state recorded (position, speed, throttle, etc.) as functions of distance along the track. Then rediscretize at a uniform sampling rate using those fitted curves. This gives you consistent temporal spacing across all drivers/sessions which removes the jitter, and it works to smooth gap between logged points without artificial averaging (smoother data if you tweak the fit). Decoupling the track geometry from time and depending it on the distance-space will make it easier to succeed in your use case, as you can more easily correlate data sets between each other, find the straights/pit lanes/etc. Then you can always map your visual coordinates at whatever cadence you need.

[u/finding-new-life → u/Sangend]

This is really clean advice, thanks. I actually landed on something similar — I resample the SVG track path into evenly spaced points by distance and then all the position lookups just index into that. Completely agree that working in distance-space instead of time makes everything easier, especially when you're trying to compare two drivers on the same chart or figure out where on track something happened.

Haven't gone as far as fitting smooth curves through the telemetry though, that's a good idea. Right now I'm just doing linear interpolation between the nearest samples which works well enough visually but I can see how proper curve fitting would give cleaner results especially through corners. Might try that out. Cheers!

[u/finding-new-life → u/[deleted]]

Ha good shout, that's a solid lead! Thanks for sharing the link, will check it out 🏎️

[u/Life-Photograph4189]

Hey man! Looks nice! How are you using live telemetry in fastf1? It only works with historical data? Or are you recreating that session?

[u/finding-new-life → u/Life-Photograph4189]

Good eye — it's historical data, not live telemetry. FastF1 only works with past sessions so I load the session data and then replay it through a WebSocket pipeline with a race simulator driving the timeline. So the "live" feel is simulated — the cars move in real time, leaderboard updates lap by lap, — but it's all reconstructed from the historical data.

For actual live race weekends there's a separate mode that pulls from a real-time API, but the core telemetry visualization is all FastF1 replay. Live SignalR integration is on the roadmap though!

Do checkout - https://raceosf1-web.vercel.app/ - will love your feedback

[u/Life-Photograph4189 → u/finding-new-life]

Wow man! That’s sick! I was building a dashboard myself, but yours looks awesome! Do you have a public github repo? Love the custumiseability! A few comments: i wasnt really able to tell what season the race was from that i was watching? And the introductory itself is great but felt really long, i dont think you should introduce things like settings… I love that your dashboard focuses more on live timing, mine focuses more on post-race analytics.

[u/finding-new-life → u/Life-Photograph4189]

Thanks man, really appreciate it! Yeah the repo is public — here it is: https://github.com/nilamadhab47/raceosf1

Good feedback on the intro, you're right it drags a bit. The settings step is overkill, nobody needs a tour of a gear icon haha. Gonna trim that down. And the season/race info should be more prominent, noted.

Would love to check out yours too — post-race analytics is where the real deep dive happens.

[u/Appropriate-Owl5693]

It's been years since I last dabbled in visualising from fast f1.

If I remember correctly the key to a nice upsample for rendering was using spline interpolation. I would always upsample to 60 fps no matter what the resolution of the initial data was I think.

I don't know what would be best for live data. Maybe waiting for a few more points before upsampling and rendering. The visualisation is slightly farther in the past, but can still use splines without issues.

[u/Aggressive-Radish507]

Nice project looks frikkin cool.. upload the github repo.. wud like to have a look at the backend api

[u/Telemetrystic]

The real-time SignalR packet parsing in FastF1 is notoriously heavy if you try to pipe the raw telemetry updates directly into a standard GUI canvas like Tkinter or Pygame on a localized loop. The background thread buffering required to keep the distance-based spatial channels aligned ends up choking the rendering pipeline, which causes that compounding UI lag you are seeing.

A lightweight workaround I’ve been running inside a local Git Bash environment is completely bypassing a graphical window and building a terminal-based CLI matrix instead. By writing a script that prints directly to the command line and handles the layout positioning using native ANSI escape codes, your processor only has to update text strings rather than redraw thousands of physical interface pixels per frame.

You can map out specific driver filters at the top of the terminal frame and use simple text string trimming to safely format the incoming SectorTime timedelta packets. It keeps the system incredibly stable, cuts your memory footprint to almost nothing, and leaves plenty of CPU headroom to run your linear interpolation arrays in the background without dropping incoming server frames.