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

  • I haven't yet figured out the Garmin algorithm for calculating the pace but something fishy is going on.

    I took out these graphs from todays run. A little faster this time so the pace dropouts are not as deep as the previous graph.

    Picture 1 shows the pace in blue versus the 200 meter lap pace in orange. 

    Picture 2 shows the averaged pace for the same distances as the laps in blue versus the 200 meter lap pace in orange. This one is interesting. Very easy to see the differences Slight smile

  • Did the same thing with a long and slow run for 19.5 km @ ~2 hours.

    Picture 1. Blue line is pace reported in the Pace Data Field and Pace diagram on Connect. Orange is Lap Pace and each lap was 200 meters.

    Picture 2. Blue line is calculated average pace for the same distances as the laps. Orange is Lap Pace and each lap was 200 meters.

  • This will probably an answer that people don’t want to hear but pace on consumer GPS watches will never be as ‘accurate’ as you want.

    I’ve invested in a Stryd foot pod and that really works but granted that’s an extravagant purchase if you’re only using it for instant pace.  By the way, even instant pace isn’t technically instant on Stryd - it seems to take a 3 second lag

  • Fenix 6 is my 6th GPS watch. I've never complained about pace accuracy before. Sure,  pace on my previous watches wasn't perfect, but it was accurate enough to be usable. In fact it was pretty good on Suunto Ambit3 - stable and consistent with mile splits. Suunto 9 wasn't too bad either.

    Fenix 6X is plain horrible in terms of pace. Most less expensive Garmin watches have more accurate pace. 

  • No one expects 100% correct instant pace on the Fenix 6 but I think than most of the pace related problems are due to software/algorithm problems. And most of the problems are solvable if Garmin puts some effort into it. I will put up some proofs later on. 

  • Picture 2. Blue line is calculated average pace for the same distances as the laps. Orange is Lap Pace and each lap was 200 meters.

    Interesting. Would you please show the relative error in %, e.g.

    relative error = ((calculated average pace / lap pace) -1) * 100

    and

    average relative error = sum relative error / number of samples

  • And here is a comparison between the built-in Lap Pace for each 200 meters lap (orange line) and an own calculation by GPS position delta based on the GPS semicircles for the same distances in the .FIT file (green line).

    So, it seems that built-in lap pace is mostly using the GPS data.

  • Here is a new screenshot that shows the relative error between averaged pace (blue line) and lap pace (orange line). I solved the earlier horizontal axis shift issue so this new screenshot is more accurate. Average relative error was 4.4% over 7122 data points (96 laps á 200 meters).

  • And here is a screenshot that shows the relative error between GPS position based calculated pace (green line) and lap pace (orange line). Average relative error was 1.7% over 7122 data points (96 laps á 200 meters).

    So, if Garmin changed the Pace algorithm from todays to a pure GPS based algorithm (rolling average for xx seconds) the Pace will be much more accurate. At least they could give us an option to choose how we want to have the Pace calculated.

  • Here is a new screenshot that shows the relative error between averaged pace (blue line) and lap pace (orange line).

    Great, many thanks. What are we learn from that?

    1. the calculation of instant pace and lap pace are performed with different algorithms.
    2. may be the differences are caused due to smoothing/filtering.
    3. the outliers are mostly at the end of a decrease in pace, i.e. for this type of course and/or running the algorithm may reacting to lazy on accelerations (or turns).

    It seems to me, that this is a run with variable pace between 5:10 and 7:20 (w/o outliers). But there are many open questions. Is it a flat or hilly course, road or trail? Where comes the outliers really from, are they from turns or challenging GPS conditions or from the algorithm?

    It should be tested if the outliers are also present if
    1. running with constant pace on a flat straight road course?
    if not
    2. running with variable pace on a flat straight road course?
    if not
    3. running with variable pace on a flat twisting road course?
    if not
    ...