Select to expand quotedecrepit said..
Interesting experiment!! can't wait to see the results
Scott kindly provided me with a beta of APPro earlier today, so I've done some preliminary testing.
logiqx.github.io/gps-details/devices/garmin/pvt/
Preliminary findings suggest the potential for timing issues on the Forerunner 255, between the NMEA consumption and FIT writing.
I still have more testing planned, including analysis of timestamps around dropped points (aluminium foil) and repeated data (pot luck).
Now I need to focus on the jobs that I was supposed to be doing today, before I get into trouble! :D
Could the spikes I saw have something to do with the watch spending processor time on notifications, or heart rate measuring or something?
Select to expand quoteremery said..
Could the spikes I saw have something to do with the watch spending processor time on notifications, or heart rate measuring or something?
That's a possibility. It'll also be interesting to see if erratic timings are specific to individual watches, models, or ranges.
Once I've tested the latest beta (32-bit data types) it would be interesting to examine some data from other watch models - FR 955, 265, 965.
This should provide some insight, and perhaps whether it is a specific product team that have a less than optimal software implementation.
I'm out of time for the day, so I can't document my latest findings but I'd like to share these charts from an hour of walking.
Fenix 7 Pro and Foreunner 255
- time between location events
- millisecond timer mod 1000
Not only is the Forerunner 255 not handling location events every second, but the timing is also drifting. If the FIT writer is running every second then it's little wonder that weird stuff happens from time to time.
I'll investigate this in greater detail over coming days (pretty busy, so limited time) and document it so that Garmin can be contacted.
Note: I applied an offset to the millisecond timers so that the mod calculation is centred around 500.
The doppler speed output still follows the reference unit very closely, (using speedreader).
The main effect is on positional speed.
We've tested the doppler thoroughly, and GTC committee's findings that it's suitable for purpose ,should still stand, in my opinion.
However, if you use KA72, it does seem to cause a problem at the moment. If Dylan can duplicate Speedreader's results it will be fine.
I presume that KA72 2s calculations are done from doppler speed, but Alpha is a distance based measurement and perhaps 5X10 is done based on positional data. Probably also NM and 1 hour, but those longer times would reduce the effect of a repeated position.
Sounds like a managable fix if an algorithm can be developed to identify repeated positions and maybe interpolate from known good positions on either side of the repeated.. or just remove that position altogether and have a 2s period between the points on either side.
It makes sense to me from the Garmin end that if they have some issue causing them to miss a point, the most sensible thing to do is repeat the previous point. Would be nice if there was some sort of error flag to identify the data is known to be in error.
Select to expand quotevosadrian said..
I presume that KA72 2s calculations are done from doppler speed, but Alpha is a distance based measurement and perhaps 5X10 is done based on positional data. Probably also NM and 1 hour, but those longer times would reduce the effect of a repeated position.
All speed results, in all the currently approved analysis software are calculated from Dopper if available. (Which it is if you use approved device and approved file formats). Position is only used in the Alpha for the proximity circle (50m radius) which is probably less of a variable, or source of slight error than the sudden changes of GPS device orientation, and swinging around of the arm and body during the gybe. It has always been the case that Alpha results are slightly more variable and less accurate than the other categories due to these sources of error. Select to expand quotevosadrian said..
....... if they have some issue causing them to miss a point, the most sensible thing to do is repeat the previous point.
For missed points, the best solution is to interpolate between them, or take to average of the previous and next point. 
I looked at my dodgy FIT files with the Garmin Connect software, for those file with heaps of positional spikes, Garmin showed hundreds of thousands of "accel errors".
Select to expand quotesailquik said..
For missed points, the best solution is to interpolate between them, or take to average of the previous and next point.
If the Garmin did just interpolate between the points, you would be none the wiser that this had happened. There would be a faked data point that you have no way of knowing that it was faked. It is better in IMHO to allow the post processing software to do this interpolation after the fact. Then the bad point can be identified and the post processing software can get the same result anyway by doing the interpolation after the fact.
The datalogger should have the responsibility of faithfully recording the data. This means if for some reason it cannot momentarily, it should tell you rather than just make up data. Once you have the raw data, you can post process it to something suitable for purpose (filtering etc.).
In this case, it seems there is no mechanism for it to flag bad data via an error flag in the data stream.... but repeating old data is probably the best option since it is detectable (in the absence of an other error flag) and unlikely to cause an issue in most cases (other sports supported by Garmin). They could have just sent data with NULL (0) in the position parameters to indicate an error, but that would cause all sorts of issues if not handled correctly by processing software.
Select to expand quotedecrepit said..
Well done Mike, looks like you're onto it
Thanks. There are some further insights which I will also document. They are primarily of academic interest, but good to have documented.Select to expand quoteJohn340 said..
Is this issue fixable or is the 255 not suitable for GPS sailing?
There is the potential for Garmin to fix the timing issue, which I will share when it is fully understood and properly documented. My primary focus right now is establishing the precise nature of the issue, and the symptoms. Once fully understood, I expect suitable work arounds for GPSResults, GPS Speedreader, and KA72 will become apparent.
As decrepit stated the issue primarily affects positional speeds. The 250/500/1852/alpha results calculated from Doppler-derived speeds are hardly affected. The 255 produces really good speed results, and the timing issues have less impact on the Doppler results than the general performance of watch itself.Select to expand quotedecrepit said..
The doppler speed output still follows the reference unit very closely, (using speedreader).
The main effect is on positional speed.
We've tested the doppler thoroughly, and GTC committee's findings that it's suitable for purpose ,should still stand, in my opinion.
However, if you use KA72, it does seem to cause a problem at the moment. If Dylan can duplicate Speedreader's results it will be fine.
I agree 100% with all of these points.Select to expand quoteremery said..
I looked at my dodgy FIT files with the Garmin Connect software, for those file with heaps of positional spikes, Garmin showed hundreds of thousands of "accel errors".
That metric has an upper and lower byte (or word) representing different things, iirc. So it's not actually saying there were thousands of errors.Select to expand quotevosadrian said..
If the Garmin did just interpolate between the points, you would be none the wiser that this had happened.
...
Just for clarity, Garmin's responsibility would be to fix the timing issue affecting their event handling on the FR 255, not interpolation.
I'm pretty sure sailquik was referring to interpolation as a workaround that GPSResults / GPS Speedreader / KA72 can employ, so that the positional speeds don't look quite so yucky. In principle, there is an opportunity to slightly tweak the repeated doppler-derived speeds as well. Discussing the finer details about such a workaround should wait until the exact issue is fully understood, imho.
I'm going to be pretty time-constrained for the next few days, but I'll continue to investigate in the limited amount of time available.
Lastly, I'm actually quite relieved to discover it's a simple software issue. The root cause is fixable, but prior to any details going to Garmin I wish to determine which watches are affected by drift. The FR 255 is obviously affected, but preliminary results suggest the F7 Pro and FR 265 are unaffected. I have an old VA 3 and VA 4 which I can test, and I have friends with other watch series.
Thanks for all your good work Mike, it's invaluable to all the speed sailing community.
Select to expand quoteK888 said..
I'm pretty sure sailquik was referring to interpolation as a workaround that GPSResults / GPS Speedreader / KA72 can employ, so that the positional speeds don't look quite so yucky. In principle, there is an opportunity to slightly tweak the repeated doppler-derived speeds as well. Discussing the finer details about such a workaround should wait until the exact issue is fully understood, imho.
I might have misunderstood Sailquik. He responded to my quote regarding Garmin handling of this issue.
I do agree that in an ideal world, Garmin would fix this issue. It is probably fixable. But in the real world they have no responsibility to fix this, Garmin sells millions of watchs a year (approaching 20 million pa). Of that maybe a few hundred go to people who care about this issue (most use it for other sports not requiring a high level of accuracy). The massively vast majority don't care. If a very small fraction of a percent of their customer base want a bug fixed, it will be very low priority for them. I think it unlikely it will ever be fixed, but if it is, it is probably going to be some time.... so if a solution is required in the short term, it will probably have to be done in the post processing. It appears it is possible to do that.
Of course I would like to be proven wrong on that, so I am all for you bringing it to their attention to fix.
Select to expand quotevosadrian said..
I might have misunderstood Sailquik. He responded to my quote regarding Garmin handling of this issue.
Yes, I was referring to the way results software handles missed points, and the way you would want the internal results calculators in the apps you use on your watch to work. Not referring to anything Garmin. Sorry for the misunderstanding.
We have always wanted the raw unfiltered data from the devices for the reasons you mentioned.
We are also talking here about the positional data. Our speed results are all calculated using the Doppler data, which testing has shown is not significantly affected by the positional data issues.
If some software processing GPSTC data are getting different results for 5X10 speeds with this issue, it suggests that positional data is being used. I understand the Alpha probably requires positional to calculate aspects of turning around from one direction to the other, so can probably be impacted by a positional error, but 5X10 should be all time and speed based and not require any position data for the calculation. Likewise for NM, 2S, 1 hours etc.
Select to expand quotevosadrian said..
If some software processing GPSTC data are getting different results for 5X10 speeds with this issue, it suggests that positional data is being used. I understand the Alpha probably requires positional to calculate aspects of turning around from one direction to the other, so can probably be impacted by a positional error, but 5X10 should be all time and speed based and not require any position data for the calculation. Likewise for NM, 2S, 1 hours etc.
Probably not, I think it's more down to how missing points are handled. The powers that be are addressing this issue at the moment.
I think it would be good to determine what causes the missing points. The session I posted a few days ago had only one spike and ended up with very good alignment with the Motion across all categories. I also have a DIY-GPS file for that session if that adds any value.
So Rob, you don't accept Mike's idea that it's completely random and caused by internal timing issues?
I know your 2 sessions indicated otherwise, but other sessions tend to rule alternatives out.
Although on the 14th we both had spikes.
I'll compare the files, and see if the spikes align
As Mike reckons, it could be internal timing issues, but I feel like something external could be triggering them. Loose band maybe? Starting logging before a fix is established maybe?
It's just crazy that a short session can have thousands of spikes, but a long session a couple of days later has one spike!
It seems like, once the logging session has started, it's either good or bad but doesn't change much.
Red is Rob, Blue is me. mainly no alignment, but there's a couple very close. Could be aligned if there's a time difference between the two.
This is the closest I can find, and well within the time difference between units.
So again nothing conclusive, still random and coincidental, that My files are normally clear and Rob and I both had bad data on the same day.
This is a real head F
Then there's that file of mine that seems to have spikes immediately before and after a 2 second peak. Which made me wonder about the watch bouncing around on my wrist
Perhaps it is worth having a look at the satellite availability to see if there is any correlation.
I remember this being an issue some years ago when we only had GPS and not Glonass etc etc
satpredictor2.deere.com/chartvisibility?addr=&lat=-32.574523466003335&lon=115.73323557729786&timeZ=32&evMask=10&gps=YES&glonass=YES
Looks like we weren't that far apart at this point. looks like Rob is the top bold green spot. I'm the bottom bold green spot.
As far as the satellites are concerned we're next to each other
I wondered if the watch likes to do some sort of moving averaging so it can show live speeds updated every few seconds. So when it has a 0 it doubles the next reading to "make up".
OAO and FIT files from a short session today on KA72. May allow comparison with Decrepit.
Select to expand quoteremery said..
I wondered if the watch likes to do some sort of moving averaging so it can show live speeds updated every few seconds. So when it has a 0 it doubles the next reading to "make up".
Watches do apply filtering to the live / displayed speeds and that varies by activity type. However, the zeroing then doubling of positional speeds is related to changes in lat + lon which are unfiltered. When they freeze (appearance of zero speed) then they will inherently double when the true lat + lon becomes available on second later.
I've requested another piece of diagnostics from APPro, which I expect to shed further light on the nature of the timing issue.
