After a bit of a hiatus, I've regained my interest in GPS technology and created a little website for device details, etc.

I'll add some more devices and further details in due course.

Meanwhile, I'd be interested in hearing your thoughts!

logiqx.github.io/gps-guides/

Thank you Michael. Excellent and interesting work.

Select to expand quote

sailquik said..
Thank you Michael. Excellent and interesting work.

Thanks Andrew.

If you spot anything missing from my GPS summaries that you think is pertinent, feel free to make suggestions.

Hopefully I can get everything in one place for people wanting to compare the brands, etc.

Great work ! If I can help you with specific information about the ESP-GPS, let me know. I can provide you logs from 4 ESP-devices, two on the boom, and two on my helmet.
Greetings, Jan.

Select to expand quote

rp6conrad said..
Great work ! If I can help you with specific information about the ESP-GPS, let me know. I can provide you logs from 4 ESP-devices, two on the boom, and two on my helmet.
Greetings, Jan.

Cool, thanks.

Funnily enough I was just this minute gathering my info to start creating the page. :)

It will be very interesting to see your conclusions on the boom mount.
There are obvious small differences in the gybe, but it seems to me these cancel out to a very large extent, Doesn't seem to make much difference to alpha values.
Overall accuracy is what you'd expect from a ublox 8 device running at 5hz or 10hz

Select to expand quote

decrepit said..
It will be very interesting to see your conclusions on the boom mount.
There are obvious small differences in the gybe, but it seems to me these cancel out to a very large extent, Doesn't seem to make much difference to alpha values.
Overall accuracy is what you'd expect from a ublox 8 device running at 5hz or 10hz

I've had a look over breakfast and my initial observations are consistent with conversations that I've seen elsewhere in this forum.

The data quality looks very good overall. and as has previously been discussed, micro accelerations are picked up simultaneously by units mounted in the same way (e.g. two units on the boom or two units on the head). Units on the head tend to show these changes out of phase with the boom as previously discussed on this forum.

My thinking is that if the units are sensitive enough to pick up all of these micro changes, they will cancel each other out over the period being measured; 10s, 500m , etc. These micro changes are more extreme on the boom due to the effect of chop but this is generally evident in elevated sAcc values. As mentioned elsewhere, rig flips can be seen in the boom data but seem to have little overall effect.

Overall, boom and head mounted results are very comparable. Over the most "important" categories (10s, 500, alpha) it looks like the worst differences are in the order of 0.02 to 0.05 knots. The 2s category sometimes differs by more (up to 0.1 knot) but well, it's 2s and imo that is plenty good enough. Interestingly, boom mounting generally seems to report slightly slower speeds over 2s in the test files.

I'll do a separate response detailing what I saw in the sAcc data.

The sAcc test data was particularly interesting in the Herkingen data. During speed runs it is rock solid and shows we can have extremely high confidence in the speeds being calculated under normal conditions, during runs, etc.

The Herkingen "alphas" (stop, turn, sail back) are an interesting illustration of what happens at the end of a typical speed run. The head units (magenta and green) retain a good signal whilst the boom units (red and blue) go a bit awry. I'm assuming the sail is either in the water or held low for a little while, subsequently flipped low to the water and then beach / water started.

It's clear from the sAcc data when the red and blue units should be ignored but personally, I think it can be done more intelligently than a simple sAcc > 1 filter applied to individual readings. It is clear when the accuracy data changes and I feel that a range can be determined, starting when it begins to diverge from "normal" and ending when it returns to "normal". Any sustained periods of abnormality could then be filtered out, including when the sAcc begins to rise and immediately prior to the return to normality, regardless of sAcc < 1.

This is one for the software devs to discuss but if I were to implement it myself, I'd look for sAcc "spikes" (e.g. above a threshold such as 1.0 or perhaps even 0.8) then for those spikes, determine where sAcc started to diverge from normal and when it subsequently returned to normal. Filter out that entire period and you are left with "trustworthy" data for results.

Just my two cents. :)

Just for the sake of clarity, here's an illustration of the contiguous ranges that I think should be ignored (filtered) during the analysis of red and blue.

From an algorithmic point of view; find the sAcc peaks and then scan forwards + backwards, looking for the first continuous 2s worth of "good" sAcc values to decide where the bad data starts and ends.

So essentially, having a definition that a period can only be regarded as "good" if it lasts for at least 2 seconds and the "lumpy" sAcc data from the blue unit is therefore considered to be one contiguous "bad" period.

Yes, I like it. Makes a lot of sense.

Select to expand quote

decrepit said..
Yes, I like it. Makes a lot of sense.

Perhaps someone in regular contact with the relevant software devs can suggest it as a topic for discussion?

Totally agree. The sAcc (and also nr of sats) seems to be heavily filtered bij the Ublox device. Maybe the sDOP value, that was used by other devices performs better. The (mini)motion recently changed the sAcc value to sDOP, because they seems to be different.
Interesting to see is that the reported doppler speed is more or less "locked" for seconds : the acc value is then 0.000 m/s?
These "receiving" issues were all caused by dropping the sail (and the ESP-GPS) in the water, where the GPS completely looses signals.
In practice, these problems do not influence the end result, as they are related to a crash / trim / rest period.
Another proposal for the evaluation of acc values : why not simple adjust the speed of the speedpoint which has an acc that exceeds the limit ? Now, the complete track is not guilty. With 10 Hz, the limit is easily exceeded.
This could be done in the GPS itselfs, but then you loose "basic data". Therefore, my proposal is to do this in the evaluating sw.

Agree, GPS-speedsurfing should approve the runs with higher sAcc values for device that log >5Hz and apply different criteria. It does not seem logical to mask this in the logging in the GPS devices.

Yes, I agree that such filtering should be done by the analysis software. Firstly, I think it can be done more effectively during post-session analysis and secondly, if it's done in the device there is no opportunity to review how well the filtering algorithms work.

The sAcc data that I have seen is indeed only bad due to entering the water, either deliberately or during a crash. I still think it's worth handling this stuff intelligently though (e.g. general principle suggested above) because as it stands, it is possible to benefit from an inflated 10s result when crashing after 7 or 8 seconds at warp speed. The GPS can potentially continue reporting high speeds for the remaining seconds and maybe even do something wild like give you a boosted speed for those crucial last seconds.

IMO, it's nor really feasible to do in real-time (within the device) because of the way the sAcc creeps up but it's pretty easy to do it effectively within the analysis software.

It seems to me that the existing filtering approach worked well when the rules were conceived with the 1Hz Locosys devices but with the u-blox data it requires a different approach.

I'm pretty sure something along the lines of my proposal would work well for all existing devices and any future devices.

Select to expand quote

rp6conrad said..
The (mini)motion recently changed the sAcc value to sDOP, because they seems to be different.

You're thinking of hAcc, HDOP and PDOP. Motion provided hAcc and PDOP. GPSAR imported hAcc as HDOP, GPSResults imported PDOP as HDOP so to suit everyone, I replaced the PDOP field with HDOP on the basis that PDOP can only mathematically be above HDOP and this fix doesn't break anything historical.

This is all relative to position and has literally no impact whatsoever on speed and speed accuracy.