Related
Options
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

silentvoyager
over 4 years ago

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

  • 0 over 3 years ago in reply to silentvoyager
    silentvoyager said:
    broyson said:
    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.

    Then I don't understand why in your graph above, where you compare the speeds, the light gray line oscillates very strong. With this raw data, an accurate speed can't be reasonably calculated, because it strongly depends on the algorithms used to filter and smooth the data. Therefore: garbage in --> garbage out

    silentvoyager said:
    Look at the screenshot below. Do you seriously think the below is a raw GPS output "scattered" around the path of my run?

    As for your pictures with the curves above, I notice that the Strava trace wobbles more than the GC trace for the same activity. So I think GC is additionally smoothing the trace to enhance the user experience.

  • 0 over 3 years ago in reply to subra

    I also noticed that in the GC graphs for pace, cadence, altitude, ... not all data points are displayed. In my case for a run of 1:30h only every 3rd point is shown. I think the chart is optimized by GC because 1:30h = 5,400sec = 5,400 data points with 1sec recording.

    You can check this by zooming into the chart and hovering the cursor over the chart and looking at the values displayed.

  • 0 over 3 years ago in reply to silentvoyager
    silentvoyager said:
    Please don't make assumptions.

    I didn't.  You did not state what your GPS settings were for the published track renderinngs above, and I did not assume what they were.  So... what were your GPS settings for those tracks, and can you link to them so I can examine them for myself?

  • 0 over 3 years ago in reply to subra
    subra said:
    Then I don't understand why in your graph above, where you compare the speeds, the light gray line oscillates very strong. With this raw data, an accurate speed can't be reasonably calculated, because it strongly depends on the algorithms used to filter and smooth the data. Therefore: garbage in --> garbage out

    Sure, I don't claim that the red line is accurate. As I mentioned it is a rolling 60-second average. Furthermore I use least squares regression for each rolling 60 second sample to find the speed, so technically it isn't an average but a best possible approximation of a speed in each rolling 60 second sample. This approach is better suitable to deal with noisy data and to ignore outliers. 

    My point was to show the BIAS - that on average the device speed is always slower compared to distance travelled over time. Another method that I used at the top of the thread is to average device instant speed and compare that to the overall average speed (e.g. distance divided by time). Averaging instant speed is a valid method as long as all samples are taken at equal intervals (1 sec).

  • 0 over 3 years ago in reply to silentvoyager
    silentvoyager said:
    As I mentioned it is a rolling 60-second average. Furthermore I use least squares regression for each rolling 60 second sample to find the speed, so technically it isn't an average but a best possible approximation of a speed in each rolling 60 second sample. This approach is better suitable to deal with noisy data and to ignore outliers. 

    I'm not sure if least squares regression "ignores" the outliers. In your case, there are 60 data points that are fitted by a curve. But the outliers are still accounted for and affect the fitted curve.

    silentvoyager said:
    My point was to show the BIAS - that on average the device speed is always slower compared to distance travelled over time.

    In your chart of comparison speeds the instant speed of the watch (blue curve) was smoothed over a period of about 10-15 sec. So your smoothing of 60sec is too long for the comparison, try reducing the period for your own smoothing to also 10-15 sec.

    silentvoyager said:
    Averaging instant speed is a valid method as long as all samples are taken at equal intervals (1 sec).

    This means that the already averaged instant speed is averaged again.

    I'm very curious of the GPS accuracy of the F7 (dual band?).

  • 0 over 3 years ago in reply to subra
    subra said:
    In your chart of comparison speeds the instant speed of the watch (blue curve) was smoothed over a period of about 10-15 sec.

    Where 10-15 seconds come from? Try stopping and see how fast the pace changes to --:--. There is some averaging and smoothing of instant pace, but it goes over a few seconds - 5 seconds at most. There is also something in the pace algorithm that seems like calibration of accelerometer, and based on my observations that takes about 30 seconds.

    GPS data is very noisy, and if I average GPS speed over 10-15 seconds it would be unusable. Again, the point is to not come up with a precise speed, which is impossible based on the GPS speed alone, but to show a bias.

    GPS speed is accurate but not precise, meaning that the data is quite noisy but if you average it over a longer period the values are true. On the other hand, Garmin's device speed is reasonably precise but not accurate. That is what my main complaint is about. What Garmin must do is to fuse GPS speed with the sensor based speed correctly so that there is no bias. There are well known algorithms for that. Garmin already fuses the data, but not correctly.

  • 0 over 2 years ago

    I have the same problem with my Garmin Fenix 6x pro! 

    Garmin please fix this. 

    This is so frustrating right now to me!

  • 0 over 2 years ago in reply to Ivo_Vieira

    And it's even worse with the latest alphas/betas... REALLY long delays in speed/pace now. It started with version 23.73 Alpha and continues in 23.74 Alpha, 23.80 Beta, 23.82 Beta. Haven't tried 23.83 Beta yet but nothing in the changelog indicates that its fixed.

  • 0 3 months ago

    I have the same experience and considering to replace the Fenix 6 by Forereunner. Few races went pretty bad for me because of this. Sriously surprised the top model has this sort of bug. Compared the data with my training partners or other competitors.