So I opened my OAO file with the KA72 speed errors from 2-Dec-21 in GPS Speedreader and then saved it as a .sbp file and then loaded that into KA72.
Guess what, that produces the exact same speeds as GPS Speedreader.
So the problem lies in the way KA72 is reading OAO files (Particularly the one containing 5hz data)
Select to expand quotemikey100 said..
Hi. Just read this above-"10Hz (with Galileo) is available again in firmwares >= #3038."
I am trialing the 3038 firmware on a mini but in the settings it only shows "10Hz WITHOUT Galileo".
am I missing something?
I don't think so. That 3038 was an experimental FW sent to a few people to test, so I think it's possible he just overlooked changing the tag "(Without Galileo). I noticed that the fw on the website is now 3040 and that tag is gone when I loaded it in my LCD Motion. 
Edit: Loaded 3040 into the Mini and it is the same now.
Select to expand quotesailquik said..mikey100 said..
Hi. Just read this above-"10Hz (with Galileo) is available again in firmwares >= #3038."
I am trialing the 3038 firmware on a mini but in the settings it only shows "10Hz WITHOUT Galileo".
am I missing something?
I don't think so. That 3038 was an experimental FW sent to a few people to test, so I think it's possible he just overlooked changing the tag "(Without Galileo). I noticed that the fw on the website is now 3040 and that tag is gone when I loaded it in my LCD Motion.
Edit: Loaded 3040 into the Mini and it is the same now.
Thanks Andrew.
10hz should be more accurate if there's the same number of sats, but if the firmware is not allowing Galileo at 10hz, then I'm not sure.
Firmware 3006 -3007 used 3 x GNSS and this has returned in 3040.
With the full 18 satellites and 10Hz you should get the most accurate results with 2 or 3 x GNSS, but with 3 GNSS you should be able to get the 18 best sats more often.
You can user either 5Hz or 10Hz for posting to GPS-TC.
So, everyone knows ka72 is a hobby site, not my day job, and my day job has been keeping me terribly busy for a while now.
I've been looking at the files that have been supplied to me, and it is clear that the problem is in the Sdop data. ka72 is expecting more accurate data than the motion is providing. I expect that the other software has loosened their tolerances to accept the data. Higher frequency devices necessarily emit a higher frequency of errors too, and ka72 doesn't accept data with errors in it (though there is always tolerances.)
If anyone happens to know offhand the ideal Sdop allowable for oao data at 10Hz, I'll happily adjust the site to use it. In the meantime I'll play with some settings and see how it affects my test tracks.
Select to expand quoteDylan72 said..
So, everyone knows ka72 is a hobby site, not my day job, and my day job has been keeping me terribly busy for a while now.
I've been looking at the files that have been supplied to me, and it is clear that the problem is in the Sdop data. ka72 is expecting more accurate data than the motion is providing. I expect that the other software has loosened their tolerances to accept the data. Higher frequency devices necessarily emit a higher frequency of errors too, and ka72 doesn't accept data with errors in it (though there is always tolerances.)
If anyone happens to know offhand the ideal Sdop allowable for oao data at 10Hz, I'll happily adjust the site to use it. In the meantime I'll play with some settings and see how it affects my test tracks.
PM sent Dylan. :-)
I'm sure the 10hz SDoP data is fine, it's probably better than lower frequencies. And the motion sdop is normally better than the gw60.
The big difference is the acceleration numbers. GPSSpeadreader uses these acceleration filters by default 1hz 4m/s^2. 5hz 8m/s^2, 10hz. 16m/s^2.
because the waveform rise time are so much faster.
Just found one of the problem files from Matt Reilly,
Here's the speedreader results
Start: 14/11/2021 01:50:10.000 end: 14/11/2021 05:12:11.900
The sdop for 2s is only 0.292. so it's definitely not an sdop problem.
And I'm surprised, these are the acceleration numbers.
2 sec 37.053 0.292 12:01:47.800
1.630
1.490
-0.160
0.200
1.840
0.530
-0.540
-0.280
-1.860
-0.580
-0.430
-0.630
-1.540
-0.320
1.190
1.500
1.450
-0.390
0.630
-2.740
Highest there is -2.740, don't think KA72 would have acceleration filters set below that. So I think that's my theory blown. Satellites didn't go below 13.
Back to you Dylan, this is a mystery.
KA72 gave this result
on the 5th post of the 1st page boardsurfr gives a great analysis, (that's his profession) with the relevant data.Select to expand quoteka72 picks a region 12 points after the highest speed for the top speed.
This does not look like a simple filter issue. There are a couple of points near the start with an acceleration above 2 m/s2, but the default threshold is 4.0, and dropping it to 2.0 still gives a result over 30 knots. The satellites and accuracy numbers for both regions are identical or nearly identical.
The top 10 second speed is also a bit further back in the track than it should be.
Clearly a problem with ka72.com. Having a higher speed for 100 m than for 2 seconds, as in tbwonder's example, is a clear indication that something is wrong with the ka72 calculations.
So I'm convinced it not a problem with the motion's accuracy. It's probably the most accurate unit we've had.
Select to expand quoteDylan72 said..
I've been looking at the files that have been supplied to me, and it is clear that the problem is in the Sdop data. ka72 is expecting more accurate data than the motion is providing. I expect that the other software has loosened their tolerances to accept the data. Higher frequency devices necessarily emit a higher frequency of errors too, and ka72 doesn't accept data with errors in it (though there is always tolerances.)
So it seems the ka72 filters for SDoP are too strict for Motion data. That actually affects 10 Hz data, too (example below).
But to say "ka72 is expecting more accurate data than the motion is providing" implies that the Motion data are not good. This is quite misleading, since ka72.com uses a much more stringent SDoP filter threshold for Motion data than for GT-31 data (> 2.5).
Since the filter values are not published on the ka72.com web site, one has to look at data files.
Here are GT-31 data from today - the top 10 second run from slowboat's GT-31 track (www.ka72.com/Track/t/483823):
Left side is ka72.com, right side is Speedreader (with filters disabled). Three points in the best 10 second run have SDoP values above 2 (2.449, 2.255, and 2.216). So ka72.com allows SDoP of at least 2.5 in GT-31 data.
Now for some Motion data - here is the first file I downloaded (www.ka72.com/Track/t/483822) from today's postings:
These are 10 Hz Motion data, where ka72 understates the top 2 second speeds by 0.121 knots. It seems that ka72.com selects a region a few points earlier in the track, which gives a 2 second speed of 24.099 knots:
It avoids point 102944, which has an SDoP of 0.606. So ka72.com appears to use an SDoP filter threshold of 0.6 for Motion data, while it uses a value above 2.5 for GT-31 data. QED.
For reference, here are the filters that GPSResults uses as defaults for 10 Hz Motion data:
Also for reference, here are the default filters that GPS Speedreader uses:
Like GPSResults, the filters differ for different recording rates (but not for different devices). The values mostly agree with GPSResults, except that higher acceleration is allowed for 10 Hz data (since the same random error will generate twice the acceleration at 10 Hz vs. 5 Hz).
Select to expand quoteboardsurfr said..Dylan72 said..
I've been looking at the files that have been supplied to me, and it is clear that the problem is in the Sdop data. ka72 is expecting more accurate data than the motion is providing. I expect that the other software has loosened their tolerances to accept the data. Higher frequency devices necessarily emit a higher frequency of errors too, and ka72 doesn't accept data with errors in it (though there is always tolerances.)
So it seems the ka72 filters for SDoP are too strict for Motion data. That actually affects 10 Hz data, too (example below).
But to say "ka72 is expecting more accurate data than the motion is providing" implies that the Motion data are not good. This is quite misleading, since ka72.com uses a much more stringent SDoP filter threshold for Motion data than for GT-31 data (> 2.5).
Well, I can confirm and clarify for everyone that KA72 was using exactly the same Sdop filter for GT-31 data as every other kind, which was a value of 3. ka72 was not using a more stringent filter for motion data, there is just a lot more data, therefore more errors, and those errors can be more pronounced. I agree overall there are more valid data points in a motion file, so the data should be considered more accurate overall, but the accuracy level of individual points requires ALL software to be more lenient with its filters.
I am still to investigate the track where the 100m was faster than the 2s, but I am pretty sure, having looked at the code again last night, that I know what is causing this and have addressed it already (still to go out to the site, I am still running tests at my end, I'll post back here when it is out there.) I'll add the track to my testing library though as a good example of a faulty read.
Dylan, I genuinely do not understand both of your posts.
If this issue is clearly SDOP (post #1) and KA72's SDOP filter maximum is 3.0 (post #2), why is your output different than GPSSpeedReader/GPSResults/GPSAR in boardsurfr's example where peak SDOP is 0.606?
Select to expand quoteDylan72 said..
........ there is just a lot more data, therefore more errors, and those errors can be more pronounced. I agree overall there are more valid data points in a motion file, so the data should be considered more accurate overall, but the accuracy level of individual points requires ALL software to be more lenient with its filters.
Can you explain what you mean by: "there is just a lot more data, therefore more errors, and those errors can be more pronounced."
Are you referring to accelleration figures?
The SDOP/sAcc Doppler error data PER POINT is generally considerably LOWER in the Motion/UBLOX data than in the Locosys data (especially the GW60 data). Using a Doppler error filter setting of 3, there would be almost no normal sailing points that would trigger that filter level. Only data points from crashes, dipping the unit underwater or when the unit is blocked from a normal sky view would exceed that filter. None of those things is visible in the runs in question
Accelleration numbers in Doppler data increase with the Hz sample rate. This is not necessarily 'error'. This is a reflection if the very small time interval between data samples and the fact that even small changes in velocity will result in larger acceleration figures.
Perhaps you are referring to the accelleration changes in your statement?, but as previously pointed out, that does not seem to account for the incorrect results.
Select to expand quotetbwonder said..
So I opened my OAO file with the KA72 speed errors from 2-Dec-21 in GPS Speedreader and then saved it as a .sbp file and then loaded that into KA72.
Guess what, that produces the exact same speeds as GPS Speedreader.
So the problem lies in the way KA72 is reading OAO files (Particularly the one containing 5hz data)
So Dylan, how do you explain this? Same 10hz data same sdop values, same everything in fact it's only the extension that's changed, oao to sbp. This means KA72 is treating motion data differently to everything else!
Select to expand quoteDylan72 said..>>>> but the accuracy level of individual points requires ALL software to be more lenient with its filters.
This is just wrong, none of the software eases off it's SDoP filters for 10hz data, in fact I do the opposite. I'm quiet happy using 2 for my 10hz data, could probably go down to 1.
It's the GW60 that needs it to be set higher, (I think GPSResults has it at 6), because of what happens in a gybe, with the overhand underhand change.
And as Andrew says, the increase need with the acceleration number is not due to less accuracy, it's purely due to the increased rise and fall times of the micro changes. These micro changes can have the same height, but 10hz data has to get there twice as quick as 5hz data.
Select to expand quotesailquik said..Dylan72 said..
........ there is just a lot more data, therefore more errors, and those errors can be more pronounced. I agree overall there are more valid data points in a motion file, so the data should be considered more accurate overall, but the accuracy level of individual points requires ALL software to be more lenient with its filters.
Can you explain what you mean by: "there is just a lot more data, therefore more errors, and those errors can be more pronounced."
Are you referring to accelleration figures?
No I'm not referring to acceleration, though I wouldn't rule that out offhand, and as a precaution I have also checked my consistency with other acceleration figures provided and ensured that there is plenty of margin for error in high resolution devices.
I mean that the specific data that I analyzed was wrong specifically because the Sdop figures were above 3. I really don't want to get into a technical barny over this. To analyze this I spent several hours going over the data looking at the correct 10s segments that were being accepted by other software and rejected by ka72, and in every case that I inspected I observed with my own eyes while inspecting the data that there were data values with Sdop figures over 3 in those segments. When I adjusted the software to use a margin of 4 instead for 5Hz and 10Hz devices, the miscalculations went away.
AFTER I did all that, I came to this thread to discuss the results and ask for input.
At no time during that process did I inspect the files in this thread, though I have brought most of them into my testing regime, and they are all calculating as expected now after making those adjustments.
I'm not going to be sucked into a line by line analysis of files that I have not looked at yet unless they are STILL incorrect after the code changes have been made. I just don't have the time to do that.
This is a specific example for you from a file recently emailed to me by Matt. On screen is the first page of data from the fastest 10s in the file. The red cells are the data points with an Sdop over 3. In all, about a third of the data in this 10s speed had an Sdop of between 3 and 4.
This is 10Hz data from a Motion GPS. Another Motion GPS that Matt was carrying did not show this level of Sdop. This may be a firmware issue, or it may be totally legitimate, or it could be a faulty GPS, but the reason the result was "right" for other software and "wrong" for ka72 is that ka72 was applying a lower threshold for Sdop than the other software, which has been confirmed in this thread by a number of posters, and I have confirmed it myself by adjusting the threshold and re-running the engine over the tracks.
This track can be downloaded from www.ka72.com/Track/t/483517
So Here's a close look at the SDoP value of the whole 10hz motion file from 14th November
So valid points are under 1.5. it's the odd submergence that goes higher
Select to expand quoteJulienLe said..
Dylan, I genuinely do not understand both of your posts.
If this issue is clearly SDOP (post #1) and KA72's SDOP filter maximum is 3.0 (post #2), why is your output different than GPSSpeedReader/GPSResults/GPSAR in boardsurfr's example where peak SDOP is 0.606?
I didn't look at that file. However, I have checked it after making software changes and it is working fine now. I don't assert anything about the specific data described in the post. I haven't inspected that file. See my post above.
By the way, I haven't been reading this thread on seabreeze. I spend 0 time on Seabreeze or other social media. I have a life outside of KA72 and it keeps me far too busy to go through all the stuff here. I understand there is some pride rolled up in this somewhere, and defensiveness about various positions, but I really don't care about any of that. I provide a free service, and everyone is welcome to use any other service they like. At the same time, you get the level of support that you pay for. I have investigated this, perhaps a little slowly for many of you, and I have addressed it by doing what the other software has done, by loosening the parameters for errors so that less data is marked as erroneous.
At the end of the day, I am not making a judgement on the correctness or otherwise of the data. I am just bringing my software in line with other software by being less fussy about the data.
Others can argue about whether a 10Hz device should produce better quality data or whatever. I don't care. As long as ka72 gives similar results to other software that satisfies me.
Yep, you definitely have an SDOP problem but it isn't coming from the Motion log, here's the same log (freshly downloaded from KA72) opened in GPSAR:
Now we know what's up! Speed is right, course is right but SDOP and HDOP are imported wrong.
And it would explain tbwonder's finding. His OAO->SBP file was imported right, his OAO file was imported wrong.
No wonder you thought the devices/logs were crap.
Woohooooooooooo it ain't on me!
It's been a weird few hours getting my devices called crap and worse than others and having SDOP of 3 or more during runs. :D
I'm going to party like it's 3:23am, in my bed.
P.S: Matt stop using an aquapac, you're ruining my speed accuracy average. :D
Select to expand quoteJulienLe said..
Woohooooooooooo it ain't on me!
It's been a weird few hours getting my devices called crap and worse than others and having SDOP of 3 or more during runs. :D
I'm going to party like it's 3:23am, in my bed.
P.S: Matt stop using an aquapac, you're ruining my speed accuracy average. :D
Well, I never said any of that, but there is a bug I just found in the oao library I am using that is inflating the SDop figure by a factor of 10. (The GPSAR data you posted above is in knots, whereas mine is in m/s, but you can see the error when you convert them to the same base.)The bug was ported over from the UBX library I am using, which has the same bug. It converts the Sdop data from mm/s to m/s by multiplying by .01 instead of .001.
I have a feeling this mistake was made because in extraction the Pdop figure is multiplied by .01 in order to rescale it back from what is stored, and whoever wrote the original library just assumed you do the same thing to Sdop.
So, having adjusted that, everything still works, and probably works better than before. Also there was probably no need to adjust the SDop margins for 5Hz and 10Hz devices (which was likely just hiding the error rather than fixing it.)
This seems like a good outcome for everyone.
Sweet dreams Julien, hope you are reading this in the daylight hours.
Yeah no I'm pumped. What an emotional rollercoaster. :D
Now do they have to re-upload their logs? Or will you re-compute them?
Glad it's over! Thank you!
Select to expand quoteJulienLe said..
Yeah no I'm pumped. What an emotional rollercoaster. :D
Now do they have to re-upload their logs? Or will you re-compute them?
Glad it's over! Thank you!
When the new engine goes out, results will be recalculated whenever a track page is opened using the new version of the engine. As soon as anyone visits the overlay page, the results should be recalculated for that track. It is possible to force a global recalculation but that is an enormous exercise that eats up a ton of time, so I usually leave it the easy way.
Seems that ka72.com converts the SDoP (actually, sAcc) values wrong, ending up with 10x higher values:
The left side shows the numbers Dylan posted and which ka72.com apparently uses. The right side shows the correct numbers (from GPS Speedreader, converted from knots to m/s since that's what Dylan used).
This is, without any doubt, a bug in the ka72.com code. It would have been very easy to find and fix if Dylan had ever bothered to compare his SDoP values with those that GPSAR, GPS Results, or GPS Speedreader show. Would not have cost anything, either, since GPS Speedresults is free. But he did not, instead insisting that it must be someone else fault.
An apology to Julien would be in order.Select to expand quoteDylan72 said..
When I adjusted the software to use a margin of 4 instead for 5Hz and 10Hz devices, the miscalculations went away.
That will not fix the issue correctly, if ka72.com still reads the sAcc values wrong by a factor of 10. It may fix the issues for some files, but it sets a threshold of 0.4 m/s, or 0.777 knots. As stated above, GPSResults and GPS Speedreader have default thresholds of 4 knots (about 2.05 m/s). It is quite possible to get error accuracy values of 0.8 with the Motion, for example if the armband slips.
Took me a while to write the post above. Seems Dylan figured out what was wrong while I was writing the post, so all should be good now.
Thanks Dylan for taking the time to solve the issue. KA72 is an extraordinary resource. The GPS windsurfing community is very lucky to have it.
