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

  • The influence of the accelerometer in conditions of non-optimal GPS conditions terribly affects the instant pace.

    The above is very easy to observe, and I observe it very regularly. On one of my local loops in a local park I have a place where the trail goes out of a densely wooded area into an open meadow, and then back into trees. The trail is flat and I run it with a reasonably constant pace. However every single time, without a failure, as I run out of the trees and into a meadow, within 30 seconds the pace on the watch speeds up by 2 min/mile, then as I exit the meadow the pace quickly drops by 2 min/mile again. That is about 20% variation in the pace.

  • Same here, have some places where it almost always ocurrs.

    Anyone seen any pace accuracy measurements for the Venu 2 Plus? My girlfriend is interested in that watch but also in the upcoming Fenix 7.

  • Update: Here is graph showing device pace vs. GPS pace from a recent trail race.

    The blue line shows speed measured by the device (in meters / sec). The red line shows 60 sec rolling average speed derived from the GPS track. The light gray line shows instant 1-sec GPS based speed, which are, basically, distances between points from consecutive 1-sec samples.

    If the device speed / pace was correct, the blue line showing the device speed would be consistent with the GPS speed and on average, would be above the red line roughly half of the time. However, as you can see, the blue line stays under the red line most of the time, which considering that the red line represents a rolling average, doesn't make sense.

    To give everyone a sense of the vertical scale:

    Speed m/s Pace min/km Pace min/mile
    2 8:20 13:24
    2.5 6:40 10:44
    3 5:33 8:56
    3.5 4:46 7:40
    4 4:10 6:42
  • "If the device speed / pace was correct, the blue line showing the device speed would be consistent with the GPS speed and on average, would be above the red line roughly half of the time"

    I do not think this is true. We know for a fact that there are errors in the GPS signal. Suppose you are running on a completely straight line and also suppose the device speed is correct. The GPS samples will be scattered around you. If all would hit exactly on the line, device speed and GPS speed should be the same. If 1 or more sample would be on either side of the line, the GPS speed will always be higher, never lower. The watch however does not know where you are running and must use the (erroneous) GPS samples to make a path through them. This is why the device speed isn't correct either. Since most runs involves twists and turns, there will be various levels of corner-cutting and overshooting, both by the GPS speed and the device speed. But, it is extremely unlikely that the GPS speed is correct.

  • The GPS samples will be scattered around you.

    No, GPS points aren't randomly scattered around the actual course. They are already corrected using the vector of movement and the data from compass and accelerometer. That is easiest to see in turns, as the plotted GPS points almost always cut through turns. If GPS samples were scattered the track would look way more wobbly. 

    If anything, the path formed by GPS points tends to be over-smoothed and already too short, at least at running speeds.

  • They are already corrected using the vector of movement and the data from compass and accelerometer.

    No, they are not.

  • Ahh. I thought you where talking about the GPS samples, not the adjusted track.

  • They are already corrected using the vector of movement and the data from compass and accelerometer.

    No, they are not.

    Look at the screenshot below. Do you seriously think the below is a raw GPS output "scattered" around the path of my run?
    In that case I ran fast downhill then walked slowly uphill on exactly the same trail. The path uphill (blue) is reasonably accurate while the path downhill (red) is quite wrong. To give you some scale, the track turns downhill about 25 meters too early (my path was right to left on the map before doing an out-and-back downhill and uphill section). FYI: Garmin map used by Garmin Connect isn't correct in this case, but OSM map shows this trail correctly, and it is much closer to the uphill part.

    I can find dozens of examples like that where the track produced by the watch either turns too early or very significantly cuts through corners. What are the chances those would be random wobbles.

    Furthermore if you look at how much the distance increases with each sample when running on a straight path, that varies from 1 meter to 5 meters when running at 3 meters per second. If the GPS track wasn't smoothed, positions would constantly wobble several meters either side. But that is definitely not the case. There is an algorithm where positions should land based on the recent speed and direction of travel, and that is used to do error correction of the path. Whether that is done in the GPS chip or in the watch software, I don't know, but I strongly suspect the watch does some additional buffering and correction, because I see behavior of Fenix 6X that I didn't see with Suunto 9, like the one shown above, despite exactly the same GPS chip.

    Here a screenshot of the same part of the run from Strava to show that the above is not just a result of visualizing the track in Garmin Connect:

  • You are confusing correlation with causation - nothing in a GPS track rendering like you show above tells us anything about what, if any, "correction" of raw GPS data is being done, certainly nothing as definitive as "vector of movement and the data from compass and accelerometer."

    If anything, you should be analyzing GPS track renderings to determine the efficacy and suitability of various GPS watch settings, e.g. Smart recording vs. Every Second recording, or GPS only vs. GPS + Galileo or GPS + GLONASS.

  • If anything, you should be analyzing GPS track renderings to determine the efficacy and suitability of various GPS watch settings, e.g. Smart recording vs. Every Second recording, or GPS only vs. GPS + Galileo or GPS + GLONASS.

    Please don't make assumptions. Obviously, GPS settings are as optimal as they can be. I have been using GPS watches for more than 10 years and I always squeeze as much accuracy out of my watch as I can. And I routinely analyze the underlying data using my own algorithms.