Garmin Edge 500 sample time and Strava lap time determination

Last post I noted there had been a difference between the reported lap time up Old La Honda and the extracted time for the segment. The lap time had been reported by Strava as 18:12, while the segment time was quoted as 18:22, a ten second difference. But looking at the difference between the point at which the end of the segment was tagged and the end point of the lap I had a difficult time imagining that was worth ten seconds. After all, while I slowed there, not just coasting but actively braking to check for cross-traffic, I never came to a complete stop (law enforcement: my account here seems to have been hacked).

So it occurred to me I was assigning the full error on the segment time, but assuming the lap time was correct.

Back when I was making suffer score test files, I used a 3 second sampling time, the same as is used by my Android phone. Since each sample represents 3 seconds of ride data and since there are 3600 seconds in an hour, I generated 1200 samples. I figured I was calculating the suffer score associated with exactly a one-hour (3600 second) ride.

But to my surprise, the rides reported a duration of only 1197 seconds. Strava was taking the difference between the first and last point, not included the time included in the first point.

So with this experience, I went into the FIT file itself (using fitdump) and checked what the lap time was. The result: 18:14.55. Ah! So it turned out the difference between the segment time and the actual time I recorded with my lap timer wasn't quite ten seconds after all: it was only 7.45 seconds. That's still a big error, and the conclusion still applies you should use your lap timer, but you can't trust strava to report the proper lap time.

Suppose I have ten data points taken at 3 second intervals. Here's the points along with the lap numbers.

3 1
6 1
9 1
12 1
15 1
18 2
21 2
24 3
27 3
30 3

With Strava's apparent approach, the first lap was 15 - 3 seconds = 12 seconds, the second lap was 21 - 18 = 3 seconds, and the third lap is 30 - 24 seconds = 6 seconds. If I add these up I get 12 + 3 + 6 seconds = 21 seconds. Strava would then calculate the ride time as 30 seconds - 3 seconds = 27 seconds. So I've lost 6 seconds: one sampling time for each time I've hit the lap button.

Back to my ride: lap 1 = 56:13, lap 2 = 18:12, lap 3 = 68:54. That's, 2:23:19. But my ride time is reported as 2:23:28. So I lost 9 seconds there.

I checked and my Garmin was on "smart sampling". Whoops. That means while it typically samples at one-second intervals, if nothing interesting is happening according to its assessment then it goes to a longer sampling interval.

Here's the sample intervals found in my file:


Honestly I though I'd shut smart sampling off. One thing it's important to remember is Strava doesn't like smart sampling. So why have I been so stupid to use smart sampling?

Honestly I didn't try. I'n running version 2.60 of the Edge 500 firmware. At that time, sampling time wasn't an option: if you used a power meter you got one second sampling, but if no power meter was detected you got "smart" sampling. Garmin figured the only remotely sophisticated data analysis was being done to power data.

But that was pre-Strava: now position data is also very important. So it's time I upgrade my firmware... the option to force one-second sampling was put in in version 2.70, and they're already up to 2.80, so I'm upgrading my firmware as I type this.

So basically Strava is makes a lower-bound assumption on each lap time, and this will result in the sum of lap times being less than total ride time (assuming multiple laps). This is especially an issue if using a smart phone with a long sampling interval, or if you're using a Garmin Edge 500 with firmare version 2.60 or older. In either case the precise lap time is stored in the FIT file as a lap record. But Strava doesn't pay attention to this number, instead calculating lap times based on the difference between the first and last sample in the interval.