Speed Accuracy

Select to expand quote

mikey100 said..
Discussion at LG when I was there went like this.
"Each knot of speed equals very close to '1m every 2seconds.' So, 40knots is app 40m/ 2sec. Mate Jayson beat me on the 2sec one day by .02knots. That meant in 2sec he travelled 2cm further then I did. So, if only I had slid my hand/wrist wearing my GW60 forward on the boom at the right moment, I would have beaten him "

Timing is everything Mikey

I keep looking back at what I have posted above and saying to myself, "That can't possibly be correct!"
Used an online calculator to check and appears it is. So, .02knot speed increase means 2cm further in your 2sec speed. So when a buddy beats you by .1knot (32.2 to your 32.1) he travelled 10cm (about the width of your palm) further in 2 seconds. The accuracy of our GPS devices is crazy.

> Julien had confirmed that the other unit also was not performing poorly, apparently because it used a "bad" firmware version.

Just had a quick look and her logs post-upgrade seem nominal. Those who received devices at that time have been asked to upgrade.

Keep the discussion, even the disagreements, technical, and we will all benefit.

Select to expand quote

boardsurfr said..

sailquik said..
Do you think it is ethical to hack the KA72 website to download files that are not made public by their owner, and them publish them on this forum?

Do not go around accusing people of unethical behavior just because you do not understand something. All files that I downloaded are available to anyone who types in the web address of the file. It is still available for anyone at www.ka72.com/Track/t/483916. No hacking whatsoever required.

One wonders, though, why you get so upset if someone finds this file on a public server that specifically promoted to allow others to download and check GPS files, instead of posting warnings not to use the firmware version(s) that can give high errors. Seems that for the #2683 unit, the owner noticed something was wrong, but there's plenty of speedsurfers who post directly from ka72.com and therefore may not notice that anything is wrong. The pictures I had posted on page 2 of this thread, which led to an GPSTC posting with an incorrect PB, is just one example.

Seriously?! Just asking questions that seem quite relevant.

I totally agree that the Doppler Error filters in KA72 and the defaults in the other analysis programs are set far too high for the Motion/Ublox devices. I have always thought the changes that were made to accommodate the GW-60 could lead to problems and here they are. Lets find a way to fix that. I suggest dropping the 5Hz and 10Hz Doppler error filters to 1 for those devices, but I am happy to hear arguments for another setting or another strategy - preferably directly and collaboratively.

Yes, we have seen some problem files from a couple of devices. There appear to be quite reasonable explanations and fixes for those, and there are hundreds out these that seem to be performing very well. I have personally tested quite a few and been sent comparisons and may more. Many of the sailors who have them have compared them with their older devices least to some extent and no other notable issues have surfaced that I am aware of. I trust that sailors who see anything unusual will report that, and they do. I have regular requests to check files from sailors when something does not look right across all the devices. A minuscule number of those are unexplainable.

KA-72 is not set up specifically to share all the users uploads publicly. There are levels of sharing including 'Private' which users would reasonably expect means just that. That you were able to find a clever way to get around that (a hack), and use it, is concerning. I am told by the owner you contacted him after you had downloaded and that he was most surprised that you could do that. Are you downloading other 'private' files? Have to contacted all the owners to ask them permission? What do you think is ethical in this situation?

Thanks Andrew, thats a very good point about how people can know if their Motion GPS is performing as it should when they have nothing to compare it with.

First, I think it's important to say that we should be concentrating on the 'runs'. There is inevitably all sorts of rubbish data outside the runs where the Motion may be submerged, or shielded from good satellite reception or compromised in some other way.

So here are some examples that show the error numbers I typically see in properly positioned and worn devices:

In the mini Motions I typically see individual point Doppler error data numbers between around 0.250 and 0.350 occasionally up to 0.400 with 14-18 satellites used. Below is an example of a lowish error run with side by side mini's. Note that one of there units had a very early firmware version and the other a more recent version as that is what I was testing at the time.


below is an example from the same session of a higher error run, but still within what I consider the normal range and still with excellent speed correlation, and the results within the error margins reported:


Below is and example from Wireless LCD Motions from another session. In this case worn on opposite arms in their supplied arm straps as would/should be the case with typical users. I would not expect such tight correlation in this setting but both units recorded speeds for each run within the reported error margins. Again, I think I had different FW in these two units which should cover the range bing used out there. I typically see slightly higher individual point error figures in the wireless LCD Motions and I believe this is the result of a smaller antenna in those, and that antenna boing located behind the LDC screen, both of which probably mean slightly lower signal strength reception. There are always compromises! This run is relatively low satellite numbers. In the Wireless LCD Motions I typically see Doppler error figures between 0.350 and 0.550 with the odd value around 0.600.


If you are seeing error values within this range, it is likely that you Device is performing correctly and adequately. If you are seeing numbers above 0.500 in a Mini and 0.650 in a LCD Motion, you should be having a close look at how you are wearing it. If you are seeing this consistently, after checking your wearing position and orientation, please bring it to our attention.

Any individual point error figures of over 1.000 (Kt) in a Ublox based device are very likely to be junk data. If you are using the excellent analysis tool, GPS-Speedreader, to analyse and post your Motion data to GPSTC, I strongly recommend that you to set the Doppler error filter to 1.000 as illustrated below. The same if you are using GPS-Results or GPSAR-Pro.


I could get criticised for only giving a couple of examples, but this is what I typically see from properly worn devices, and I pay particular attention to this in every session. I'm pretty confident that this would be what I would find if I extracted data from a larger sample of sessions, but the danger there is that if I chose them randomly, it might include some data from badly positioned/compromised devices.

Interestingly, I often see lower error data from most of the custom/homemade Ublox M8 and M9 based 10Hz devices, as they typically have a larger antenna and use a larger number of satellites. But I also see the occasional missed data points in these devices. As I said, there are always compromises.

Select to expand quote

mathew said..
you just criticised someone for stating something that you already performed

That's an incorrect statement. sailquik stated that I did not bother to ask the person who had posted the record ("or, god forbid, even ask him" are the exact words he used). He is rather consistent in choosing words that are clearly intended to offend and denigrate, for example by calling my attempts to gather data to optimize filters a "trawling expedition", and by raising questions about whether my behavior is ethical.

sailquik is quite skillful in this behavior. He has been quite successful in quieting anyone who had different opinions about what kind of GPS units should be allowed on the GPS Team Challenge. I can certainly understand the people who have left the GPSTC rather than dealing with him.

Anyway, I'm out of this discussion. I've put any further development of GPS Speedreader on hold while I consider if I should spend any more time on it. It seems entirely pointless to make it produce more accurate speed data while the preferred way of uploading results does not include effective filters for a large subset of the data.

yes, for ublox devices I think an SDoP of 1 is appropriate, but for the watch you will loose data, especially through gybes, a setting of 2, for the watch, would have been fine for your speed run. That could be an under hand, over hand thing. The wrist is far from the ideal place for GPS accuracy, especially when flipping a sail. So for alphas with the watch, I'd be tempted to stick with 4.
So as locosys don't have a 10hz device, I think 10hz can safely be left on 1

Unfortunately as most people use KA72, with lax filters, there is that problem of apples and oranges.

But very glad to see someone else getting into the accuracy thing.

Select to expand quote

sailquik said..

Aus501 Boz said..

Any individual point error figures of over 1.000 (Kt) in a Ublox based device are very likely to be junk data. If you are using the excellent analysis tool, GPS-Speedreader, to analyse and post your Motion data to GPSTC, I strongly recommend that you to set the Doppler error filter to 1.000 as illustrated below. The same if you are using GPS-Results or GPSAR-Pro.

Boardsurfr/sailquick, I have found this discussion most interesting from a tech point (maybe not the bickering) .
I went back to see how some of my previous data would look applying the above SDOP value of 1 for the 5Hz devices using Speedreader as per Sailquicks comment above (Excellent tool by the way).

What I discovered was a downgrade on one of my 2sec 40knt runs to 37knts due to the 40knt run 5 Hz SDOP not meeting the criteria of SDOP 1. All other 2 Sec runs that I checked where well within as I changed from the 5Hz device (watch stopped working) to the GT31 and the Mini Motion and no issues with the remainder of the 40+knot runs.

Sorry Boz. I did mention only Ublox based and Motion devices.

For the GW-60 device, as Decrepit said, an SDOP setting of 2 would probably be best for most runs, but as he also pointed out, there is a particular issue with this device (and probably other wrist worn devices) where error figures tend to spike higher in the Gybes during Alpha runs. The SDOP filters were adjusted to 4 to allow what appear to be legitimate runs, but would have otherwise have tripped this filter. It's not ideal, but seems to have worked out OK.

Beauty I keep my 41kntsI'm not tech savvy enough to know what a Ublox device is assumed the watch was

Makes perfect sense now
So to throw a cat amongst the pigeons how do we verify the Corros watch so we can use it for reporting as per the other speed sailing site????

Select to expand quote

decrepit said..
Sorry Boz, we tend to write this stuff as if everybody knows what we are talking about.
ublox devices are named so, because they use the Swiss ublox gps chip. The locosys devices use their own Sirf chip. The motions and the DIY stuff, like Flex's and Elmo's boom mounted devices and my helmet loggers. Use the ublox chip, set to 5hz or 10hz.
The slightly annoying difference is the accuracy data formats, Locosys use SDoP (speed depletion of precision) ublox use sAcc, (I guess, speed accuracy). From observation of our results, there appears to be a difference between the way these are calculated. But we have no data from either company over what algorithms are used.

A locosys file will have the .sbp or .sbn format, where as a ublox file will be .ubx or .oao

SDOP =Speed Dilution of Precision , and by my knowledge Locosys doesn't use a SIRF chipset, SIRF chips where produced by the company SIRF, in 2007 it has been acquired by American company Qualcomm. The GW60 devices still use the .SBP extensions, (Sirf Binary Protocol) that has been extended by the SDOP data fields designed by Tom Chalko (document can be found here -> nujournal.net/estimating-accuracy-of-gps-doppler-speed-measurement-using-speed-dilution-of-precision-sdop-parameter/ ) Both the algorithms for SDOP and sAcc are closed source so not comparable.

Select to expand quote

Xbraun54 said..
>>>>>>>
SDOP =Speed Dilution of Precision , and by my knowledge Locosys doesn't use a SIRF chipset, SIRF chips where produced by the company SIRF, in 2007 it has been acquired by American company Qualcomm. The GW60 devices still use the .SBP extensions, (Sirf Binary Protocol) that has been extended by the SDOP data fields designed by Tom Chalko (document can be found here -> nujournal.net/estimating-accuracy-of-gps-doppler-speed-measurement-using-speed-dilution-of-precision-sdop-parameter/ ) Both the algorithms for SDOP and sAcc are closed source so not comparable.

Thanks Xbraun, I stand corrected, I shouldn't go shooting my mouth off without checking the facts.

MEOW MEOW...
Just get back to the Tech stuff.

Select to expand quote

Aus501 Boz said..
Boardsurfr/sailquick, I have found this discussion most interesting from a tech point (maybe not the bickering) .
I went back to see how some of my previous data would look applying the above SDOP value of 1 for the 5Hz devices using Speedreader as per Sailquicks comment above (Excellent tool by the way).

What I discovered was a downgrade on one of my 2sec 40knt runs to 37knts due to the 40knt run 5 Hz SDOP not meeting the criteria of SDOP 1. All other 2 Sec runs that I checked where well within as I changed from the 5Hz device (watch stopped working) to the GT31 and the Mini Motion and no issues with the remainder of the 40+knot runs.

I suppose it begs the question if one software uses SDOP value of 1 then all software would require to be set like this otherwise we are not comparing apples with apples. Anyways I'm no techy and really only looking at my own data so thanks for the discussions you are having on this subject it's actually made me take a closer look and get a better understanding of our very interesting and exiting sport.

Screen shot of the default settings versus changing the SDOP to 1

Boz, that's an excellent example of why we need to treat u-blox (Motion and prototype) data differently from Locosys (GW60) data. The units use different GPS chip types which compute the error estimates differently.

Julien had initially suggested to lower the threshold for Motion data to 1 knot, since u-blox (but not Locosys!) with an error estimate above 1.0 knots are poor quality. To get a quick idea what the effect of this would be, I analyzed a collection of 94 recent Motion files from ka72.com, looking only at data above 20 knots that did not trigger any of the default filters.

13 of the 94 Motion files had points with an accuracy estimate (sAcc) between 1.0 and 4.0 knots that would be filtered by increasing the threshold. 4 were from one "bad" unit; if we exclude this unit, that leaves 9 out of 90 files from 9 different units.
2 files had a maximum sAcc of 3.0 and 3.96. The other 11 had sAcc values below 1.3.

In the file with the highest sAcc (3.96), the newly filtered points with appeared to be in a crash, and therefore should be filtered:


Note that the sAcc values are increasing slowly, and that the speed remains constant for multiple stretches. This is quite typical for u-blox data in crashes. Based on the drop in satellites tracked, the crash seems to have happened around point 13069.

The next example is interesting:
There is a pretty long region with sAcc values above 1, but below 1.5, in the middle of a run. Here's the entire track:
The is a period of about 20 minutes where the sAcc values are much higher than usual, even during runs. Otherwise, the Motion used here has typical accuracy, as shown by the +- estimates for the 10 seconds.
One possible explanation for this is that during these ~20 minutes, the Motion armband had moved, and was pointing downward. But there may also be other explanations. Reducing the sAcc filter threshold from 4 knots to 1 knot, as sailquik had suggested, reduces the speeds for 1 hour and nautical mile, and cuts about 9 km from the distance.

Here is another example from a different GPS unit:

Again, there are many sAcc values between 1.0 and 1.5 within a run. This time, the track contained a period of about 7 minutes where the accuracy was low. The second-fastest 10 second run was during this period and is filtered out by the more stringent filter threshold, so lowering the sAcc filter threshold to 1.0 knots reduces 5x10 seconds, in addition to hour and nautical mile results.

Of the 6 other files which had points with sAcc values between 1.02 and 1.3, only one had a crash as the cause. The others showed a varying number of points with sAcc just above 1.0, generally no more than 2-3 points in a row. Filtering these points would only have a significant effect on results if they happen to be in the top 2 second or 10 second runs.

To summarize: reducing the SDOP/sAcc filter threshold from 4.0 to 1.0 affected about 10% of the files (if we exclude a "bad" unit). In a small subset of cases, the stricter threshold eliminated artifact speeds in crashes. In a similar amount of cases, it eliminated larger portions of a session where (probably) the arm band moved so the Motion was partially blocked by the arm and body. In the majority of cases where the stricter filter eliminated points, the effect was rather small.

It would be interesting to hear from 448's user because this very long bad period starts and ends with 1 minute idling at the same location.


What is the log of the last one? Thank you

Select to expand quote

Roo said..
Julien, Pretty sure it was a Sirfstar chipset Locosys used on the GT11 and GT31, not the MT3318 (that was on the later units ).

Either I'm going crazy or we agree.