Garmin Advice

I've written up some general advice for Garmin watch users.

Hopefully it will be useful whether you are taking part in GPS-Speedsurfing, GPSTC, or simply sailing recreationally.

You can find it at logiqx.github.io/gps-guides/guidance/garmin/

Note the comment from Decrepit that a rolled up neoprene sleeve next to the the three button side of the the watch, could cause problems. I hope to test this in the next couple of days.

It's surprised a few of us, that the antenna is on the rim, and is obscure by anything touching the rim.
a rolled up wetsuit sleeve or a "watch saver" can give very bad data.



This is from Remerys session a few days ago, when he had the watch next to his rolled up wetsuit sleeve. From now on he''s wear the watch on top of his wetsuit.
The spiky stuff is positional data speed. This would normally follow the doppler speed data closely, with good satellite reception.
Ka72 gave some strange results, that's what alerted us to the problem

Select to expand quote

decrepit said..
It's surprised a few of us, that the antenna is on the rim, and is obscure by anything touching the rim.
a rolled up wetsuit sleeve or a "watch saver" can give very bad data.



This is from Remerys session a few days ago, when he had the watch next to his rolled up wetsuit sleeve. From now on he''s wear the watch on top of his wetsuit.
The spiky stuff is positional data speed. This would normally follow the doppler speed data closely, with good satellite reception.
Ka72 gave some strange results, that's what alerted us to the problem

I think the image looks worse than things actually are. Seems the Garmin prioritizes getting a speed solution over getting a position solution, and sometimes just repeats the old position data. While the positional speeds shown may be technically correct, they are somewhat misleading, since we already know that repeated positions should be ignored, and the next positional speed should therefore be calculated over 2 seconds instead of one second. I've put some initial workarounds in, but there's more work to be done. If you could email me this file, that would be great.

Select to expand quote

K888 said..
It's intermittent on my FR 255 and I've seen it on earlier Garmin watches as well.

As far as I'm aware, we've only seen it when we get a bad comparison with another GPS, and the user has something next to the rim.

Select to expand quote

boardsurfr said..

decrepit said..
It's surprised a few of us, that the antenna is on the rim, and is obscure by anything touching the rim.
a rolled up wetsuit sleeve or a "watch saver" can give very bad data.



This is from Remerys session a few days ago, when he had the watch next to his rolled up wetsuit sleeve. From now on he''s wear the watch on top of his wetsuit.
The spiky stuff is positional data speed. This would normally follow the doppler speed data closely, with good satellite reception.
Ka72 gave some strange results, that's what alerted us to the problem

I think the image looks worse than things actually are. Seems the Garmin prioritizes getting a speed solution over getting a position solution, and sometimes just repeats the old position data. While the positional speeds shown may be technically correct, they are somewhat misleading, since we already know that repeated positions should be ignored, and the next positional speed should therefore be calculated over 2 seconds instead of one second. I've put some initial workarounds in, but there's more work to be done. If you could email me this file, that would be great.

GPS Speed Reader analysis of the Garmin file was very close to Motion and DIY-GPS, But KA72 resulted in quite differrnt alpha and very different 5x10.

As.soon as as the wind returns I will test Garmin on top of the wetsuit along with Motion, DIY-GPS again, and perhaps GW60. Just to make sure the watch is not faulty.

OK, so we can't use this as an indicator of a badly worn watch.
It would be interesting to know what affected KA72 if it wasn't this.

K888 can you post one of your examples to KA72 and see how that compares to speedreader please?

Yes Peter has explained it's the way gaps in the data are handled.

Thanks K888,
I'm assuming missing data is more prevalent, when the wetsuit sleeve is up against the watch

I have a different view about why this happens, and I don't think it is to do with reception, or the ability of the GNSS chipset to produce a PVT solution. I suspect it is simply a race condition (i.e. threading related), and how the NMEA sentences are being consumed.

There are the two manifestations of the issue.
- The first is most common and illustrated in the post above (i.e. repeated PVT solution then a big catchup)
- The second is completely skipping a PVT solution, essentially doubling the distance travelled and then repeating those same values.

The timestamps in the FIT file are based on the Garmin system time. This is different to both GPS time (which can be converted to UTC) and the local time (displayed to the user). We already see random offsets in the FIT files (typically 0, 1, or 2 seconds) and if you manually change the time on your watch you can also shift the data by as many minutes as you wish. I did some testing around this recently. The Fenix 7 has some nice logging which shows how these 3 timestamps relate to each other, and how they differ.

Every second, the watch is bundling all of the current data together (e.g. GPS, HR, barometer, thermometer, etc) and saving a record to the FIT. In an ideal world this would be centred around the GPS timestamps, but I do not believe it is doing that.

It would appear to me that it is simply using the latest consumed NMEA message(s) and that any slight variations in the timings of NMEA consumption and generation of FIT records (almost certainly separate threads) causes it to skip PVT solutions, or repeat solutions.

I could detail the NMEA sentences that I believe Garmin are using and how one of them does not contain timestamps, which would explain why they might be doing something as simple as I have described above.

Also, there is no evidence of poor quality adjacent PVT solutions when either of these 2 scenarios occurs, which one should probably expect when reception is poor. Additionally, one should also expect the Kalman filter to prevent any solutions that are identical to the previous one (scenario 1) and would be unlikely to generate solutions that double the distance travelled in a second (scenario 2).

I can't prove this is the cause, but a simple race condition would explain both scenarios - en.wikipedia.org/wiki/Race_condition

Select to expand quote

boardsurfr said..>>> The most straightforward approach is to interpolate both speed and coordinates from the two neighbor points. This will also usually be the most accurate approach. This is especially true if the repeated point is at the start or end of an alpha run.

To illustrate this, here is an example of a repeated point in the blue Garmin data, with Motion data in red for comparison:
The point at the vertical line is repeated: it has exactly the same value as the the previous point, and the positional speed (blue dashed line) is 0. A speed value that's the average of the previous and next point would be lower, and closer to the speeds that the red Motion data show.

I agree, that looks like the best way of doing this, but can we get everybody else to agree. It would be really good if we get the same results from every analysis program.

Motion plus 2 FIT files just uploaded to KA72. The earlier FIT file is on the wetsuit sleeve. The later smaller one is next to a rolled up sleeve.

Select to expand quote

boardsurfr said..
One question is if obscuring the watch actually causes repeated points, and thereby differences in results by different analysis programs. Mike (K888) seems to doubt that. Correlation is not causation, after all (and especially not spurious correlation).

I did some tests in the backyard, walking in circles, covering the watch to different extends with a double layer of wet neoprene short (about 3-4 mm think when doubled). The first part is with the uncovered watch; part 2 with the left (3 button) side of the watch covered; part 3 with the entire watch covered; part 4 with the entire watch covered and facing the ground, simulating an underhand grip.

In this test, there is exactly one repeated point with a doppler speed above 0. That's at the very beginning of the track, with the uncovered watch. This test does not support that covering the watch antenna with neoprene causes point drop. It's just one test, but easy to repeat.

That's really some nicely thought out and executed testing Peter, nice work! Part 4 (watch upside down and covered) really jumps out at me with a clear bias being introduced, causing the positional and Doppler speeds to become quite separated. Small detail but the GNSS antenna is adjacent to the strap fixing, between 11 o'clock and 1 o'clock.

Regarding inaccurate results when the watch is fully or partially covered, I've seen numerous test tracks from people (via sailquik) where I looked at the data and immediately noticed it was not as good as would usually be expected. My immediate response was always to ask whether they had their watch covered by neoprene or lycra. In all cases, it turned out to be a watch protector or wetsuit sleeve.

The repeated points is not an uncommon issue, so it will sometimes coincide with an obscured antenna. It happens with my FR 255 which is never covered and has always struck me as a software issue. I could write a software simulator to demonstrate the effect, but would prefer not to spend time doing so. I'm pretty sure that it is simply a consequence of software architecture / design / implementation.

Regarding interpolation, it would be an effective way to handle some instances of this Garmin nuance. Simple linear interpolation would suffice as it makes it easy to implement. I mentioned two distinct cases and they both require slightly different handling. The first needs to replace the repeated values with interpolated values, whilst the second case needs to replace the values prior to the repeat with interpolated values.

Here is a screenshot of the second case (first example in this thread), but with some simple mental arithmetic you can see how it's the first record of the first two pairs which is incorrect. The record that belongs at 14:23:01 was skipped. Likewise for the second pair. The third pair is actually a third case, where the record at 14:23:08 is incorrect, if you look at the changes in lat / lon.

This third case actually makes things somewhat more complicated as you would need to shift 14:23:08 and 14:23:09 forwards by 1 second and then calculate a new 14:23:08 using interpolation. I suspect there would be some more complicated scenarios to handle as well and it might get rather tricky when they are jumbled together. TLDR - it's not just the repeat values that are problematic!

Anyways, this very much looks like a software issue and maybe more pronounced on the watches with a slower MCU.

It's possible that your interpretation is correct, but it relies on a bunch of assumptions, for example that your diagnosis of the underlying problem is correct. Alternative explanations exist, and any proof what's really happening would require "listening" to the GPS chip in the watch.

There are a few other weird things going on, too. One is that the offset between positional and doppler speed data is not always constant (the same is true comparing doppler speeds to other watches). Some tracks show a separation, others recorded with the same setting do not. That is usually, but not always, constant for a session. In remery's example that decrepit sent me, the offset switches multiple times in the file. In your NMEA / race condition theory, that could be explained by speed and position being handled separately; however, this would create additional problems.

But more importantly, what you suggest is simply to complex. Rather than a simple interpolation, you're now talking about first requiring an accurate problem category diagnosis, and then different fixes depending on the result of the diagnosis.

I wonder if there's any point in bringing the issues to Garmin's attention.

Select to expand quote

remery said..
www.ka72.com/Track/t/537971
www.ka72.com/Track/t/537972

Thanks. The Motion file for the session is at www.ka72.com/Track/t/537970

The first file has 149 repeated positions at non-zero speed in 4611 points (3.2%).
The second file has 248 repeated positions at non-zero speed in 1442 points (17.2%).

So in this case, having the watch next to the rolled up sleeve made things a lot worse, which is obvious when just looking at the files.

Just glancing at the first file, it seems most of the repeated points are 0 positional speed followed right away by doubled positional speed. There are some exceptions, though. One (at 15:03:49) has the position repeated, but the speed is updated.

Did you use APPro or the GPSTC data field to record the watch sessions?

Just making sure it's clear that I uploaded a Motion OAO file for the whole session, along with a FIT file for the first 3/4 is the session with the Garmin on the wetsuit sleeve, then the last 1/4 session with it next to the rolled up sleeve.