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 "

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

Select to expand quote

Mr Keen said..

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

Next time Jayson, next time!

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.

Select to expand quote

sailquik said..
I dont suppose you thought to wonder why this sailor was wearing, comparing and uploading 4 motions in one session to the KA72 page, or god forbid, even ask him??

You are, as usual, very wrong. I did contact the person who posted the track several times, after initially contacting Mike (Decrepit) asking if he knew the poster. The only information that he gave was that the unit with the higher errors was a Motion with an LCD.

Select to expand quote

sailquik said..
This particular unit is one we are very suspicious of, and has been under study and review for some months. The owner flagged it immediately and has been sharing session studies with me all of that time. No sessions have been actually posted to GPSTC from this unit after it was flagged if they deviated from the mini's worn at the same time. (There has always been at least one control unit)

So you are confirming that you are aware that there are Motion units that do not perform well. Good to know. Julien had confirmed that the other unit also was not performing poorly, apparently because it used a "bad" firmware version.

Select to expand quote

sailquik said..
It might be more productive and useful if you actually talked directly to the people involved in a cooperative and constructive way when you go on trawling expeditions, find things that bother you and then get online and cast dispersions.

Once again, sailquik goes on to a personal attack that is full of lies as soon as someone disagrees with him. That's typical bully behavior that we have seen multiple times.

You posted a screen shot from a single comparison to make your point. Which is quite pointless, as I illustrated by posting a rather similar example using Motion data.

You stating that I went on a "trawling expeditions" is complete bull**, quite obviously intended to discredit me. I have shown in earlier posts on this thread that the currently error estimate filters need to be improved for Motion data. That requires looking at a large number of files, for which ka72.com is a public resource.

Select to expand quote

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.

> 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.

I have also received new logs of 42, 332 and 2683. In a car, without that damn pouch. And the max differences on 10s are: 0.06, 0.04, 0.01, 0.01, 0.03kn and on 500m are: 0.03, 0.03, 0, 0.01, 0.06kn. So is it the pouch? Is it water? Is it something else? Let's find out. And chill.

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

This is getting us nowhere, we don't come on these forums to abuse people and make enemies, We are here to improve our sport, through the exchange of the extensive knowledge that many have.

Lets focus on what we believe the best auto filters should be for all the current devices and how we can implement them across all posting software.

Looking at Boardsurfr's comparison of the 4 motions.
It is very easy visually to see the blue motion has a problem, once you know what a good motion data looks like.
It would be nice if GPSSpeedreader (and other software) could analyze a motion file and give a score for the 'quality' of the data. Derived from a combination of reported error and stability of data.
This would allow users of single devices to get a feeling of how their device was performing. They could experiment with different positions, aquapacs, inside helmets, etc to see which gives the best results

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?

Select to expand quote

boardsurfr said..


You are, as usual, very wrong. I did contact the person who posted the track several times, after initially contacting Mike (Decrepit) asking if he knew the poster. The only information that he gave was that the unit with the higher errors was a Motion with an LCD.

sailquik said..
It might be more productive and useful if you actually talked directly to the people involved in a cooperative and constructive way when you go on trawling expeditions, find things that bother you and then get online and cast dispersions.

Once again, sailquik goes on to a personal attack that is full of lies as soon as someone disagrees with him. That's typical bully behavior that we have seen multiple times.

Did re-read your own post - you just criticised someone for stating something that you already performed -> it appears you simply wanted to call out Sailquik as a bully for ... a reason which you agree with... which doesn't make any sense.

Calling someone a bully while also being a bully, just makes you a bully too.

How about we all stop being bullies?

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

sailquik said..
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?

Downloading files from ka72.com is not only perfectly "ethical", but it's actually one of the big arguments why people should use ka72.com for GPSTC postings in the first place, as you very well know. If you look at the details for a few successive daily postings, you may notice that the only thing that changes is the number of the track in the URL. So changing the number directly, instead clicking back and forth, happens to be a faster and more effective way of downloading many files. That's something anyone can do, without even needing a ka72.com. The pages displayed by ka72.com do not indicate in any way that the data are "private", and display a perfectly functional "Download" button.

So why are you trying repeatedly to paint me as unethical? Perhaps you should address your concerns to the owner of ka72.com, who seems to promise "private" data, but leaves the data easily accessible for downloading for anyone. Have you even bothered to contact Dylan about adjusting the thresholds for error estimate filters to at least match the values from ka72.com? Or do you just don't care than data submitted from GT-31 units are processed without any SDoP filtering?

You seem very intent to paint me as a hacker an villain, but you state quite correctly that the owner of the files in question was "surprised" when I told him that I had gotten the file from ka72.com. He was surprised, not concerned. As you very well know, the purpose of the downloads was to improve the filters in GPS Speedreader, specifically for the GPSTC. Which is something that should be done looking at a significant number of data files, not just at a few examples.

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.

Select to expand quote

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.

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

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

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.

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

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

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

boardsurfr said..

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).

Which is exactly what I wrote - different words with exactly the some meaning - have you got a comprehension problem ?

Here's the deal -> if you really dont want to post onto this forum because you think someone is out to get you, then fine dont post. If you do want to post and then fine too. In the meantime, stop being nasty to everybody that has a differing message.

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

Aus501 Boz said..
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????

That's the problem, we have no idea. If we knew it may be possible to approve it.

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.

Select to expand quote

mathew said..
have you got a comprehension problem ?
...stop being nasty to everybody that has a differing message.

How about you follow your own advice?

Phrasing offensive statements as a question does not really change anything about their offensiveness. The question still clearly shows what you think, but leaves you the lame excuse of "just asking a question".

You have not made any contribution to the topic of this thread. Your only "contributions" were to call me a "bully" with a "comprehension problem", followed by issuing directives. Nasty, indeed.

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

GT11: SiRF Star II,
GT31: SiRF Star III,
and as Roo once mentionned here, GW52 and GW60 both contain plain-text references to MediaTek frames. And their specifications would be consistent with something like MT3318.

Chalko's paper: "This article explores and tests the "Speed Dilution of Precision" (SDOP) parameters developed and kindly provided by SiRF (many thanks SiRF) and implemented by Locosys Technology Inc (many thanks Roger at Locosys) into firmware of their GT31 hand-held GPS datalogger."

Now, is SiRF's-era SDOP the same as MT's-era SDOP? Wasn't SDOP SiRF's property? Locosys' website mentions SDOS. Did anyone ever notice something similar to SDOP in MediaTek's datasheets? You have four hours. A4 sheets, 2cm margin on each side.

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.

Select to expand quote

JulienLe said..
GT11: SiRF Star II,
GT31: SiRF Star III,
and as Roo once mentionned here, GW52 and GW60 both contain plain-text references to MediaTek frames. And the specifications would be consistent with something like MT3318.

Chalko's paper: "This article explores and tests the "Speed Dilution of Precision" (SDOP) parameters developed and kindly provided by SiRF (many thanks SiRF) and implemented by Locosys Technology Inc (many thanks Roger at Locosys) into firmware of their GT31 hand-held GPS datalogger."

Now, is SiRF's-era SDOP the same as MT's-era SDOP? Wasn't SDOP SiRF's property? Locosys' website mentions SDOS. Did anyone ever notice something similar to SDOP in MediaTek's datasheets? You have four hours. A4 sheets, 2cm margin on each side.

Julien, Pretty sure it was a Sirfstar chipset Locosys used on the GT11 and GT31, not the MT3318 (that was on the later units ). Yes the speed accuracy was proprietary at the time. I'd already moved onto using U-blox 10hz chipsets when they implemented it, must be 15 years ago now. The U-blox was unique at the time as it output 3d gps raw data, the only one doing so back then. That made more sense as we were moving in space relative to the gps sats and there was no rounding up of the data. Sadly no one wanted to measure doppler speed that way but Manfred did rewrite his software to calculate it.

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.