[edit to add CAT4] and one more suggestion at the bottom]
Garmin OWS Potential Issues and potential improvements.
Using the Epix (with similar results on F6) during OWS and using FIT Decoders I can see why I am (and others) are still having issues with OWS distance accuracy. Essentially the OWS can be categorized into three categories which will provide varying results which I will list below. I am having issues with category three and will try to explain below.
CAT 1: Based on swim style, etc, a GPS signal is maintained throughout the swim and this provides the most accurate results. This of course is the desired state but for me this stopped working with the F6 and now Epix Gen 2. With prior watches such as 910xt, F3 and F5 is was in this category with good GPS signal throughout my swim. Alas, this is no longer the case since F6 and Epix.
CAT 2: Mostly no GPS signal is obtained and the SW uses an algorithm which will use “cadence” (strokes per minute) to estimate distance or speed. This is not a bad estimate and provides a mostly believable results.
CAT 3: This is when GPS keeps being lost and re-established, many times during an Open Water Swim. If this process of connect/disconnect happens a lot, an error is accumulating which cuts down the total distance in a more considerable way. I will explain this issue below.
CAT 4: This is when GPS is re=acquired but is seriously out of whack and normal pace in the neighborhood of 1m/sec suddenly jump to 10m/s. If you think of 10m/s that would be 100 meters in 10 seconds, clearly a huge error. When this happens you end of with a much longer swim distance. Example from FIT decoder below at the "enhanced speed column":
,
Issues with CAT 3.
I have observed this over a few swims but will mostly refer to a recent swim file from a Half Ironman which cut my total distance by around 300 to 400 yards. As you can see from the below figure 1. The issue is not during the time GPS is lost (dashes for GPS points) because during that time the algorithm uses “cadence” for speed/distance, ie, it uses .774 m/s for the ES (Enhanced Speed). However, as soon as GPS is re-established, the watch takes a long time to ramp up to the correct speed. During this ramp up duration, we are losing distance. The two columns that show GPS coordinates have “dashes” when no GPS signal is available. During that time you can see a constant value is used for what Garmin calls “enhanced speed”. In the example in figure 1, the ES is .774 m/s. This value will change if the cadence changes and is part of CAT 2 method which works well enough. Now, take a look at what happens when the GPS signal is returned. As can be seen, the enhance speed starts of being very low, ie, 0.1 m/s, where in reality I am still swimming at my normal pace. This low reading persists in some cases for up to 45 seconds until the GPS “stabilizes” and the ES is close to real. This is the crux of the issue. As an estimate, let’s say that the ramp up takes 20 seconds. At my pace let’s again assume an average speed of .75 m/s(meters per second). I will approximate and say that because of the ramp up, the values used are an average of .25 m/s and therefore I lost .5 m/s. In this example, with 20 low reading, I therefore lost .5 m/s for a total of 10 meters lost. Now, imagine (which is true for my swim during the triathlon) that the GPS signal is lost and re-acquired 25 times. Than on average, in my example I would lose 10 meters times 25 for occurrences for a total of 250 meters lost or cut short (273 yards) which is close to what I was short during my last OWS.
Potential Fix
I will leave it to Garmin, as I don’t have knowledge as to why this “ramp up” in distance/speed happens every time a GPS is signal is acquired (after a disconnect). I am hoping that something can be done but if not, can they improve their logic (SW algorithm) somehow? What if their logic said something like the below:
- If swim activity is in process and GPS was lost and re-acquired is TRUE ( starting at 7:44:08 below)
- Until the “enhanced speed” is within 80% of where it was just before GPS was lost, continue to use the “cadence” based constant for ES.
Example of the above new and improved logic. From 7:48:08 to 7:44:15 the enhanced speed is not within 80% of the last known speed sample of .694 m/s, so use the constant of .774 m/s (from cadence) during those “bad” 8 samples. This will remove the “ramp up” error and provide great improvements.
Potential fix 2: If the track looks close to correct, Strava has a feature where you can "auto correct distance" based on the track. I have done this a couple of times and when Garmin cut the distance short but the track looked close to real, Strava auto correction brought it closer to reality. Garmin should also have this feature to post process the track and estimate distance based on the track and map distances.
