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/

The Garmin guide is intended to be generic, so it doesn't go into the specifics of the GPS Team Challenge or GPS-Speedsurfing.

Anyone taking part in the GPSTC should obviously try out the datafield by TBWonder, and always use multi-band on their FR 255.

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.

Select to expand quote

remery said..
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.

I think that may have been based on information that I recently provided to sailquik.

I've annotated the inside of a FR 245 which shows the Sony GNSS chip and the antenna inside the rim of the top of the watch. The contacts of the GNSS antenna are circled. There is a second antenna for ANT+ / bluetooth low energy / bluetooth in the rim by the up + down buttons. The original photo was courtesy of www.ifixit.com/Teardown/Garmin+Forerunner+245+Music+Teardown/150396

Other teardowns (including fenix models) show the GNSS antenna in the same place, at the top of the watch. Teardowns of various Garmin watches have links at logiqx.github.io/gps-details/devices/garmin/watches/

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

The spikey positional speeds looks like the "frozen positions" issue that I documented in "data niggles".

logiqx.github.io/gps-details/devices/garmin/review/

Sometimes it will be extremely prevelant in the Garmin data, sometimes not present during an entire session.

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

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.

gpsspeadreader gave very similar reults to the motion, but KA72 gave quite different results, So I guess your work arounds are already good. File coming over.

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

decrepit said..

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.

I've got plenty of examples which I can share if they are useful? I always wear my watch on top of my wetsuit.

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.

I've seen this intermittently when testing the FR 255, and I always wear mine over my wetsuit. Here is an example track from a windsurfing session, recorded as multi-band back in July. It happens regardless of the GNSS settings as I've seen it with GPS, all systems, and multi-band. It appears to be an NMEA handling issue and I've seen it in older watches as well.

There are actually two variations of this glitch; identical position followed by a double-distance jump (e.g. screenshot of remery's session), and double-distance jump followed by an identical position (e.g. screenshot below). This particular session contains both variants at different times.

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?

Select to expand quote

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

This may help with diagnostics - www.ka72.com/Track/t/537950

KA72 produces slightly different results to GPS Speedreader and GPSResults.

This includes 10s #4 + 10s #5 and the alpha.

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

The FIT File Viewer illustrates it quite nicely. It can be seen that lat + lon + speed sometimes don't change. The same values are simply repeated for 2 seconds. Metrics from the other sensors (including altitude / elevation which is from the barometer, not the GPS) are updated throughout. Interestingly the odometer is sometimes updated, but sometimes it is not updated.

I've yet to see this behavior on my fenix 7 pro, but I've not been testing it for nearly so long as my FR 255.

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

Select to expand quote

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

Currently, GPS Speedreader takes the data as provided by the GPS. For points that simply repeat the previous position and speed, this is somewhat questionable. The repeated position and speed really indicates that the watch/GPS has not provided a valid solution for this point, for whatever reason (seems poor signal from covering the antenna is one possible cause, but not the only one).

There are several other possible ways of dealing with such repeated points that make more sense. 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 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

There may be 2 scenarios, because with our testing of random sailors sending in comparisons, on a t least 3 occasions when there was a significant difference between watch and reference, using KA72, the wearer had wetsuit material against the watch.
So we have known that wetsuit against the watch produces bad results.
Because KA72 ignores missed points, it can be concluded that the bad results we saw is also because of missed points.
1 scenario causing a problem, doesn't rule out a 2nd scenario causing the same problem.

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.

So if I understand Mike (decrepit) correctly, there are some observations where covering the watch partially gave files with results that seemed less accurate than usual, and where the watch was partially obscured by neoprene (?) watch protector bands or a bunched up wet suit. At least some of these files also had "repeated" points. Details, however, depend a bit on how the data are analyzed, since ka72 gives different results than Speedreader and GPS Results on (some of?) these files.

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). Here's an example:

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.

I did also do a similar test where I enclosed the watch in several layers of aluminium foils to block the GPS signal. When fully enclosed, the watch simply stopped reporting speeds (but kept reporting heart rate etc.).

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.

While I say it was over the wetsuit, it was on my writs with the sleeve all the way down. The FIT file from the 8th, that doesn't have any spikes at all, was further up my forearm.

I thought I was doing the right thing starting a new FIT file when I moved the position of the watch, but I realise now that it makes it hard to compare the KA72 speeds for the day to two individual files.

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.

Regarding testing of the watch next to a wet sleeve, or under a neoprene protector. That testing is definitely worth doing but it will need quite a few sessions before it is possible to establish whether there is a causal relationship, rather than a spurious correlation.

This shows a session with my FR 255 over my wetsuit, but towards the end of the session the repeat values suddenly become highly prevalent. If it's a software issue then even the slightest of changes in timings could cause the behaviour to start and stop.

@remery - can you share a link to the files on KA72 so that I can download them and have a look? tia!

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

K888 said..
@remery - can you share a link to the files on KA72 so that I can download them and have a look? tia!

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

( I hope I chose the correct files)

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?

I used TBWONDER's GPSTC Approved datafield.

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.