Thanks Rob, that should give the boffins something to chew over.

End of a long day and I'm not really over my COVID infection, so just a couple of passing comments.

I sometimes see these sustained periods of repeated speeds suddenly start mid-session, then often times stop again and the rest of the session can go back to normal. So the big question is whether in the last quarter of the session did it start because of the sleeve, or would it have happened anyway? Would it have gone back to normal if allowed more time? Something tipped it over the edge, but was it simply chance, or was it genuinely provoked?

It's an interesting observation that occasionally the speed is not frozen. I also see something else on rare occasions, whereby the doppler-speed is zero but positional speed is fine.

I'll look more closely tomorrow and perhaps find time to do some testing with impaired signals.

Additionally, reporting to Garmin would probably be a good idea in the near future. Perhaps after a little more fact finding, something clear and unambiguous can be worded, but need to choose the wording carefully. I know a developer who asked for the doppler speed to be written to their GPX files (since they have a GPX extension for it) but the support team said they'd never heard of Doppler speed.

FIT and OAO files uploaded to KA72.

I like the wetsuit exclusion band!

Seems to have worked, totally clean speed graph.
This was over and hour that it's clear, and yet when the wetsuit could "ruck up" you had the odd positional spike. And when you had the wetsuit hard against the watch, you had positional spikes everywhere!
Case closed as far as I'm concerned.

Select to expand quote

decrepit said..
This was over and hour that it's clear, and yet when the wetsuit could "ruck up" you had the odd positional spike. And when you had the wetsuit hard against the watch, you had positional spikes everywhere!
Case closed as far as I'm concerned.

You are privy to more data than I am. How many times has the issue affected remery?

To be scientific and prove an association it needs to be demonstrated beyond reasonable doubt. We'd look to test the null hypothesis (assume the issue occurs randomly) and try to prove that there is a suitably low probability that the quirky results are not by chance, typically < 5% chance.

There may be a causal link, but it I'd like to understand how many sessions are afffected when next to a rucked sleeve, versus sessions affected (or not) on top of the wetsuit. Within this thread, I've seen one affected session which happened to be next to a rucked sleeve which is not enough to reject the null hypothesis.

Like I showed in my own data, identical results can happen when worn on top of the wetsuit. I'd like to understand this better, so I'll contact remery and try to get hold of all relevant data. KA72 isn't allowing me to download all of his files.

Like Peter (boardsurfr) said there are quite a few possible explanations for the issue and I do agree that it may indeed be that poor signal reception can trigger it. My main point is that 3 or 4 tests sessions are not enough to be conclusive, if it were random. Toss a coin 4 times and we might expect 2 heads, but 4 tails would not be surprising and would not be proof of a biased coin (or toss).

But is your wetsuit a bit loose?????
That's what Remery found, the watch was on top of the wetsuit, but the wetsuit isn't tight, so there are small folds that can still touch the side of the watch. That's why he's moved the watch to his upper arm where the suit is tighter, and used broad tape over the wetsuit to form a barrier.

Salt water laden neoprene is a good electrical conductor, and the wetsuit arm then becomes a good ground. I think this can (short) any RF signal to earth. But my Radio theory is decidedly rusty.
I'll ask Peter about his tests, if the neoprene wasn't soaked in salt water, it doesn't mean very much.

Let me know what files you need, I thought I made them all Public, but I only uploaded the Motion files to GPSTC.

I've looked at some of my files, worn over a light rashie,
2.5 hours worth no spikes


And here's another over a light rashie.



not quite 2 hrs of data, still no spikes.





Almost 4.5 hours again on my bare wrist. So in total that's over 8hours of data with no spike from me, plus what Rob did today, and one of his earlier sessions. But as soon as it's on a wetsuit you get the odd spike, as soon as it touching a rolled up wetsuit sleeve you get lots of spikes.

May not be absolute undeniable proof. But I'll make a bet, if I wear a rolled up wetsuit sleeve against the watch, you'll see lots of spikes appear.

Select to expand quote

decrepit said..
I like the wetsuit exclusion band!

Seems to have worked, totally clean speed graph.
This was over and hour that it's clear, and yet when the wetsuit could "ruck up" you had the odd positional spike. And when you had the wetsuit hard against the watch, you had positional spikes everywhere!
Case closed as far as I'm concerned.

There are some spikes at no speed, I htink that that's when I deliberately put my hand under water as I did on previous days.

Select to expand quote

K888 said.. I've seen one affected session which happened to be next to a rucked sleeve which is not enough to reject the null hypothesis.

I thought you'd seen Daffy's files from a watch protector causing the same thing, admittedly the watch protector goes all round the watch, but I think it's the same issue, salty wet neoprene against the watch rim.

Select to expand quote

decrepit said..

Almost 4.5 hours again on my bare wrist. So in total that's over 8hours of data with no spike from me, plus what Rob did today, and one of his earlier sessions. But as soon as it's on a wetsuit you get the odd spike, as soon as it touching a rolled up wetsuit sleeve you get lots of spikes.

May not be absolute undeniable proof. But I'll make a bet, if I wear a rolled up wetsuit sleeve against the watch, you'll see lots of spikes appear.

I wish I remembered what I did on the 8th, the first time I tested the watch. There were no spikes that I recall. Maybe because it was over the wetsuit and I didn't put my arm in the water to clear the fin. As you know I am familiar with scientific experiments, the null hypothesis and importance of 95 percent fiducial confidence.

Select to expand quote

decrepit said..
But is your wetsuit a bit loose?????
That's what Remery found, the watch was on top of the wetsuit, but the wetsuit isn't tight, so there are small folds that can still touch the side of the watch. That's why he's moved the watch to his upper arm where the suit is tighter, and used broad tape over the wetsuit to form a barrier.

Salt water laden neoprene is a good electrical conductor, and the wetsuit arm then becomes a good ground. I think this can (short) any RF signal to earth. But my Radio theory is decidedly rusty.
I'll ask Peter about his tests, if the neoprene wasn't soaked in salt water, it doesn't mean very much.

Mine are all very snug on the arms, so much so that I can't fold them back, which is one of the reasons that I wear my watches on top. I will see what I can glean by gradually adding layers of foil whilst driving around my usual test circuit, since I can't sail at the moment. It's by no means the same as wet neoprene but the degradation in signal might provide some useful insights.

It is probably worth remery also testing the GPSTC datafield in cycling mode. When I first started testing the FR 255 in April last year, I found the issue (albeit typically no more than a handful of glitches per session) only occured in the activity modes with minimal filtering. I was never able to provoke the issue in cycling mode which implements some additional filtering.

Last night, I also re-confirmed the issue occurs regardless of whether using all systems, or multi-band so that is not a factor. Even if the the Airoha chipset stops outputting solutions at 1 Hz, I feel the watch should be able to handle it better and continue logging at a solid 1 Hz in sync with the available NMEA data.

Select to expand quote

decrepit said..


I thought you'd seen Daffy's files from a watch protector causing the same thing, admittedly the watch protector goes all round the watch, but I think it's the same issue, salty wet neoprene against the watch rim.

I wanted to get a screen protector for the Garmin and decided against one of these given the spikes.

Select to expand quote

decrepit said..

May not be absolute undeniable proof. But I'll make a bet, if I wear a rolled up wetsuit sleeve against the watch, you'll see lots of spikes appear.

That would certainly be a useful test, perhaps even relocating your watch every 20 minutes if it's not too much trouble.

Select to expand quote

decrepit said..

I thought you'd seen Daffy's files from a watch protector causing the same thing, admittedly the watch protector goes all round the watch, but I think it's the same issue, salty wet neoprene against the watch rim.

The neoprene-affected files that I saw from Andrew showed an obvious degradation in the accuracy and precision of the data from the watch(es). I don't recall any of those files containing periods with excessive repeats of lat + lon + speed, just the usual intermittent repeats that I'm used to seeing in my own files.

I also checked every file from my fenix 7 pro and unlike the FR 255, I haven't seen the issue happening routinely. After more than a dozen test sessions, I've only seen one session with a couple of glitches, whereas the FR does it almost every other session. However, the two watches have completely different firmware, antenna designs and the fenix 7 has a much faster processor so can't really read much into it.

At the moment it's too warm for me to wear a wetsuit, I don't know how Remery does it without completely dehydrating!
But as soon as it cools down a bit I'll give it a go.

Select to expand quote

decrepit said..
At the moment it's too warm for me to wear a wetsuit, I don't know how Remery does it without completely dehydrating!
But as soon as it cools down a bit I'll give it a go.

Haha! I say wetsuit, but its just something similar to this...

I've tried to do some substantive testing and perhaps gleaned a few additional insights into these watches.

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

Two points from the discussion section:

- There is no clear relationship between poor GNSS signals and repeated values. There were only 4 occurrences in total during the 16 trials on Garmin watches, all of which occurred on the Forerunner 255. Half of the occurrences were whilst the watch was wrapped in foil, and half whilst the watch was operating normally. Yet, half of the trials had severely degraded signals due to the foil, sometimes to the point where there was no GNSS data.

- The fix quality indicator written by APPro provides some additional insights, both in terms of solution quality and the manner in which fields are written to FIT files, including how they persist if they are not updated in time for the next FIT record. The FitContributor documentation mentions an issue with time sensitive data, how values may be lost if not already written, and there is also an implication that values will persist, if not updated.

Feedback welcome on the general approach, findings and discussion points.

I'm keen to get to the bottom of this issue of frozen / repeated values, so Scott Simms has kindly agreed to my request for a private beta of APPro which will log some additional diagnostic data. Just for the sake of clarity, I'll try to describe what I think is going on based on the Garmin documentation, discussions amongst Garmin app developers and my past life as a C developer.

The Airoha transmits NMEA data every second, which is an asynchronous serial protocol. The Garmin has to consume the NMEA sentences character-by-character, parse the different sentences and combine the data prior to actual processing of position and speed. Skip past all of the system / app / datafield processing and there is a background thread (or process) which writes one record per second to the FIT (or whenever changes occur, when using "smart" recording), simply writing whatever data is present.

In between the NMEA consumption and FIT writing is where things can easily go awry, because event-driven processes and the various listeners may not always fire at precise time intervals. This is where the synchronisation / timing could lead to what I referred to as race conditions, where multiple threads / processes are racing against each other and the timings impact the outcomes. Anyways, the logging in APPro will provide two important pieces of diagnostic data every second - system timer (milliseconds) and GPS time.

The milliseconds timer will tell us if the location events fire at regular intervals. I don't expect to see every 1000 ms like clockwork, but how much will it vary - 800-1200 ms, 700-1300 ms? Do the absolute times of the location events slowly drift? Additionally, the GPS timestamp will also be interesting when we get frozen / repeated values of lon + lat + speed. If the GPS timestamp is repeated, then it may suggest a Garmin glitch, not Airoha. I'm confident the additional diagnostics will show something useful, so I will look forward to the testing.

In terms of on-the-water testing, the person who is probably best placed to do some "wet neoprene" testing is sailquik with his two FR 255 watches; one impaired, one normal. I fully expect to see degraded data (accuracy and precision) from the watch that has an impaired signal but over a number of sessions it will be possible to gather some statistics as to how many sessions are affected by the frozen / repeated values. Again, time will tell if there is a relationship and whilst I remain sceptical, I'm keen to see some data from multiple sessions.

Interesting experiment!! can't wait to see the results

I had a closer look at the GPS metadata this evening.

The write up is at logiqx.github.io/gps-details/devices/garmin/metadata/

TBH, I'd never really payed it much attention before now, but perhaps some interesting observations.

Today will sail for a while with the Garmin sitting on duct tape over the wetsuit sleeve, then move it next to the rolled up sleeve. Without saving the file between changes.

We can combine the files, so they are continuous

OAO and FIT files uploaded.

Select to expand quote

remery said..
OAO and FIT files uploaded.

Thanks. The single FIT file is preferable imho. If the underlying issue is timing related, then starting a new session is effectively rolling the dice again and introduces an additional factor.

In terms of this session, just one occurrence of frozen / repeated values. It occurred at 07:38:22 UTC, about a third of the way into your session (watch on duct tape?), whilst standing in the shallows.

Back to the topic of GPS metadata, I think that I may have come close to solving that little mystery now.

- Speeds in FIT records are filtered according to the sport profile.
- Speeds in GPS metadata use generic filtering, regardless of the sport profile.

This shows the difference between FIT records for kayaking and other, during a short test drive (Fenix 7 Pro and FR 255).


This is the GPS metadata from both watches, during the same test drive.


Just for clarity, these are the speeds that end up in Speedreader. It can be seen how the "other" activity (red) compares favorably to the Motion (green), whilst the kayaking activity (blue) implements some heavy filtering / smoothing.


To summarise, GPS metadata contains speed data that is filtered in the same way, regardless of the sport profile. It's still not the raw Doppler-derived speeds and the purpose is still unknown, but I have a suspicion it may be used for pacing, or "live" speeds.

Full investigation at logiqx.github.io/gps-details/devices/garmin/filtering/

Today I went back to the same spot using the same gear. Did about 4 runs with the Garmin kept dry and on duct tape. Then a couple of runs still on the duct tape but after dipping in the estuary. Then a couple of runs next to the rolled up wet sleve. Then a couple of runs with the sleeve moistened with filtered tap water. Negligible position spikes and almost identical results compared with the Motion and analysed by KA72 and GPS Speed Reader.I have no idea what was different the previous couple of sessions that had spikes and speed discrepancies.

Select to expand quote

K888 said..

Thanks. The single FIT file is preferable imho. If the underlying issue is timing related, then starting a new session is effectively rolling the dice again and introduces an additional factor.

In terms of this session, just one occurrence of frozen / repeated values. It occurred at 07:38:22 UTC, about a third of the way into your session (watch on duct tape?), whilst standing in the shallows.

Yes I reckon 07:38 UTC was after a few runs keeping the watch dry on duct tape, dipping in the water for a fin check, then taking off.

Just be reconciled to the fact life is weird and unpredictable.
It's all an illusion anyway.