I had a fun foil session yesterday with some nice PBs; >30 knots 2s, >28 knots 10s and >22 knots alpha.

I think the data contains some nice examples of why an mAcc filter of 10.0 is much too low for Motion data in GPSResults.

- GPSResults reports the best alpha 500 (slightly over 22 knots) at 12:56 on all devices.
- All devices with the exception of the Motion Mini also have this alpha as the fastest 500m. It's a very small lake!
- GPSResults does not regard the Motion Mini alpha as a valid 500m because mAcc is 11.2 and the filter only allows mAcc of 10.0.

This results in an anomaly that the alpha is faster than the 500m; 22.132 @ 12:56:03 vs 21.820 @ 14:10:13

Looking at the data from the Motion Mini it is is clear that the sAcc is very low and consistent through the alpha and the high mAcc for what was probably 1/10th second was most likely the rig flip.

This is the 22 knot alpha from the Motion Mini, showing how rock solid the sAcc was throughout the alpha / 500.


Other alpha results in this track contain an mAcc of 13.7, 13.8 and 14.1. In all instances the sAcc is extremely low and these runs should therefore be considered valid over 500m.

Conclusion: For 10Hz data from the Motion Mini it would appear to make sense to have an mAcc filter of 16.0 like GPS Speedreader.

Full write up at logiqx.github.io/gps-guides/sessions/20220404/

Absolutely agree, should be 16 at 10hz, otherwise valid stuff will be eliminated.
I thing it would be better if acceleration could be averaged over 1s.

Agreed, averaging definitely makes sense for the mAcc filter.

Yes, averages would make more sense for acceleration filters when data rates are above 1 Hz. The same is true for the accuracy filters, especially for u-blox (Motion) data, since sAcc increases quite slowly after crashes, so it is not uncommon so see "fake" speeds after crashes that do not get filtered out (more common in sessions with more crashes, e.g. foil sessions). Lowering the thresholds for sAcc is only a partial solution, and only if you never use a 5 Hz Locosys GPS, where SDoP values above 1.0 or 1.2 are quite normal even in good runs.

Select to expand quote

boardsurfr said..
Yes, averages would make more sense for acceleration filters when data rates are above 1 Hz. The same is true for the accuracy filters, especially for u-blox (Motion) data, since sAcc increases quite slowly after crashes, so it is not uncommon so see "fake" speeds after crashes that do not get filtered out (more common in sessions with more crashes, e.g. foil sessions). Lowering the thresholds for sAcc is only a partial solution, and only if you never use a 5 Hz Locosys GPS, where SDoP values above 1.0 or 1.2 are quite normal even in good runs.

I had another idea in relation to sAcc values which I think would work well for u-blox and Locosys devices.

I jotted down my thoughts in the thread www.seabreeze.com.au/forums/Windsurfing/Gps/NEW-Website-for-GPS-Device-Details?page=1#8

Great work K888. the more people who study and understand this the better.
Unfortunately there appears to be little interest in implementing the findings of such work.
No analysis software developer is prepared to "go it alone" on tightening the filters as who would use software that produces lower speeds?
The major GPS ranking sites do not seem interested in enforcing tighter filters.
The result is we have sites displaying speeds to two or even three decimal places but allowing errors of up to 4 kts.
This does not encourage users to wear GPS devices correctly to minimise errors, instead it rewards those who stuff there old GW60s inside their wetsuit or inside a backpack.

Maybe it would be possible to organise a one-off (or occasional) zoom / teams meeting with the various developers to discuss some of the thoughts and ideas?

If people can get together around one (virtual) table then it might create an environment where ideas can be discussed and hopefully lead to agreement on ways forward, common to all of speedsailing analysis tools.

Maybe I'm being niaive but it's not like we're trying to get Apple and Samsung to agree on a standard UI for all of their products. :D

I think all of the devs want their software to produce trustworthy results and it makes sense to have a common, agreed standard in my mind. The most obvious way to attempt that is via some kind of video forum imo.

With respect, I don't think Video Forum is the best way to go. Too difficult to organise with different people all over the world in different time zones and busy lives with many other commitments.
At the beginning of GPS-SS, we set up a discussion group via email with, from memory about 6-8 people, including the software developers. That worked very well and is how most of the original agreements came about. This format gives people time to ponder and mull over various suggestions and proposals, and more time to make a thoughtful and researched response.

Regarding the crash errors using Ublox sAcc, (there have actually been very few cases bought to our attention, but those few were quite significant). On all those cases I ran GPS-Speedreader with the sAcc filter set to 1.0 and that filtered the crash out of all of them correctly. So now that is my personal default filter for the Ublox based devices. I always use the Ublox devices on 10Hz, but since I still occasionally use the GW-52 on 5Hz I use SDoP filter setting of 4.0 for it, but I cant say I have ever seen good runs where the SDoP goes over 2.0, so I would be happy to use that on 5Hz SDoP. and I have found 2.0 is better and more realistic for the 1Hz GT-31 files. Anything higher than 2.0 can be highly suspect from the GT-31 IMHO, and I could make a good case that it should be more like 1.8 from some of the suspect tracks of have examined.

My filter settings on a 10Hz Motion LCD Bicep mounted session (Mini Motion sAcc values in the helmet are typically half those of my arm mounted Motion LCD):

I have always worn my GW-52's in my helmet, or on my bicep, and it has a much larger and less directional antenna, so my SDoP figures are always MUCH lower and vary far less than the GW-60 I wore on my wrist. Again IMHO, if you are seeing SDoP numbers much higher than 1.5 on the GW-52, I think you should seriously check how you are wearing it. The GW-60 has an extra complicating burden in that it is worn on the wrist where it is subject to more shaking around, but particularly to big, sudden changes on orientation, form the 'overhand' to the 'under hand' grip where the small directional antenna is highly compromised (multi-path, sudden change of satellites used and poor signal strength ). This can very clearly be seen in back and forth tracks where there is alternating under and over grip, but it also particularly evident in gybes.

I just grabbed a random track from 2018 where I was wearing a GW-60 (wrist), GW52 (helmet), and GT-31 (also in the helmet) to illustrate.

2 second run:


A few things to note.
The 5Hz files show a LOT more detail/resolution than the 1Hz and because of this will usually resolve a slightly higher average speed over 2 seconds, and 10 seconds on a typical 'hill shaped' speed graph like this.
The GW52 (Red) has the lowest and most stable SDoP
The GW-60 (Blue)has much more variable and higher SDoP*
At no time in this session was there SDoP over 2 on the GW60 during runs, even the gybes. (big spikes in SDoP when stopped, but that is irrelevant for the results)
You can see here that the GW-60 SDoP suddenly increased when I was slowing down to stop. *I would probably have been using 'under grip' on this run on starboard tack.

Here is a alpha in this session (on my CA40 speed board, so really just a gybe at the end of a run or going upwind.


The issue with the GW-60 SDoP is clearly seen here (Blue)

Acceleration filters are more of a tricky problem because of Gybes, mainly for Alphas. Particularly with the GW-60 worn on the wrist. Really, the only reason why the SDoP filter and Max accelleration filters are set so high for the 5Hz devices in because of the high numbers often seen in Gybes with the GW-60, where the track data seems otherwise to be quite acceptable. But i dont see any reason not to use the figures I have shown above for acc filters if we can agree to reduce the SDoP filter to around 2.0 and the sAcc filter to 1.0.

As a footnote: Since the numbers of GW-60's being used these days is declining at a rapid rate, I dont really see much justification for preserving this high 5Hz SDoP filter at 4.0, but I am open to a reasoned case for it.

I also agree that there is a good case to be made for using averaging over a few points for accelleration filter values.

Ok, just had a quick look at the acceleration data for this specific foiling alpha from Monday.

The existing formula turns out to be 10 * (s2 - s1), where s1 and s2 are speeds in m/s, 0.1s seconds apart from each other.

Simply changing the formula to (s11 - s1), where s1 and s11 are 10 readings apart (1 second) gives a much cleaner acceleration metric.

s1 and s11 are actually centred around the point being analysed, so 5 seconds either side.


If you want to go one step further then calculate a centred moving average for the newly calculated acceleration values.


This was a very quick piece of analysis.

I haven't looked at optimal solutions such as whether to average the speeds first, prior to calculation of the acceleration. I'd expect it to produce even better results. What the above illustrates is that there are some very effective ways to interpret to accelerations in 10Hz data (and 5Hz).

I think I'm even willing to suggest it is "wrong" to simply multiply a 0.1s observation by 10 to determine acceleration in m/s.

Select to expand quote

K888 said..
I think I'm even willing to suggest it is "wrong" to simply multiply a 0.1s observation by 10 to determine acceleration in m/s.

Nonsense. Acceleration is clearly defined (and the typically used unit is meters/second squared, not m/s).

What's "wrong" is to simply use a filter that worked well for GT-31 data, with a 1 second period and comparatively heavy filtering, for 10 Hz data, where the real speed change between points is typically below 0.2 knots, but the random errors are much higher (often 0.5-1 knot).

The two approaches you describe to get around this both would work. Taking speed differences 10 points (1 second) apart simply scales down the random effects by a factor of 10, so what you measure has a larger component of actual acceleration compared to random error. Using a moving average is mathematically a bit cleaner. Either way, you end up analyzing acceleration with 1-hz data.

But while getting this implemented in all the different analysis software seems very unlikely, there is a pretty easy way to avoid these problems: record at 5 hz instead of 10 hz. The average difference between 5 hz and 10 hz results for 2 seconds is in the range of 0.02 knots; for 10 second and longer runs, it drops to 0.01 knots and lower. These differences are way lower than the typical error estimates. Details at boardsurfr.blogspot.com/2022/01/measuring-speed-errors-sampling.html

Ok, so I forgot to go back and add the ?.

My point was that multiplying a noisy 1/10 of a second metric by 10 doesn't represent the true acceleration/deceleration of the windsurfer.

It's just amplifying noise which is what you went on to explain, I just didn't go into the details because I was in a hurry to leave the house.

peace...

Edit: So even now that I went to the trouble of copy / pasting the superscript 2 from Google, the forum shows a ?.

I've left the ? for prosperity.

Select to expand quote

K888 said..
My point was that multiplying a noisy 1/10 of a second metric by 10 doesn't represent the true acceleration/deceleration of the windsurfer.

I agree with that - the measured acceleration in 10 Hz data is dominated by variation between points, not by the true acceleration. That includes both random point-to-point errors, as well as non-random changes when the GPS measures small movements of body parts, like arm or hand movements in the middle of the jibe.

Typical "true" acceleration values in speed runs are about 1-2 knots per second, or 0.1-0.2 knots per 0.1 seconds. In your example, the acceleration in the 10 seconds before your top speed is about 8.4 knots over 10 seconds, or 0.08 knots per 0.1 seconds. In the same region, the point-to-point differences are often around 0.3 knots, or about 4x larger. In the top 10 second run, there is a point with a measured acceleration of 5.7 m/s2 (1.08 knots in 0.1 sec, point 63133).

For anyone tempted to call the observed point-to-point changes in speed "real", I suggest a reality check with Newton's second law that states acceleration is proportional to force. An acceleration of 5.7 m/s2 is a bit more than half a g, which means that the power from the sail would have to suddenly increase by more than half of the body weight within 1/10th of a second - an extra 50 kilogram-force for a 90 kg sailor. If the wind force would indeed change that suddenly, the sailor would experience a spectacular catapult, not a sudden speed increase within 0.1 second.

Your argument about using moving averages can be extended from the acceleration filters towards the actual speed calculation. The acceleration numbers are (almost) useless because of the high-frequency jitter, but the same jitter affect the speed measurement at the edges. One drawback is that using a moving-average filter will reduce the measured top speeds, since lower speeds on both sides of the top speed period will "bleed in". That's probably one major reason why the Coros data, which are heavily filtered, usually are lower (mostly for 2 and 10 seconds, where edge effects play a larger role). Of course, the Coros is really handicapped by having only 1 Hz data.

I meant to do this earlier today but was busy. Here is a look at acceleration across 3 devices being worn during an alpha.

Left to right: GT-31 @ 1Hz + GW-60 @ 5Hz + Motion Mini @ 10Hz
Blue: standard acceleration calculation in our software. 5Hz and 10Hz are pretty noisy and have different scales.
Orange: simple use of moving averages, smoothing speeds then smoothing acceleration.

This was just a quick sanity check to see how well such an approach might work. My initial reaction is that it looks pretty decent.

There has been no jiggery-pokery with the scales, moving averages alone brought the acceleration values in line across all devices.

Anyhow, I thought this was quite interesting. I think the Motion Mini @ 10Hz looks closest to the GT-31 @ 1Hz acceleration data.

With acceleration standard across devices, a single mAcc can potentially be chosen, which seems "cleaner" than multiple values to me.

Obviously, right-click the image and open in a new tab to be able to read the text, etc.

Yep, that's the obvious answer. Now It's a just a matter of convincing everybody.

Select to expand quote

decrepit said..
Yep, that's the obvious answer. Now It's a just a matter of convincing everybody.

I'll write a short article / proposal that can be shared with the relevant people.

I'll also do some more extensive testing using additional data.

So who are the relevant people?

I guess the analysis software providers and the GPS Rankings sites.

So to my (limited) knowledge:
GPS Action Replay
GPS Results
GPS Speedreader
RealSpeed (No longer supported)
KA72
GPS Speedsurfing
GPS Team Challenge

Ideally all the above could be contacted and agree to this new proposal.
A changeover date would need to be agreed to and the ranking sites would then need to ensure that all users are posting with the latest software versions. Clearly it will take time for users to update their software but with encouragement from the Ranking sites this could eventually happen.

If any of the analysis software providers do not agree to making the changes, then the ranking sites would need to be prepared to block posting from these providers.

Select to expand quote

tbwonder said..
I guess the analysis software providers and the GPS Rankings sites.

If any of the analysis software providers do not agree to making the changes, then the ranking sites would need to be prepared to block posting from these providers.

I think your list is complete. The existing GP3S rules state "max. Accel. [5 m/s2]" with no mention of how to handle 5Hz / 10Hz.

I know that GPSResults (which is also used for the GP3S web upload) uses filter values of 4.0 (1 Hz), 8.0 (5 Hz) and 10.0 (10Hz) whereas GPS Speedreader uses 4.0 (1 Hz), 8.0 (5 Hz) an 16.0 (10Hz). They've essentially got their own filter rules to accommodate 5Hz and 10Hz. The other packages (GpsarPro, Realspeed and KA72) probably have some commonality with GPSResults and GPS Speedreader but I have yet to check.

In terms of making a "switch" to this method (i.e. apply this alg and have a single agreed filter value of 4.0 or 5.0), unchanged software would just be doing different filtering of 5Hz and 10Hz results as is already the case. e.g. Current GPS Results doesn't allow this specific alpha to count as a regular 500m result because mAcc > 10.0 using the current calculation. The new calculation says 0.9 just like the track from my GT-31.

As I see it, GPS3S rules are essentially a "minimum" requirement (currently defined as 5.0) but individual GPS software can be stricter and actually is stricter. e.g. GPSResults and GPS Speedreader both use 4.0 for 1Hz devices but have accommodated 5Hz and 10Hz devices by choosing higher values; 8.0 and 10.0 / 16.0.

Within my article, I will suggest it makes sense to leave the GP3S standard as-is (5.0 m/s2) but point out that GPSResults and GPS Speedreader can use their existing (stricter) choices of 4.0 after applying this approach. The new approach simply makes 5Hz and 10Hz acceleration comparable to 1Hz values by producing data with the same shape + magnitude but higher resolution.

Using a filter of 4.0 or 5.0 will become universal, whatever the logging rate; 1 Hz, 2 Hz, 5 Hz, 10 Hz, 18 Hz.

One final note. Everything I created above was produced very quickly... 10-15 minutes in Excel for each post.

Before writing this up properly and making any kind of proposal, I will undertake some extensive investigations, analysis and automated testing of this approach.

I'm going to be busy for the next few days so it'll probably have to wait until some time next week.

Select to expand quote

tbwonder said..
So who are the relevant people?
I guess the analysis software providers and the GPS Rankings sites.

I can't think of anybody else.
I think the GPSTC and GPSspeadreader, would be supportive.

Select to expand quote

Ideally all the above could be contacted and agree to this new proposal.

I don't think it's such a big deal. At the moment it's the software that has a harsh acceleration filter that's penalising high frequency devices. It won't make much difference to software with an appropriate acceleration value. Except to actually filter out longer term spikes.
So this isn't some major change in how speeds are analysed, just a more appropriate way to deal with higher frequency sawtooth wave form filters.

In any case, there are already much bigger differences between the various analytical software and websites that can have quite big differences in results.
A big example of this is how the hour is calculated. Months of talk hasn't resolved the issue.
Basically KA72 and GPSResults say the whole hour must be sailed and have a strange way of working the start out.
The GPSTC's hour is your best distance during an hour. This removes the necessity of working out when the hour starts and finishes, and doesn't need a whole hour to be sailed.

So there are no real agreed standards of accuracy or definitions of categories.
The GPSTC will go with what makes most sense.

So I assume this is also an opportunity to tighten the current SDOP values as well for 5hz and 10hz data?

Select to expand quote

tbwonder said..
So I assume this is also an opportunity to tighten the current SDOP values as well for 5hz and 10hz data?

I think SDOP / sAcc filtering is best regarded as a separate topic as it is more complex and has different considerations (such as slow to react sAcc from u-blox chips) but I will write my thoughts up about that topic in a separate article.

This particular topic of conversation (measuring acceleration on 2/5/10/18 Hz devices) is just about cleaning noisy data and as it happens the most basic techniques appear to work really well. They are also easy to understand and easy to implement.

Select to expand quote

K888 said..

tbwonder said..
So I assume this is also an opportunity to tighten the current SDOP values as well for 5hz and 10hz data?

I think SDOP / sAcc filtering is best regarded as a separate topic as it is more complex and has different considerations (such as slow to react sAcc from u-blox chips) but I will write my thoughts up about that topic in a separate article.

This particular topic of conversation (measuring acceleration on 2/5/10/18 Hz devices) is just about cleaning noisy data and as it happens the most basic techniques appear to work really well. They are also easy to understand and easy to implement.

I agree. Doppler error filters really need to be tightened, but this is a different topic and might be a bit more difficult.

On the Accel. for GPS-SS we would need to convince Manfred Fuchs(GPS-Results)/GPS-SS, and Yann/GPSAR. It seems that Peter/ GPS-Speedreader is already open to it. For GPS-TC, we could agree to a change and specify the settings required, but we would have to have Dylan/KA72 and Peter/GPS-Speedreader come along with that to make it practical.

Thanks Andrew.

I'll put this to one side until next week, when I'll do more detailed analysis, testing, tweaking to make a sound case, then document everything clearly.

I've spoken with Yann and Manfred in the past so once I've finished testing and documenting, I'll make contact and see what they think.

That'll just leave Peter and Dylan for GSPTC.

If you can convince Manfred, I think Dylan will follow along.