There have been quite a few "max speed" claims throughout the year, so I decided to write something on this topic.

medium.com/@mikeg888/what-to-make-of-max-speeds-b83c05569e6c

I don't think it will surprise many people in this forum that "max 2 seconds" is a far better indicator of top speed.

yes with 10hz ripple, max speed doesn't look very realistic

I have to agree. I wonder if there is a "simple" way to implement 2-sec max speed in my Garmin 255.

Does TBWonder's data field implementation include 2-sec max speed?

Select to expand quote

segler said..
I have to agree. I wonder if there is a "simple" way to implement 2-sec max speed in my Garmin 255.

Does TBWonder's data field implementation include 2-sec max speed?

Yes

Great article Michael, I learnt a bit here, thanks for sharing
I do agree with your closing Takeaways
Cheers
TK

Select to expand quote

segler said..
I have to agree. I wonder if there is a "simple" way to implement 2-sec max speed in my Garmin 255.

Does TBWonder's data field implementation include 2-sec max speed?

Yes, GPSTC V4 includes 2 second (last run and best).

Another app that I use on my 255 is called Windsurfing Application by ViVSurfer.

apps.garmin.com/en-US/apps/9d47be43-2724-44e4-8f5e-3005b0766087

I guess this "problem" is exacerbated on devices with a high accuracy. The max speed reported by my Garmin watch is a 1 sec average and it also displays 2 sec max speed. The difference is generally only about 0.2 knots.

Yes, the difference between a 1s average and 2s average can be fairly close, but the difference between a 0.1s peak and 2s average can be much more.

Select to expand quote

ptsf1111 said..
I guess this "problem" is exacerbated on devices with a high accuracy. The max speed reported by my Garmin watch is a 1 sec average and it also displays 2 sec max speed. The difference is generally only about 0.2 knots.

I often see differences in excess of 0.5 knots in my FR 255 sessions (max vs 2s) but we need to remember that it's how much they differ from the "truth" that matters, rather the difference between the max and 2s. Elaborating on the last example from the article might help to illustrate the issue.

The blue dots in the graph below are raw 5 Hz u-blox data with the 3 obvious outliers highlighted in red. The yellow dots show what happens when you sample at 1 Hz and calculate 2 second averages using the 1 Hz samples. All possible offsets (.0 / .2 / .4 / .6 / .8) have been included and some of them obviously pick 5 Hz outliers as 1 Hz samples.

This not only leads to misleading max values, but also misleading 2s averages which happen to be quite close to the max values. Neither are particularly close to the likely truth, but the 2s averages are slightly better. This can happen with any chipset that does speed calculations over short time periods, but logging at 1 Hz. This includes 1 Hz u-blox data and the 1 Hz Airoha chipset used in recent Garmins.

I intend to write this topic up properly at some time in the not too distant future, since there are some interesting findings. There are a number of interesting observations I've made during recent testing of sampling rates and activity types. I just need to put some thought into how I write it all up in a coherent manner.

p.s. When it comes to something like a FR-255 logging @ 1 Hz we can't refer to a 1 second average. Each speed is a single value calculated over a short time period within the second, and certainly not the average speed during the whole second.

Thnx for sharing your knowledge ! Some cool readings on your blog....

Select to expand quote

K888 said..

ptsf1111 said..
I guess this "problem" is exacerbated on devices with a high accuracy. The max speed reported by my Garmin watch is a 1 sec average and it also displays 2 sec max speed. The difference is generally only about 0.2 knots.

I often see differences in excess of 0.5 knots in my FR 255 sessions (max vs 2s) but we need to remember that it's how much they differ from the "truth" that matters, rather the difference between the max and 2s. Elaborating on the last example from the article might help to illustrate the issue.

The blue dots in the graph below are raw 5 Hz u-blox data with the 3 obvious outliers highlighted in red. The yellow dots show what happens when you sample at 1 Hz and calculate 2 second averages using the 1 Hz samples. All possible offsets (.0 / .2 / .4 / .6 / .8) have been included and some of them obviously pick 5 Hz outliers as 1 Hz samples.

This not only leads to misleading max values, but also misleading 2s averages which happen to be quite close to the max values. Neither are particularly close to the likely truth, but the 2s averages are slightly better. This can happen with any chipset that does speed calculations over short time periods, but logging at 1 Hz. This includes 1 Hz u-blox data and the 1 Hz Airoha chipset used in recent Garmins.

I intend to write this topic up properly at some time in the not too distant future, since there are some interesting findings. There are a number of interesting observations I've made during recent testing of sampling rates and activity types. I just need to put some thought into how I write it all up in a coherent manner.

p.s. When it comes to something like a FR-255 logging @ 1 Hz we can't refer to a 1 second average. Each speed is a single value calculated over a short time period within the second, and certainly not the average speed during the whole second.

This is called "aliasing" in signal processing 101.

Its unavoidable when running low sample rates compared to the actual motion spectrum.

If you sample at 1Hz, then any motion component faster than 0.5Hz will introduce an aliasing error. In the worst case where the peaks of that real speed line up with the sampling point, you get an offset. If this is periodic it accumulates. Usually though its not in phase so averages to 0 over time.

The worst errors happen with motion of 1Hz, 2Hz etc which is not unlike banging through a bit of chop.

Back when windsurfing had the outright record (Finian, AA), was when consumer GPS was taking off as a tool. Due to the exclusivity (expense, access etc) of WSSRC sanctioned events, and the discovery of some epic locations for speed around the world, there was a motivation from GPSSS crew to get consumer GPS recognised for WSSRC. A tech group was set up to investigate how we could prove the error margin of consumer GPS. One of the errors identified was due to aliasing on 1Hz devices. I suggested that the devices of the day did not employ decimation filters prior to being exported. There was some robust discussion on this and to prove it was an issue, Manfred Fuchs built a servo controlled test jig... and indeed he discovered that there was virtually no filtering in the chipset firmware- so aliasing was really an issue.

The pursuit for recognition for WSSRC lost its steam by the time that absolute legend Paul Larson did his thing with Sailrocket...

The only way to prevent aliasing errors is to sample at higher rate. Initially there were no chipsets readily available but there was a lot of effort put in to try to get something up and running (Tom Chalko especially). Then we got UBlox M8n...

10Hz really helps take aliasing out of the picture (by the time we are talking 5Hz motion its pretty small due to our bodies being a mechanical low pass filter) but you have to use every sample. You can't just take every 10th sample to calculate your 2 second speed otherwise there is no advantage over aliased 1Hz sampling. You need to run the data stream through a decimation filter to suit the final sample rate used for analysis.

eg if you want to look at the speed every second, you need to pass the 10Hz data through a 0.5Hz low pass filter.

Not sure if thats what the "rules" stipulate for how to process it (I hope it uses all the points in a 10Hz sample rate data set) but I've run out of bandwidth on this topic

sorry that all got a bit nerdy but thats where we are...

Thanks Chris for the explanation.

Select to expand quote

slowboat said..

K888 said..

ptsf1111 said..
I guess this "problem" is exacerbated on devices with a high accuracy. The max speed reported by my Garmin watch is a 1 sec average and it also displays 2 sec max speed. The difference is generally only about 0.2 knots.

I often see differences in excess of 0.5 knots in my FR 255 sessions (max vs 2s) but we need to remember that it's how much they differ from the "truth" that matters, rather the difference between the max and 2s. Elaborating on the last example from the article might help to illustrate the issue.

The blue dots in the graph below are raw 5 Hz u-blox data with the 3 obvious outliers highlighted in red. The yellow dots show what happens when you sample at 1 Hz and calculate 2 second averages using the 1 Hz samples. All possible offsets (.0 / .2 / .4 / .6 / .8) have been included and some of them obviously pick 5 Hz outliers as 1 Hz samples.

This not only leads to misleading max values, but also misleading 2s averages which happen to be quite close to the max values. Neither are particularly close to the likely truth, but the 2s averages are slightly better. This can happen with any chipset that does speed calculations over short time periods, but logging at 1 Hz. This includes 1 Hz u-blox data and the 1 Hz Airoha chipset used in recent Garmins.

I intend to write this topic up properly at some time in the not too distant future, since there are some interesting findings. There are a number of interesting observations I've made during recent testing of sampling rates and activity types. I just need to put some thought into how I write it all up in a coherent manner.

p.s. When it comes to something like a FR-255 logging @ 1 Hz we can't refer to a 1 second average. Each speed is a single value calculated over a short time period within the second, and certainly not the average speed during the whole second.

This is called "aliasing" in signal processing 101.

Its unavoidable when running low sample rates compared to the actual motion spectrum.

If you sample at 1Hz, then any motion component faster than 0.5Hz will introduce an aliasing error. In the worst case where the peaks of that real speed line up with the sampling point, you get an offset. If this is periodic it accumulates. Usually though its not in phase so averages to 0 over time.

The worst errors happen with motion of 1Hz, 2Hz etc which is not unlike banging through a bit of chop.

Back when windsurfing had the outright record (Finian, AA), was when consumer GPS was taking off as a tool. Due to the exclusivity (expense, access etc) of WSSRC sanctioned events, and the discovery of some epic locations for speed around the world, there was a motivation from GPSSS crew to get consumer GPS recognised for WSSRC. A tech group was set up to investigate how we could prove the error margin of consumer GPS. One of the errors identified was due to aliasing on 1Hz devices. I suggested that the devices of the day did not employ decimation filters prior to being exported. There was some robust discussion on this and to prove it was an issue, Manfred Fuchs built a servo controlled test jig... and indeed he discovered that there was virtually no filtering in the chipset firmware- so aliasing was really an issue.

The pursuit for recognition for WSSRC lost its steam by the time that absolute legend Paul Larson did his thing with Sailrocket...

The only way to prevent aliasing errors is to sample at higher rate. Initially there were no chipsets readily available but there was a lot of effort put in to try to get something up and running (Tom Chalko especially). Then we got UBlox M8n...

10Hz really helps take aliasing out of the picture (by the time we are talking 5Hz motion its pretty small due to our bodies being a mechanical low pass filter) but you have to use every sample. You can't just take every 10th sample to calculate your 2 second speed otherwise there is no advantage over aliased 1Hz sampling. You need to run the data stream through a decimation filter to suit the final sample rate used for analysis.

eg if you want to look at the speed every second, you need to pass the 10Hz data through a 0.5Hz low pass filter.

Not sure if thats what the "rules" stipulate for how to process it (I hope it uses all the points in a 10Hz sample rate data set) but I've run out of bandwidth on this topic

sorry that all got a bit nerdy but thats where we are...

Hi Chris, Thanks for the background and some history, it's always interesting to read about investigations that were undertaken in the past. Regarding signal processing, sampling theory and filtering, also interesting to hear about Manfred's test jig. I had contemplated a similar setup myself, but in the absence of building such a thing have found that walking provides some basic insights suitable for a wide audience.

The red plot shows my arm movement according to a Motion recording at 5 Hz (showing the true cadence) and the blue line is from a Motion recording at 1 Hz. The resultant aliasing is obviously explained by the Nyquist-Shannon sampling theorem, but I think it's a nice illustration using data from a very simple test that anyone can perform.


The green trace is from my FR 255 (Airoha) which aside from a slight phase offset is almost the same behavior as the Motion (u-blox). The MediaTek chipsets popular in watches prior to 2019 (Sony era) tended to use the MT3333 which was also capable of 10 Hz, but typically logging at 1 Hz. The Airoha (MTK descendant) in modern Garmins appears to have a lot in common with the u-blox in this respect.

What I am contemplating writing up is how different watch manufacturers appear to deal with these aliasing artefacts. Just out of curiosity, I recently tested a bunch of activity profiles on the Garmin FR 255 and COROS APEX 2 Pro to determine the differences between the various activity profiles and between the two brands. Each brand essentially uses the same filtering for a bunch of similar activity profiles.

Although one might initially assume that the COROS and Garmin watches (same Airoha chipset) would produce similar data (both for position and speed) their approach to filtering is really quite different. Watch manufacturers also tend to filter the positional data and speed data differently. It's obviously very geeky but a topic that I think is kinda interesting and does provide some worthwhile insights.

BTW, I understand why we should use every sample, either logging at the original frequency or using the output of a decimation filter. That's essentially what I was trying to illustrate with the wing foil data in the earlier post, although not with the full explanation it deserved. I think your post does a great job of explaining it from a slightly different perspective, albeit the same underlying theory.

Select to expand quote

K888 said..
p.s. When it comes to something like a FR-255 logging @ 1 Hz we can't refer to a 1 second average. Each speed is a single value calculated over a short time period within the second, and certainly not the average speed during the whole second.

That statement is technically correct, but it misses one important accuracy aspect: filtering. The 5 and 10 hz data are basically unfiltered, so they are subject to spikes from both real movements of the GPS, and from noise. In contrast, 1 hz data are often filtered to remove high-frequency movements. This is the case for the old Locosys GT-31, and it is also the case for Garmin watches. For the Garmin 255, it's very obvious when you record at an activity that has to compensate for arm movements, like running; but some filtering is always present in 255 data.

This means that the graph you showed overstates the errors from using 1 hz watch data. Here is an illustration with data from one session:
The blue line is 5 hz data. The red line is 1 hz data generated by subsampling (using every 5th point). The green line is data from a Garmin 255 watch, which show clear evidence of filtering. I highlighted two points near the top speed where the sub-sampling picked two maxima, and two points to the left and right where subsampling picked minima. Near these 4 points, the filtered Garmin data (green) are clearly more accurate than the subsampled (red) data.

GPS watches usually do a decent job at measuring speeds even when walking or running, even though they are worn at the wrist which moves forward and backward all the time. When walking, the actual "real" speeds that the watch moves vary from around 0 (when the arm moves back) to around 2x the walking speed (when the arm moves forward); the graph Mike posted above shows that nicely in the 5 hz data. If runners would want to know the speed that their arm is moving at any time, they'd definitely have to use 5 hz or 10 hz data. But they actually want to know how fast their body is moving, not their arm. They could do this either by gathering high-frequency raw data, and then averaging them in analysis - or by using data that have been appropriately filtered to even out the back-and-forth movements, which is what GPS watches do.

Select to expand quote

boardsurfr said..

K888 said..
p.s. When it comes to something like a FR-255 logging @ 1 Hz we can't refer to a 1 second average. Each speed is a single value calculated over a short time period within the second, and certainly not the average speed during the whole second.

That statement is technically correct, but it misses one important accuracy aspect: filtering. The 5 and 10 hz data are basically unfiltered, so they are subject to spikes from both real movements of the GPS, and from noise. In contrast, 1 hz data are often filtered to remove high-frequency movements. This is the case for the old Locosys GT-31, and it is also the case for Garmin watches. For the Garmin 255, it's very obvious when you record at an activity that has to compensate for arm movements, like running; but some filtering is always present in 255 data.

This means that the graph you showed overstates the errors from using 1 hz watch data. Here is an illustration with data from one session:
The blue line is 5 hz data. The red line is 1 hz data generated by subsampling (using every 5th point). The green line is data from a Garmin 255 watch, which show clear evidence of filtering. I highlighted two points near the top speed where the sub-sampling picked two maxima, and two points to the left and right where subsampling picked minima. Near these 4 points, the filtered Garmin data (green) are clearly more accurate than the subsampled (red) data.

GPS watches usually do a decent job at measuring speeds even when walking or running, even though they are worn at the wrist which moves forward and backward all the time. When walking, the actual "real" speeds that the watch moves vary from around 0 (when the arm moves back) to around 2x the walking speed (when the arm moves forward); the graph Mike posted above shows that nicely in the 5 hz data. If runners would want to know the speed that their arm is moving at any time, they'd definitely have to use 5 hz or 10 hz data. But they actually want to know how fast their body is moving, not their arm. They could do this either by gathering high-frequency raw data, and then averaging them in analysis - or by using data that have been appropriately filtered to even out the back-and-forth movements, which is what GPS watches do.

if you have 10Hz data stream its quite trivial to filter it properly before storing. As you demonstrated this is what the watches do. The intuitive way is a moving average filter- but this has a pretty ugly response. FIR or a simple biquad is better since it chops out the motion above a defined frequency- my bet would be the watches use biquad since its computationally efficient and "good enough". FIR can be pretty efficient too if you can accept a bit of ripple- and when its used for decimating by factor N you only need to run taps/N per input sample. (In a past life I did a fair bit of DSP coding and hardware).

Back in the day (close to 20 years ago!) I proposed and wrote some code for the 1Hz sampled GPSs for a fairly steep brickwall FIR filter (much better than a moving average- which is actually a crude FIR anyway) that cut off at quite a bit lower than nyquist frequency. I think it was 0.3... Reason was that the GPS of the day didn't have any decimation filters (Manfred showed this perfectly in his tests that it was practically non-existent). That way you remove aliased error caused by movement from 0.5Hz up to 1.7Hz- which is where most of it is (due to arm mass etc the velocity amplitude decreases with frequency). Downside is the 2 second averages would be more like 4 second readings (so they wouldn't look as exciting)... and even peaky 10 second runs would have been "toned down". At least the results would have been more consistent due t removing the bulk of the aliasing spectrum.

Now we have 5 or 10Hz data stream so that becomes a non issue, and its now about how to decide whats useful information, and what frequency you decide to consider "non-interesting vibration". If we are looking for specific intervals- eg 2 second averages, that helps us to decide what is and isn't important.

Applying a 1Hz low pass filter to 10Hz GPS stream should make even the 1 second data more consistent and believeable. As per watch filters now... With 10Hz log rate a simple single stage biquad would be enough to eliminate aliasing spikes from impact events (eg hand grabbing boom, board hitting chop... etc). The you can store it at 5Hz, since you've already decimated the information above the filter cutoff. With biquad you'll still see a bit of wiggle above the cutoff frequency since its not brick wall. 10 second runs and even 2 second would be practically unaffected- aside from suppressing residual aliasing effects and unwanted "vibration" from the data.

Maybe one day I'll have another look at this, but far too many irons in the fire at the moment...

Thanks for the comments and feedback.

When I refer to the differences in filtering in the watches, I'm primarily referring to the differences in the activity modes and across brands. For example, comparing the SUP activity (whilst walking) on my COROS and Garmin shows quite striking differences and insights into their filtering imho.

This first chart is the FR 255, comparing position-derived speeds (green) and doppler-derived speeds (red) when using the SUP activity for a walk. Speed is being heavily filtered (although not as much as walking/ running activities), but changes in position (lat + lon) are relatively unfiltered. If you compare the position-derived speeds to the 1 Hz Motion data you'd also see near-identical aliasing.



The second chart is my APEX 2 Pro (same time period as the first chart). Both the positional data (green, changes in lat + lon) and speed data (red) are being heavily filtered. Position-derived speeds and (what should be) doppler-derived speeds are really similar which is true for a number of COROS activities, including windsurfing and speedsurfing.


The charts above are in stark contrast with the windsurfing / "other" activity on the FR 255 (shown below), where filtering is barely evident. The position-derived speeds are in green and doppler-derived speeds are in red. When compared to a 1 Hz motion (not shown) the aliasing of speeds is near-identical. I'll show that later in this post.


One approach for watches to take would be to utilise the 10 Hz data, and then further filter it accordingly to the activity profile. However, are we really sure that Garmin are decimating before applying their activity profiles, rather than using every nth sample? If so, then why does the windsurfing / "other" activity exhibit exactly the same artefacts as 1 Hz u-blox data (which is taking every nth sample)? It's a genuine question but before coming back to it, perhaps worth sharing some observations whilst hiking yesterday.

Whilst hiking, I have been keeping a close eye on how my COROS and Garmin have been reporting speed (using hike mode) and how they differ to each other. The observations were for a mixture of consistently swinging arms or still arms for several minutes at a time. For a lot of the time they show very different speeds but they also provide some insights into what they might be doing.

The COROS seems to use a simple concept of moving, or not. When you stop the speed stays constant for 5 seconds then suddenly goes blank. When you start walking then after roughly 5 seconds it instantly reports something similar to your previous speed. It's really slow to pick up genuine changes in pace and to me it looks like they are tracking average moving speed over something perhaps up to a minute and reporting that speed when it considers you to be moving. It's not quite this simple because of observations when driving, when it does some really strange things. This simple description applies to when you are really walking though.

The Garmin on the other hand shows decreasing speeds for 5 or so seconds after you stop, then it snaps down to zero. When you resume your walking the reported speed starts really low then increases steadily over the next 10 seconds or so. It's very different to the COROS approach and when you stop and start walking (taking photos, rests, etc) the two are frequently different by several km/h. After a minute or so of walking at a steady pace they then settle down to reporting similar speeds.

Obviously, the approach to determining walking speed is not of huge relevance to our sport but it's interesting to see just how different the two brands have chosen to implement their activity profiles. Although it's not evident from the charts above, COROS appear to treat SUP like the windsurfing / speedsurfing activities, whereas Garmin treat SUP as something in between walking and windsurfing.

Perhaps I'm missing something, but when I record a walk on the FR 255 using windsurfing / other and compare it to a 1 Hz Motion the exact same aliasing is seen on both devices (due to a sampling frequency that is significantly lower than Nyquist frequency). To me this suggests the Garmin is simply taking every nth sample (or receiving 1 Hz data which hasn't been decimated), just like the Motion. However, this isn't consistent with Peter's chart which is interesting.


Question for Peter: Was that graph using data captured in cycling mode, or "other"? I've observed during my own testing that cycling mode changes it's filtering approach every once in a while (perhaps some "automatic detection" of walking / cycling). Sometimes using cycling mode when walking shows the speed artefacts, and sometimes it doesn't. Filtering (or not) seemingly appears to switch on and off, depending on what it thinks you are doing.

On the other hand, windsurfing and "other" always exhibit the artefacts just like a 1 Hz Motion. One such test is shown below (5 Hz Motion in blue, FR 255 activities overlaid) - cycling, "other", cycling, "other". The second cycling stint (magenta) has a fair bit of filtering evident. During other tests, I've seen the cycling filtering changing the moment I stop walking and re-start, becoming more or less aggressive. In this respect, I'm pretty sure that the cycling activity behaves differently to "other", but the windsurfing activity is essentially the same as "other".

So, why all this effort looking at activity modes and their filtering?

My other half has a COROS Pace 3 which doesn't have a windsurfing / speedsurfing mode and I wanted to determine the most appropriate choice for her to use on the water. The custom activity profiles that she originally selected exhibit hideous smoothing artefacts, so I started looking at what the various COROS activities so and then compared them to Garmin. BTW, what I considered "hideous" is shown below for a short van journey - Motion in blue, COROS "custom" activity in red.




A mixture of walking and driving tests have proven to be quite insightful when comparing activity profiles, additional to the obvious on-the-water tests. It turns out the best activities on a COROS (in the absence of windsurfing / speedsurfing) are SUP (which would be a bad choice on a Garmin), or something called GPS cardio. On a Garmin we need to avoid SUP, but we can use "other" with GPSTC V4 or windsurfing (via an app).

I'm still not entirely convinced that Garmin aren't outputting individual samples without decimation under certain circumstances. I see it when hiking (speeds way higher than my torso speed, but reflecting momentary arm speed) and in data that I capture using "other" or windsurfing activity profiles when doing a walk (matching a 1 Hz Motion). I don't have the DSP background of Chris, so there may be a simple explanation of how the 1 Hz artefacts that I'm capturing on a FR 255 match a 1 Hz Motion (which is definitely just taking every nth sample).

Any thoughts or explanations as to how the 1 Hz sub-sampling artefacts seen in Motion data can also be seen in FR 255 data under certain circumstances?

Apologies for such a long post.

p.s. I'd previously noticed that Locosys devices (GT-31, GW-52 and GW-60) use decimation / filtering for 1 Hz data, not every nth sample. It was the aliasing artefacts in the data from my FR 255 matching a 1 Hz Motion that surprised me.

I've just realised I didn't include a graph showing how different the speeds are for the hiking activity profile of COROS and Garmin. The graph below is just a 5 minute snippet from yesterdays hike; APEX 2 Pro (red), and FR 255 in (blue).

This was a slightly unusual section of the walk with a short stop, plus speeding up and slowing down but nevertheless, I find it quite striking how different the reported speeds are from the two watches which use the identical Airoha chip. They clearly use very different filtering approaches.

The graph below is a final example for today, demonstrating the activity profiles that are relevant to our sport. The FR 255 data (magenta = windsurfing) exhibits the same aliasing artefacts as the 1 Hz Motion data (blue) when walking, whereas the COROS data (red = windsurfing, green = speedsurfing) is clearly filtered.



Granted this data is somewhat articial and I'm deliberately trying to provoke aliasing artefacts by arm movements, but there are consequences for the speeds later calculated through our standard software.

- 500 m provides a reasonable proxy of the true speed (3.5 knots) and is roughly the same for all devices
- COROS has a max 2 s of just over 4 knots.
- 5 Hz Motion data has a max 2 s of 3.8 knots.
- 1 Hz Motion data has a max 2 s over 7 knots.
- FR 255 has a max 2 s of 6.5 knots.

I'm not suggesting we should expect to see this amount of difference in speedsurfing tracks, but there clearly is a very different approach to filtering in the Garmin and COROS devices that use the same Airoha chipset.

I'm still finding it hard to explain the aliasing in the FR 255 data without it being simple down sampling of the 10 Hz data - every nth sample.

Select to expand quote

K888 said..
I'm still finding it hard to explain the aliasing in the FR 255 data without it being simple down sampling of the 10 Hz data - every nth sample.

It's been a while since I looked at 255 data, but the thing I remember seeing was a delay between the u-blox and 255 data of about 1 to 2 seconds (longer in heavily filtered modes):


I don't recall the details, and my wife did all the setup on the (her) watch, so I cannot tell you if this was biking or other mode. Perhaps you can find it in the .fit file?

The delay was also between positional and doppler speeds. I started to write some code to automatically find the delay (mostly to check alphas, where we use both position and doppler speeds in a connected way), but stopped when I noticed that the delay seemed to not be present in all files. Never looked into details, that would have required to buy another watch. The impression I got was that the amount of filtering even in biking or other mode may have been variable, depending on some characteristics in the data (speed?, variability?). If that is so, then your walking data results may be different from what you'd see windsurfing.

I'd generalize your caution about using "max speed" a bit, and extend it to all short-term numbers, including 2 seconds. In the walking data you show, accuracy would go up significantly if you take 10-second values, and probably would be quite decent for 5x10 averages. There's still a remaining error in the 10 second data, but I'd argue that is partly due to the inherent bias in the algorithm used: if we have a perfectly steady run with some noise added (measuring and/or movement of the GPS, wrist, etc.), then the algorithm would always find a speed that is higher than the true speed. Higher data rates do not address this problem if the added noise shows any correlation (as it would for any non-white noise, including GPS movements slower than the data rate). The way to address this would be filtering before analysis - but in reality, there's little reason to do so, since the observed errors for anything but max speed are already low enough for all practical purposes.

BTW, when looking at how good jibes are using the ratio of minimum speed to maximum speed in a jibe, it suffers from the same problem as "max speed" - or sometimes even twice the problem, with overstated max speed and understated min speed. Anyone who looked at the speed ratios in jibes and went from GT-31s to 5 hz devices probably noticed that the numbers when down.

Yes, the original activity profile is recorded in the fit file, regardless of any edits / changes made in Garmin Connect.

The 1-2 second delay does vary between sessions, and sometimes it's even close to zero. It can also change during a session which makes it harder to handle automatically. I considered trying to automate a correlation process to fix screwy COROS data (where the delay can 10s of seconds, or even minutes) but never put any time into it due to other priorities.

The amount of filtering in biking mode definitely varies and you may well be right that it can vary for the other type, which leaves me with some investigations pending. There are a lot of approaches they might be utilising, some of which might be testable. I have a suspicion that Garmin have set the fix interval to 100 or 200 ms, but the frequency and handling of NMEA outputs is currently unclear to me.

With regards the walking example, even the 10s average (and 5 x 10s) are 2 knots too high, circa 5.6 knots. The 5 Hz data on the other hand has 10s and 5 x 10s results around 3.6 knots so somewhat closer to the 3.4 knots that is probably close to the truth. I like the analogy that Chris made of an arm effectively acting as a low-pass filter. :)

I take your point about non-white noise, although it's quite often followed by the opposite effect. For the most part this seems to make the ripples in 5 Hz and 10 Hz data almost disappear when averaged over time, although not completely. You are quite right though, even 2s can be too high, even from 5 Hz and 10 Hz devices.

Good point about speed ratios in gybes on devices that show a higher max speed and lower min speed. This is something that could probably be attenuated using an approach similar to the one I described a couple of years back where filtering (even a simple 2s moving average) could be used to better determine acceleration within 5 Hz and 10 Hz data.

I won't swamp this thread with the copius amounts of testing that I did relating to different activities, but one of my van sessions might be of slight interest (FR 255, APEX 2 Pro, 1 Hz + 5 Hz Motions). It shows the delays you mention, plus a few other minor points:

- FR 255 - logiqx.github.io/gps-details/devices/garmin/activities/driving-2024-06-30/
- APEX 2 Pro - logiqx.github.io/gps-details/devices/coros/activities/driving-2024-06-30/

I really must find / make some time to write up my actual FR 255 testing... stuff actually relevant to speedsurfing. :D

If you (plural) can improve this and make your case with (a) competition(s), I'll happily make the changes. I'll even introduce "per competition" settings if needed. All in all, what I want is synchronicity with official and final results.

First Motions had a tiny low pass filter and rest-speed-pinned-to-zero but competitions requested raw unaltered uBlox frames so they had to go.

1 frame statistics weren't shown either, maybe not even 1s, but other devices showed these and users requested it often.

IMHO, filtering as being discussed is best done post recording. It's better to record all the raw data and filter it later so we are sure we can always see the whole picture. Currently, all the speed sailing GPS analysis software packages can do the bulk of the filtering in regards to bad data and do a very good job of it. That would be the obvious place to add smoothing filters if people want them, and they they can be turned on and off as required.

A large majority of the sailors in Australia use the mini Motions currently, where you just record and analyse later anyhow. Of course, most use some sort of other instant feedback like a watch, phone or other gps device, but no-one realistically expects the instant and 2 second top speeds of them to be accurate, and for on the water feedback does not really need to be anyhow.

And of course, apart from the instant and 2 second top speeds, which dont mean anything in most competitions, the normal 10 second and longer divisions are very accurate on the ublox based device displays as they come. (ESP and LCD Motions) For these devices, why not just have the option of seeing filtered or unfiltered results in the display processing. Just keep the raw data recording for detailed analysis.

Select to expand quote

sailquik said..
That would be the obvious place to add smoothing filters if people want them, and they they can be turned on and off as required.

Reasonable, but with respect to the GPSTC, it completely ignores the reality that a large percentage of postings are done through ka72, which will not be updated.

I think that proper smoothing can actually give more meaningful and accurate data, since searching for short-period top speeds in raw data are subject to analysis artifacts. But the proper implementation of a filter is non-trivial, as Mike's results with different Coros firmware versions illustrate. Filters are also specific to data characteristics, as the Garmin filters for different "activities" show. For speedsurfing, this may matter less, although I have the suspicion that different amounts of chop and even different GPS mount positions would call for differences in the smoothing. For now, a simple solution is to stay on perfectly flat water . I hope the weed in Fangyland is starting to grow for the summer season!

Select to expand quote

boardsurfr said..
I think that proper smoothing can actually give more meaningful and accurate data, since searching for short-period top speeds in raw data are subject to analysis artifacts. But the proper implementation of a filter is non-trivial, as Mike's results with different Coros firmware versions illustrate. Filters are also specific to data characteristics, as the Garmin filters for different "activities" show. For speedsurfing, this may matter less, although I have the suspicion that different amounts of chop and even different GPS mount positions would call for differences in the smoothing. For now, a simple solution is to stay on perfectly flat water . I hope the weed in Fangyland is starting to grow for the summer season!

100% - filtering well is a non-trivial task. Which is why it shouldn't be implemented haphazardly. So raw data without filtering, is what we should be capturing.

I think most people agree that whenever possible, logging unfiltered data at the higher frequencies is best as it can always be post-processed. People just shouldn't believe individual samples and certainly should not refer to them as their "max speed".

Lots of people claim PBs based on the max speed of their Motion LCD (or GW-60) which was essentially what my article was discussing. I made a conscious choice to avoid references to sampling theory or aliasing, but perhaps I should have done.

Devices limited to 1 Hz logging (e.g. GT-31, Garmin, COROS) really should employ some kind of low-pass filter to avoid aliasing, imho. This should not be confused with the different activity filters implemented by Garmin or COROS to handle the idiosyncrasies of different sports.

The data below is from a short bike ride, intentionally provoking aliasing by swinging my arm. The 5 Hz Motion (blue) can be used to calculate meaningful results (2s, 10s, 500m, etc) but the 1 Hz Motion (red) and Forerunner 255 (green) exhibit aliasing, resulting in very misleading 2s and 10s.


The obvious way for 1 Hz aliasing issues (including random movements + measurement errors) to be attenuated is to use a low-pass filter, prior to decimation. Personally, I'd (almost) always favour a low-pass filter when a device is limited to 1 Hz logging.

10 Hz data? I'm more than happy for the unfiltered PVT data to be logged because it can be handled accordingly during post-processing / analysis.

p.s. I've intentionally not listed which devices and GNSS chipsets do implement low-pass filtering. I've tested many of them...