Appropriate filter value for mAcc (max acceleration)

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.

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.

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.

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.

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.

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.

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.

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.