Overview
Occasionally, part of a session’s car telemetry (speed, RPM, throttle) gets “stuck”: the same values repeat sample after sample instead of varying as the car actually drives. This isn’t something Watchparty’s pipeline does. It’s a fault in F1’s own timing feed for that stretch of the session, present in the archive both FastF1 and OpenF1 draw from. Watchparty detects it and tells you plainly rather than plotting a flat line as if it were real data.How It Works
Detecting a Frozen Trace
A telemetry sample is treated as frozen if its speed, RPM and throttle values are all identical to the immediately preceding sample, including cases where both are simply missing. A trace is flagged as degraded once it has at least 100 usable samples and at least 30% of consecutive sample pairs are frozen by that definition. Those thresholds were set from measured behaviour: a healthy race lap typically has somewhere between 0% and 3% of samples frozen, while a genuinely broken feed showed 60 to 70%. A 30% threshold sits comfortably in the gap between the two, and the 100-sample floor stops a short fragment of a lap from tripping the check on noise alone.Why It Happens
This is a source problem, not an ingestion one. When a stretch of a session is degraded, both FastF1 and OpenF1 show the exact same stepped, repeating values for that period, because both ultimately draw from the same upstream archive. There is no better copy of the data to fetch instead. The affected channels are the car telemetry ones specifically (speed, RPM, throttle); the separate timing feed that produces lap times, gaps and running order is not affected by this, so a degraded telemetry trace does not by itself mean lap times for that session are wrong.Where You See It in the App
- A one-time warning modal appears the first time you view a degraded telemetry trace after selecting a session, titled “Telemetry degraded at source”. It explains that the F1 timing feed itself carried stale values for part of the session, so every data source shows the same stepped traces, and that this is not an ingestion fault. Dismiss it with Understood; it won’t reappear for the same session selection unless you leave and come back.
- A warning badge sits next to the affected driver’s entry in the Telemetry widget’s legend for the rest of your session, so you can see at a glance which traces are affected even after dismissing the modal.
FAQ
Does a degraded telemetry warning mean something is wrong with Watchparty?
Does a degraded telemetry warning mean something is wrong with Watchparty?
No. It means the underlying F1 timing feed had a fault for part of that session, before the data ever reached Watchparty. Both major data sources show the same fault, which is how you can tell it’s at source rather than in the pipeline.
What should I do when I see the warning?
What should I do when I see the warning?
Nothing is required. Acknowledge the modal and keep using the widget: it’s correctly reflecting genuinely frozen source data rather than hiding a problem. Treat flat stretches of the flagged trace as unreliable, and rely on other laps or drivers for that comparison if you need it.
Does this affect lap times or tyre degradation for the same session?
Does this affect lap times or tyre degradation for the same session?
Not directly. Lap times, gaps and running order come from a separate feed to car telemetry, so a degraded speed or throttle trace doesn’t by itself imply anything about lap timing accuracy.
Next Steps
Telemetry
See the degradation badge in the widget it belongs to.
Data Journey
How telemetry gets from source to this widget in the first place.
Insights and Versioning
How Watchparty handles missing or unreliable data elsewhere.