How to fix / improve wrong current pace on fenix 6 pro?

There is custom stride length in the my profile of Garmin connect. Also does how does third party iq connect datafield fair with their feedback on pace? For example exact pace iq data field.

from my experience gps pace seems to be smoothed over 20 seconds and any sudden increase in pace (arm cadence) has a temporary pace increase until the gps pace smoothing catches up.

Edit: for forgot to that for workouts, it seems gps and footpod pace is smoothed using lap pace 

Edit: for those that barely move their arms vs someone moving their arm normally vs excess arm movement I wonder how these pace changes are displayed 

Mattbest said:

1. happens particularly in low gps signal areas (trees, buildings etc).

This is the reason for an inaccurate pace.

How would you calculate the pace if the GPS signal is weak or even lost?

The SW of watch uses dead-reckoning and sensor fusion.

But the pace/speed can dropout even if the GPS signal is good enough to plot a good GPS trace. I'm almost always loosing pace/speed in this area. But the GPS trace is good on the same section of the track.

Is the custom stride length in the Garmin connect profile just for walking? Does its adjustment have an effect when running?

AndersB said:

But the pace/speed can dropout even if the GPS signal is good enough to plot a good GPS trace.

How would you know that the GPS signal is good enough to calculate the speed/pace?

Please make a suggestion.

You can calculate the speed using the GPS positions (the semicircles) in the .FIT file. With some seconds of averaging it seems to be quite good data.

AndersB said:

You can calculate the speed using the GPS positions (the semicircles) in the .FIT file. With some seconds of averaging it seems to be quite good data.

Please, exactly how do you calculate the speed with noise data? And how do you averaging this?

Because the GPS data (the semicircles for each second) is has better precision than many thinks. And with a rolling average for about 3-5 seconds it should give pretty good accuracy. The above pace/speed dropouts is really off so the current solution with the accelerometer is not good for all.

The best would be if Garmin added a setting for this. To only use GPS and/or with the accelerometer data. And also let us choose the amount of smoothering in seconds.

Im away for some days and dont have a computer with me. Can show you the calculations next week. I have built an Excel spreadsheat for these type of calculations earlier. 

subra said:

Please, exactly how do you calculate the speed with noise data? And how do you averaging this?

I've actually done quite a bit of experimentation with this. The method that I am using is that I download activity data from Garmin Connect as a TCX file, then I have some code written in Python to parse and process the data. I wanted to see if I could create my own custom pace field that would be more accurate than Garmin's built-in pace.

Looking at the TCX data gives me the following data at each 1 second sample: coordinates, distance from the start, speed (in meters/second), altitude, HR, etc). There is no pace metric, but the pace is easily derived from speed.

One observation that I've made right away is that the distance at every sample progressively lags behind the distance that can be calculated from coordinates. It seems that Garmin smoothes the distance and the smoothing effect is much more pronounced on trails. So there is that.

The second observation is that the speed, on average, lags behind the distance over time. Let me clarify that. If you go over the entire TCX file and average the speed over all samples the end result is always slower than the average speed that you get by dividing the total distance by the total time. That is the speed/pace bias that I mentioned several times in my posts on this forum.

I tried the following methods to get a more accurate pace:

1) Simple running average. Basically we take distance delta in the last 10-15 seconds and divide that by the time delta. The resulting pace ends up being more accurate than what's reported in the instant pace but less precise, meaning that it is closer to the true pace overall (less bias), but it is less stable (more jumpy).

2) Running average using least squares method. This is far more accurate and allows to dismiss fluctuations in distance in individual samples. You can think about this method this way - plot distance and time values on a graph, then use linear regression to try to draw a line through the last few points so that the line is as close to all the points as possible. The slope of that line will be the speed. There is a simple enough formula to calculate the speed this way on the fly. I'd say even something as simple as this is already superior to Garmin's pace, although it works well only when someone runs at a reasonably steady pace. If you stop running and restart than it would take some time for this averaged speed to be accurate, depending on the number of seconds that you average it over.

3) Using distance calculated from coordinates (vs. Garmin's distance) further improves accuracy, but requires more calculations on every step. 

4) Simple fusing the distance data with cadence. The method I tried is to try to estimate stride length by looking at distance and cadence data, then using the recent stride length and the recent cadence, try to determine the speed. Overall this isn't a bad method because it reacts more quickly to changes in cadence, for example when someone accelerates. I suspect, based on my observations, Garmin uses a method similar to this. However they seem to estimate the stride length over a longer time interval which makes the pace inaccurate in the beginning. What this method doesn't fully take into account is that the stride length changes with terrain. For example it tends to shorten when going uphill and lengthen when going downhill. If the algorithm keeps to continuously re-evaluate the stride length this method may produce a decent accuracy and stability.

5) The best method would be to use machine learning to try fuse multiple methods at different ratios. Basically we have two domains of data. We have cadence based data which is precise but not accurate, meaning that the values would be fairly stable and close to each other in the short term, but not necessarily close to the actual pace and potentially deviate in the long term. Then we have long term GPS distance and time values that would be very accurate if you average over a long time but not precise at all in the short term. It should be possible to learn a specific users gait and fuse these two inputs at the right ratio so that the resulting pace would be more accurate and more precise than either the cadence based pace or GPS based pace. This isn't a very easy method, but still quite doable, and there is plenty of scientific research in this area. For example see www.udacity.com/.../sensor-fusion-algorithms-explained.html , in particular the Kalman Filter section.