You are right, I hadn’t noticed it before!
These are GPS Nsat and GPS PosAccuracy of the 2 laps, they seems different or I’m wrong?
Sorry, about that I don’t understand the point but it’s my fault. I have 2 laps, If I take one or another for reference, what’s the difference? The lines remains the same, with inverted colours, and the microsector time remains the same
What’s the GPS PosAccuracy here? It seems accurate to the millimeter, but in my case I’m not sure it is. I still don’t understand how a faster line (in km/h terms) in every moment of the sector can be slower by 2 tenths. My GPS PosAccuracy in the microsector is 400mm for one lap and 450mm for the other, so it may be a 40cm of imprecision, they are lot
The accuracy on both of those sessions is very good.
Can you email me the data file and what laps/corners? It’s much easier to explain it with the software than off screen shots. My email is [email protected]
Hi Matt, appreciate the response.
The map tile is there for just reference so you can get a sense of physical references on the track, it doesn’t change any of the analysis on RS3A side. But what’s still not addressed is the GPS offset between laps and its effect on the time compare result. When looking at the GPS overlays for both mine and Jacopo’s data, I think you can see a clear offset between the two laps being compared, it’s not just a matter of a difference in the driven line given how that offset is manifested around the entire lap.
It’s not always like this, in some cases the overlays don’t have any offset, but if you are comparing data between different drivers (ie devices), sessions, or different test days, it does happen.
If you analyze T3/T8 in my example (fast lap from two different drivers), the red line is shown as faster simply because of its GPS position (inside line), despite carrying lower apex speed. And then on the other side of the track at T8, despite the red line having higher exit speed all the way onto the straight, the time compare says it’s losing time because the green line is the inside line (assumed shorter distance). The GPS overlay will say the driven lines are different and if that’s true I’d agree with the analysis, but in reality they aren’t given these are capable drivers able to consistently drive the racing line and hit the apex.
I don’t dispute the improvements in RS3A, I’m just saying that any offset in the GPS between laps will mess with the time compare function. The relative accuracy of Aim devices is high and as you point out RS3A will give you the position accuracy and in most cases mine will be within 1.5ft (Jacopo’s data says 0.4m), but I don’t believe that to be the absolute accuracy of the GPS to a fixed point on earth or in this case the track. The GPS accuracy of a lap relative to itself is accurate, but relative to each other (different sessions/days/ two devices) can have error and thus offsets in the overlay and analysis.
I use a GoPro to verify the video aspect, unfortunately the only way to get definitive proof of these offsets is to encode the data with video like the smarter cam’s do which I don’t have. If you’re willing to lend out a SC3 to have someone collect data I’d be will to do that! 
1 Like
GPS error that occurs at the Mychron will then propagate to the lap distance. There is nothing you can do about this within RS3 because the error is in the coordinates themselves. I’ve tried zeroing the coordinates to the same point at the start/finish line since that’s about the most repeatable place on the track, and it helps, but you also have to correct the projection (a variation of Merkatur).
But backing up a bit, you simply can’t zero in on one corner and make any conclusions from the delta ref. You have to look at the whole lap and understand where changes in the delta ref affect the whole lap.
I’m sending it, thanks a lot
This is exactly the same problem I see when I analize my data. If the GPS see the kart in a innermost line than another lap, he assume that you are doing less meters even if in reality you are doing the same line
I think we need to backup a little bit. Time slip or time compare has been around a lot longer than GPS. It was originally calculated from wheel speeds, which gave us lap distance by integration. To make a quick summary from Jorge Seger’s book “Analysis Techniques for Racecar Data Acquisition” (a great book btw), the basics of time compare is the sum of difference in speed at each point along the track as a percentage. Note that there is nothing here about position in the world, it’s only lap distance which you will find to be very accurate on an M5S. My friend Samir does a nice job explaining this a little deeper, but not too deep, if you want a read Introduction to Motorsport Data Analysis: Delta-t I believe Chris Brown has it in “Making Sense of Squiggly Lines” as well.
So, it’s important to remember that the lap distance is what is important and you can see the lap distances you drove in the channels report. I’ll post the graph of lap distances along with the channel report showing them. You can see that I was within 27’ in lap distance from the shortest lap to the longest.
Offset in the data does not change the accuracy of the data. The distance from S/F is what is important and that is very good provided good GPS reception. I’ll take a look at Jacopo’s data tonight or tomorrow and repot back.
If people have more questions, are confused, or want more info, let me know.
This is flat wrong - the line you take around the track has a strong influence on the lap distance by a significant margin when comparing tenths of a second. An error on position translates into an error on distance traveled.
Edit to add: I just read that post you linked to. The author consistently assumes the lap distance is constant, but it is not in reality. Now, let’s say you run two dead-perfect laps but the GPS says one line had broader arcs than the other. The GPS will calculate a longer lap for the one with broader arcs despite starting and finishing at the same point. This is analogous to using wheelspeed sensors but with slip being involved. I’ve dove pretty far into the raw data out of my Mychron, and the best way around this is to periodically ‘reset’ the lap distance at known points like sector boundaries.
Edit #2 - that first wording came across pretty rude, so I apologize. Didn’t mean to sound combative
Hi Matt,
My understanding is AIM has a reference racing line (shown in grey on the middle of the track in the photo above) for each track. They use this reference line to sync the two laps together by projecting an intersection point to the driven line at a fixed frequency. In their examples it’s 1, 2, 3, 4, etc… Looking at points 3 and 4 in their example, I believe they will take the distance traveled between them for the two laps and using this and speed, and other factors, come up with a delta time.
To me it seems if your GPS data is offset (not talking about just S/F line offsets, but overall lat/long offsets like mine and Jacopo’s data shows), then the calculated distance will be different at each point in time during the corner and thus lead to inaccuracies in the time compare.
The overall distance traveled for each lap will be similar because the GPS offsets would be averaged out across the whole lap, so I’m not saying the lap distances are incorrect, they are just locally (in that particular corner) incorrect.
I don’t know what else can explain the behavior in the time-compare function. In the data you shared the GPS position is clearly more consistent and accurate relative to each other, but what about data like mine and Jacopo where there are visible shifts in the GPS?
I’ll email you some data sets for you to take a look at.
This shows up in the data as a blip in the delta plot that then resumes whatever trend it was on. It will look similar to a change in line that may or may not change the overall lap time because the GPS thinks your line changed. It doesn’t know if it really did or not. Overall, the affect is very small, it just means you need to keep this in mind when zooming way in on the delta plot
Here is what I see. You drove a different line in that corner that was roughly 6% of the corner corner length. You can see that it was different in the lap distance, GPS radius, and lat G plots (lat G was higher with a slower speed = tighter radius). The blue lap loses time on the entry and it loses it through the whole corner.
The GPS is measuring 25 times per second (25 Hz) and then calculating the speed based off the distance change and the time. It is not using the line for that.
Still lurking, still enjoying the conversations. Fwiw, based on this thread I was inspired to start dinking around with RS 3 Analysis today. (loosening my grip on RS2)
2 Likes
I’m seeing the blue gains time during the entire corner not losing it according to the time compare? That’s despite running a lower apex speed, exit speed and tighter exit than the green line.
Thanks Matt, so you confirm that is possible that in this lap I did a very tight line that give me lot time advantage (almost 2 tenths in one corner is incredible) despite having slower speed for the whole time. I’m honest, this sound very strange because this is my home track, I have maybe 1000 laps around it and I’m pretty sure I didn’t do something special in that lap; plus, the inner kerb is so high and not usable. I went to see ALL my records in RS3 and my best time in this sector is only 0.028 faster than the blue lap, but with new tires and more grip (think about that the faster lap was 7 tenths faster than the blue one).
But let’s move on and assume that yes, maybe in the blue lap I did the perfect corner, I’m not a professional driver so I can’t rule it out. From your experience as driver and data analyst, you are telling me that we can’t only see at the speed line to compare 2 laps or 2 driver? Because what 99% of data analyst do, including the one of our team but also F1 data analyst when they share telemetry on TV, is to see only the speed line to judge the goodness of a lap, ignoring completely the possibility that there is a very small shift point where less meters and less speed means faster corner/lap. Here we enter in a more mathematical and geometric field but is fundamental to understand how to read data. Do you think this is a possibility?
Playing a bit of devils advocate but, the data is all coming from the same place. Both the line and speed are coming from GPS data. So if its getting the line wrong, it may be getting the speed wrong too. Speed might not be effected if the entire line is offset, but if its only offset on one corner then I’d assume all data sourced from that GPS data might be off too.
You have to remember that speed is only part of the equation. The time it takes you to traverse a part of the track is the distance divided by the speed. If you take a long distance at the same speed, the time will be longer. If you can keep the same speed but drive a shorter distance, then you will have a faster time.
The difference between 6 and 4 is the same as the difference between 5 and 3. They are both 2 - that’s an offset of 1. It’s just a shift of the data. It doesn’t make one wrong, it just moved it over. I’m not saying that the overlay on a Google map is ever accurate (sometimes it’s good) but that is a different problem. The GPS accuracy of the M5S is very good and certainly good enough for lap to lap comparisons.
It is at best, 45cm or 1.5ft? I’ve never thought that was good enough but you work with what you have.
Of course, but talking about good drivers and not newbies, we assume that they take the right line. So when they need to improve these 1-2 tenths to reach the victory, I think they have to focus on maximizing speed doing 1-2 more meters and not on shortening the track, sacrifying the speed. That’s my cent about it.