Fenix 6x GPS Accurate - But Records Incorrect Distance

Can you please elaborate Chris on your post, because what you're saying clearly isn't the case here with fenix 6 series watches. They cut every single activity, while newer Garmin watches don't. I can't imagine it would be impossible to fix this algorithm problem. I don't mind the track on strava looking bad, but losing a few percent of every run is not ideal.

Everything I am saying is contained within the Support Center article. GPS is complicated and bottom line, the distances are going to be different. You can wear 10 watches on your wrist, you will be lucky if 2 match.

Think of it this way, we as humans are an ant on the planet at best compared to the distance of the minimum 4 GPS satellites orbiting the planet that are required to position us. Meanwhile, the Earth itself is rotating at 1,000mph just to make things even more interesting.

It's extremely complicated and the algorithms running to position everyone using GPS are practically magic.

It doesn't explain why fenix 6 watches make every run shorter, and fenix 7 doesn't. I've tested it in during various trail running events - i could see on strava other people who participated with me, and their new gen Garmins were all pretty much accurate when it comes to final distance. Every person who used a fenix 6 series watch ended up with a shorther final distance. It's not luck, clearly there's a pattern here. I can send you the evidence, if needed.

5925888 said:

and fenix 7 doesn't.

The Fenix 7 is a different animal altogether due to hardware changes to improve GPS along with different software. For example, a Fenix 7 sapphire versions and the newer Fenix 7 Pro/Epix Pro series both connect to a lower level "Multi-Band" GPS constellation that vastly improves GPS tracking metrics. Also, in our current Quarter 4 Beta phase that will lead to a new official software update before the end of the year, India's GPS satellites have been added to the entire Fenix 7 family of devices. (Currently, the Fenix 6 series includes: GPS = USA. Glonass = Russia. Galileo - EU. The Fenix 7 series family is about to add NAVIC GPS satellites = India after the next update is released.)

There is fore sure a hardware component to this phenomenon. But looking at the original post, the raw GPS track has a more accurate distance than what Garmin is displaying, so the problem must originate (or at least be further amplified by) some post processing that Garmin is doing on the raw GPS track. It is a long known issue in the F6 community that although the distance from the raw GPS track is quite accurate, the distance reported in the FIT file is too short. There are countless of reports here on the forums of users who compared the raw GPS track distance to the distance in the FIT file and the raw GPS distance is in most cases more accurate. 

A popular theory among the community member is that Garmin, when calculating the distance, tries to correct possible GPS track inaccuracies (e.g. jumps, jittering) using a correction algorithm, but in most cases, this is overdone so that the result is an artificially shortened distance.  

There have been multiple discussions on Fenix 6 forum about this issue. I observed this issue for a long time, first on Fenix 6X and then even on Fenix 7X, and I think that fundamentally this is a software issue. There is a faulty algorithm that is perhaps amplified by hardware limitations in Fenix 6. I also think that the same faulty algorithm has been inherited by Fenix 7, but in the case of Fenix 7 most users don't see any issues because the new GNSS chipset is so much better.

There is a hint to the root cause of this issue in the ConnectIQ developer API (https://developer.garmin.com/connect-iq/api-docs/Toybox/Position/Info.html):

var speed as Lang.Float or Null
The horizontal speed in meters per second (mps).

Speed is derived from the most accurate source in the following order:

- GPS

- Foot pod

- Accelerometer

According to that the speed source switches between the 3 sources, using only one source at a time that the Garmin software chooses as the most accurate one. I'll explain how that is related to the distances issue discussed here.

In the same SDK document slightly above we can also see the following:

var accuracy as Position.Quality
The positional accuracy.

This is given as one of the following values: good, usable, poor,
or not available, which corresponds with the Position.QUALITY_* constants.

So we can see that the watch continuously evaluates the quality of the position and chooses the source of speed based on that. That doesn't explain how it calculates changes in distance, but I strongly suspect, that when it considers the position quality to be less than "good" it no longer trusts GPS as the source for speed and at the same time stops using it for calculating the distance. Instead it calculates the distance from speed over time using integration.

Perhaps the position quality is provided by the GNSS chipset firmware, so perhaps in the case of the Sony chipset used in Fenix 6 it is to sensitive to multipath errors, so perhaps it switches from the "good" quality to "usable" or "poor" when there are trees around. I don't know that but suspect that is the case. And perhaps that is different with the new Airoha GNSS chipset used in more recent Garmin watches.

I think the root of issue is that one single source of positional data is used at the time rather that fusing all possible sensors continuously with different weights. If you read about Kalman Filter, that is the algorithm that can take input from multiple noisy sensors and produce an output that is more accurate than any of the inputs taken separately. I don't know if Garmin uses Kalman filter algorithm, but I doubt that because otherwise they wouldn't mention choosing only one most accurate source of speed. With the Kalman filter all sources of positional data would be fused together, so there wouldn't be one most accurate source.

One of my regular run routes goes through a park where I first run on a trail under a lot of tall trees, then it goes onto a meadow with open sky above, then after a short distance it goes back under the trees. When running with Fenix 6X I noticed that every single time when I ran on that trail and entered the meadow the pace displayed on my watch sped up by about 2 min/mile without me changing anything. Then as I exited the meadow and entered the tree covered trail it dropped back to 2 min/mile slower pace. I reproduced that consistently and the change in pace was always very fast - within less than 10 seconds. So that was a strong evidence that the source of speed was switched from accelerometer to GPS, and back to the accelerometer as I entered the open sky meadow and then exited it again. With Fenix 7X I can still see the same changes in the speed when dual-band GPS isn't enabled, although the changes in pace are smaller. Still, I observed sharp unexplained changes in pace for up to 1 min/mile. That tells me that the same algorithm from Fenix 6 still exists in Fenix 7.