I am very certain that those fluctuations are nothing that is happening in reality. My theory is that this is an artifact caused during processing of the data on F1's server. Keeping the samples correct is most likely not a priority there. There is likely a small processing delay, and fluctuations of this delay can cause the samples to become somewhat incorrect.dialtone wrote: ↑22 Mar 2024, 16:20It’s not just sampling but they introduce jitter in these traces. So the interval between samples isn’t constant.Vanja #66 wrote:No idea, perhaps sampling rates of their traces are different.
That being said, it’s still a little weird and was happening in Bahrain as well. I’m sure there’s a very simple explanation and it could indeed be wind.
Those kinds of errors occur all the time, but usually they are on a much smaller timescale, that makes them much less noticeable usually. It's a combination of two things, samples having incorrect timestamps and samples having the same value as previous samples, sometimes both.
The errors here are in the range of 200-300ms approximately, and that makes them very visible already.
I have already tried to correct this client side in FastF1. It might be possible to do that by making enough (good) assumptions about the data and the processing that is involved here. But I haven't managed to get good enough results that I could actually roll this out as a new feature.
The lack of reference data is a big problem here when trying to evaluate the results. So if someone can get me some recent team-grade telemetry data, we might have a chance to fix this