This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Instant pace is not accurate and has bias towards slower than actual pace

It appears instant pace on my Fenix 6X Sapphire has a consistent bias towards a slower than actual pace, often by 0:30-1:00 min/mile. 
That makes it more difficult to pace accurately, for example during races. It seems the bias is worse on more challenging terrain, for example on trails or under tree cover.

To understand this better I wrote a python script that parses a run activity that I export in TCX format (for easier parsing because TCX is a text based format).

Here are some examples of my script output. This is from a faster paced trail run on moderate tree covered trails:

Mile 1.00: Split: 8:42, Avg Pace: 10:04
Mile 2.00: Split: 8:52, Avg Pace: 9:22
Mile 3.00: Split: 8:37, Avg Pace: 9:17
Mile 4.00: Split: 8:04, Avg Pace: 8:31
Mile 4.53: Split: 8:03, Avg Pace: 8:03
----------
Overall pace 8:30, Avg Pace: 9:08

In this example Split time is produced every mile based on elapsed time from the beginning.
Avg Pace is produced by looking at the instant speed reported each second in each sample, averaging it over all samples of that split, and then converting that average speed to pace format (in minutes per mile). Basically Avg Pace represents the averaged result of what the watch was showing me during the run.

If anyone questions that approach, it should be OK to average the speed because it is sampled at even intervals every second (it wouldn't be OK in the case of smart recording).

As you can see there is quite a bit of discrepancy, especially in the beginning, although it gets better towards the end. Overall, after averaging, the watch reported 0:38/mile slower instant pace than what I actually ran, so there is a strong bias towards slower pace.

Here is another example - this is from a mix of road and suburban trails on more open terrain:

Mile 1.00: Split: 9:07, Avg Pace: 9:22
Mile 2.00: Split: 8:04, Avg Pace: 8:09
Mile 3.00: Split: 10:49, Avg Pace: 10:43
Mile 4.00: Split: 10:35, Avg Pace: 11:30
Mile 5.00: Split: 8:23, Avg Pace: 8:18
Mile 6.00: Split: 13:05, Avg Pace: 13:39
Mile 7.00: Split: 7:58, Avg Pace: 7:56
Mile 8.00: Split: 9:08, Avg Pace: 9:34
Mile 9.00: Split: 8:11, Avg Pace: 8:44
Mile 10.00: Split: 8:43, Avg Pace: 8:46
Mile 11.00: Split: 10:08, Avg Pace: 10:13
Mile 12.00: Split: 8:22, Avg Pace: 8:32
Mile 13.00: Split: 8:29, Avg Pace: 8:30
Mile 13.76: Split: 10:02, Avg Pace: 10:00
----------
Overall pace: 9:21, Avg Pace: 9:32

Even though this is much better overall, during some miles the discrepancy between the split times and the averaged instant pace was still up to 1 min/mile.

One more example - this is from a much slower mountainous trail run on steep terrain with a good amount of walking:
Mile 1.00: Split: 9:44, Avg Pace: 10:17
Mile 2.00: Split: 11:44, Avg Pace: 12:15
Mile 3.00: Split: 14:14, Avg Pace: 14:08
Mile 4.00: Split: 29:14, Avg Pace: 27:51
Mile 5.00: Split: 17:40, Avg Pace: 20:02
Mile 6.00: Split: 12:23, Avg Pace: 12:43
Mile 7.00: Split: 12:36, Avg Pace: 13:46
Mile 8.00: Split: 11:53, Avg Pace: 12:34
Mile 9.00: Split: 14:34, Avg Pace: 15:07
Mile 10.00: Split: 24:11, Avg Pace: 23:23
Mile 11.00: Split: 8:50, Avg Pace: 8:46
Mile 12.00: Split: 12:23, Avg Pace: 13:31
Mile 13.00: Split: 10:46, Avg Pace: 11:50
Mile 14.00: Split: 16:09, Avg Pace: 16:42
Mile 15.00: Split: 17:20, Avg Pace: 17:51
Mile 16.00: Split: 13:23, Avg Pace: 13:32
Mile 16.68: Split: 11:14, Avg Pace: 12:32
----------
Overall pace: 14:40, Avg Pace: 15:15

In this case the instant pace was faster than actual in a couple of splits, mostly in very slow ones where I walked or stopped. But the overall pattern is the same - there is a clear bias towards a slower pace.

I should add that today I installed a Rolling Average Pace Garmin IQ field that averages pace over the last 100 yards. I placed that field next to Garmin's Instant Pace and watched them side by side during an easy run. One thing was clear, every time I reached a steady pace and cruised for a while to let the rolling pace stabilize, the rolling average pace was always a bit faster than Garmin's Instant pace, which confirmed the same bias that I discovered from the post-analysis of the runs with my script.

Has anyone had similar observations?

12/05/21 EDIT: I changed the title of the post since Garmin seems to have improved the pace. It is more stable and precise than before, meaning that the values are closer together, but it is still not accurate - there is still a significant bias towards slower than actual pace

  • Exactly the same thing happens with the 945 without a foot pod

  • Let's keep visibility to this issue. Here is a fragment from today's run in a local park. I've zoomed the graph in to a 0.25 mile segment of the run. It started at 11:36 into run and finished 14:11, which means the duration of this fragment was 2:35. To find the average pace per mile on this fragment we just multiply 2:35 by 4, which gives us 10:20/mile average pace.

    On the graph I put the dashed line roughly at 10:20/mile, which as I mentioned above was the actual average. Pace displayed by the watch was slower than that 100% of the time, ranging from 10:23/mile to 12:14/mile.

  • Sorry, but I didn't understand your calculation. You multiply the duration and get the average pace? This isn't a linear function y=ax .

  • Average pace on that 0.25 mile.

  • Good information!

    I have recently configured my watch to add auto laps every 200 meters so it will be easier to follow this up. Most of the times the Pace data field is about 3-5% to slow compared to real pace. But sometimes it drops really low and can be up to around 50% off the real pace. And occasionally its too fast but that is not so common. The Lap Pace is also a little too slow but that seems to depend on distance shortage.

    Here are two sceenshots showing when the Pace was to fast:

    And here are two sceenshots showing when the Pace was really off to the low side:

    I will dig further into this later on and I think that I will register a support case about it but I think that I need more information first.

  • Thanks, already got it. It's simply a conversion of the unit.

  • I think that I will register a support case about it but I think that I need more information first.

    I have already contacted support 5-6 months ago and they have added me to already existing case. We need more pressure to get this addressed.

    Unfortunately the attitude seems to be to buy a Stryd instead. 

  • For these slower pace activities do you see different between the run, trail run, walk and hike profiles? If so this is something we can point Garmin towards to fix something which is broken

  • Agree, I will try to gather good information and then register another case on it. But I think that its three different problems to these pace issues.

    1. Pace/speed is generally to slow

    2. Pace/speed has really long delays

    3. Pace/speed has some strange dropouts

    I did another comparison in Excel based on the data in one .FIT file from a slow run. Blue is pace reported in the pace data field and also the same in Garmin Connect. Orange is lap pace based on auto lap configured to 200 meters per lap. 

  • Very interesting! This clearly shows there is a delay between the lap based pace, which is based on the actual distance travelled, and the instant pace. I think the reason for that is a sort of simplistic adaptive algorithm that tries to calculate current pace based on some past data, for example length of stride. But that likely doesn't take into account terrain or elevation changes - the fact that the length of stride is changing throughout a run. That would also explain why the pace is often way too slow in the first minutes, especially when running on trails, but then it mostly adapts.