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

I believe Garmin is doing something with option  five as various friends have contacted Garmin and told that a certain numbers of runs are required to help instant pace stability but you are right that nothing will be perfect with the various methods but could be closer to the truth to actual 

Matt_Barrett said:

various friends have contacted Garmin and told that a certain numbers of runs are required to help instant pace stability

Perhaps. But I have been running with my Fenix for over a year and the pace is still quite unstable and biased. 
A mere fact of running from a tree covered area to an open area, or back to a tree covered area changes the pace by 1:30-2:00/mile. Every. Single. Time. I can see the pace changing rapidly over 5-10 seconds by 15-20 sec/mile per second. It is like the watch flips the switch. Perhaps it has a smart algorithm, but it isn't properly calibrated, and it seems to be switching between the two different algorithms constantly depending on the GPS signal strength.

Out in the open the pace stability is actually quite good. But the conditions have to be perfect for that to work, and even a small number of trees makes the pace unstable.

Matt_Barrett said:

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.

Stride length in Garmin Connect settings is about walking....I don't know if it will affect pace estimation in running...but i'll try.

Third part datafields simply show you something derived from the pace calculated from F6 original pace (at least the one i've tried, a 15s rolling average), i'm not sure if they make they're own pace calculation.

Mattbest said:

There is no need to invent something new: the algorithm of any 7/8 years old forerunner works excellently.

With this argument you may deny every innovation.

A 7/8 years old FR is mainly a running watch, but Fenix is a multisport watch with additional:
- BLE
- Ant+
- WLAN
- barometer sensor
- acceleration sensor
- temperature sensor
- compass sensor
- HR sensor
- gyroscope sensor
- ...
and tons of apps, which all need battery power. And this battery power consumption is also a critical problem for the GPS signal reception and processing.

Therefore, you should compare the entire device, not only pick raisins out of the features.

Unfortunately, not every new innovation is immediately successful. Usually, it's a development process with setbacks. But I think, in the whole they are on the right way.

tl;dr: Things are more complex as they seem to be.

My assumptions and findings, that may help to understand the complexity of the problems:

For the calculation of an accurate GPS position there are at least a fix of four satellites are needed. Before the start of a running activity users try to soak a good GPS fix, which is usually indicated on the display of the device by a green ring, some bars, etc..

But what happens, if during running one or more satellites signals get lost or turn weak, due to running through a tunnel or under dense tree cover or under a bridge, multipath, atmospheric conditions, GDOP, ...? Even the own body shields the antenna in the backward/lateral direction. Or what happens, if satellites are switched, due to running an u-turn?

According to table 3 about GPS quality in ciq sdk docs
developer.garmin.com/.../Position.html
the SW uses 5 GPS qualities:

For value 1 (QUALITY_LAST_KNOWN):
If no GPS is available or is between GPS fix intervals (typically 1 second), the position is propagated (i.e. dead-reckoned) using the last known heading and last known speed. After a short period of time, the position will cease to be propagated to avoid excessive accumulation of position errors.

For value 2 (QUALITY_POOR) or 3 (QUALITY_USABLE) :
If a weak GPS signal is available, some SW filtering of the GPS noise and smoothing of the values is necessary, but this is limited. It's simply not possible to calculate accurate and smooth metrics from worse sensor values. Hence, garbage in -> garbage out.

For value 4 (QUALITY_GOOD):
If a strong GPS signal is available, (theoretically) the sensor values can be used without any modification. But in reality there is also noise present, which should be filtered out.

Furthermore, there exist a GPS position error, which is usually a circle with radius 3m around the current real position in 95% of the time. This means in 5% of the time the position error may be larger than 3m. If the position error is in the range of the real moving speed, it has a strong impact on the calculated speed. E.g. for running the position error of 3m is in the range of a usual running speed of 3m/s, and in this case the impact is strong. In contrast for cycling the position error is also 3m, but the usual cycling speed is 10m/s and therefore the impact is smaller.

Moreover, with running the watch at the wrist moves continuously back and forth about 0.2m. Hence, for running with an usual cadence of 180spm, during one second the wrist is in ahead position and in the next second the wrist is in back position. This may also have some impact on the distance and pace, e.g. for a run during 1h the distance deviation may be 0.2m/2s * 3600s/h = 360m/h. This means for a marathon it's >1km difference.

In addition for values 2, 3, (4), sensor fusion may be used to enhance the metrics, i.e. especially with weak GPS signals, metrics may be enhanced by taking the cadence into account.

These conditions changes continuously during running and can't be seen, neither on the display of the watch, nor in the .fit file. In the .fit file there is stored an enhanced_speed, which is the result of the filtering and the smoothing of the speed. But I assume that the lat/lon's are the original sensor values, they aren't filtered or smoothed. If the lat/lon's are accurate, there are less noise and the filtering and smoothing of speed/pace/distance is also accurate. This may explain, why the metrics are different if the GPX-file is uploaded to different platforms, like Strava.

Users want a small nice watch with a long battery life. Therefore, they get a small antenna that points lateral during running, and a low energy GPS chip. The accuracy of this combination is obviously limited. And the Fenix series isn't a pure running watch, rather it's a multisport watch. Because, for different activities the orientation of the watch is different (e.g. running, cycling, swimming, hiking, ...), it has been made some compromises regarding the position of the antenna.

The main reason, that a phone shows better instant pace than a watch is, that the phone has a larger atenna and more battery power, and therefore a better reception of the GPS signal. And some phones enhances the GPS by dual-band GPS chip.

A footpod shows a better instant pace than GPS. The satellites rotate over the earth in a hight of about 20000km and the GPS signal travels with the speed of light. For the trilateration of the GPS position, time differences of ns (10^-9s) are significant. During the travel of the GPS signal there are many possibities to disturb the signal, and this causes GPS noise. Every technical device has measurement tolerances which may accumulate, the position of the satellite, the GPS signal, the parts of the watch, ... But finally time differences of ns are relevant. Therefore the GPS metrics should be filtered and smoothed. The footpod signal travels only about 1m, and it's independent from tree cover, multipath, weather, etc.. It simply analyses and counts the steps and calculates the pace/speed/distance by multiplying the steps with the step length. It doesn't need to take the position error into account, but the drawback is, that it can't generate a GPS trace.

With a close look to a trace it can be seen, that there are segments that are pretty pinpoint, and other segments always have a drift, or some deviations. What's the reason for this: it's the same watch, but different GPS conditions.

It's easy and useless to complain over and over about Garmin, the SW devs and the HW designers, and I wonder why even engineers won't realize the complexity of the problem. Rather, feel free to make an useful suggestion how to enhance the GPS accuracy.

Just my two cents.

Thank you for the clear explanation of a very complex problem. From an engineering pov, I 101% agree with you. From a customer pov, I think almost 99% of users prefers better GPS performance than the super extra battery life of F6. Furthermore, F6 already gives me some options and settings to improve battery life, so, if I choose to use the most battery draining for GPS (GPS +glonass, 1 sec), I'd like to have the best possible accuracy. Finally, F6 is no more a new model, and even if innovation is important, if you (Garmin) have so many evidences of pace issues, a stepback in the algorithm is not a shame (if possible).

Thank you for the very interesting post.

GPS traces are often wobbling, although running on a straight course. I assume that for the calculation of the enhanced_speed in the fit-file the Kalman filter is already used to remove this noise. And in addition, the distance is not only calculated by the distances between the lat/lon's, but the heading is also taken into account.

Yeah, the watch assumes that most people run mostly on a straight line and the wobbling is due to GPS inaccuracy.

However in my case most of my running is on trails that are never quite straight. I find that Fenix tends to oversmooth the path and shorten the distance quite a bit. In fact GPS coordinates already seem to be filtered, which is most noticeable in corners - my watch always cuts through corners, up to the point that it is often unable to finish Strava live segments that end at intersections.

But the distance is further shortened on top of that. In my experience even unfiltered distance by connecting recorded GPS coordinates is already 3-5% short on trails, but Garmin's filteted distance is another 3-7% short. I would be much happier if Gain didn't do that at least in trail running mode. 

This is a great description however it doesn't quite explain inconsistency between distance, time, and pace.

I can agree that it may be difficult to get sufficient GPS accuracy and that GPS coordinates would often deviate side to side or back and forth. And yes, I see that in the recorded files if I look at distance deltas on consecutive seconds - one second it may increase by 2 meters, another second - 3, than 1.5, then 4. I am just making these numbers up, but I've seen uneven instant speed like that.

However this doesn't explain a consistent discrepancy. The algorithm certainly has some issues because on average the recorded speed is consistently slower than what you'd get by dividing the recorded distance by the recorded time.