Select to expand quote

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

+1, great site Dylan, as I'm not playing for sheep stations it's great to have a resource that's transparent where I can see other results and tracks to improve my sailing??

Thank you all who were participants in the above discussion, though I have to admit that 99% of it flew way over my head. You are all such a great resource to our speed surfing community. Cheers guys.

Thank you Dylan we all love posting to and via KA72
Many people around the world appreciate your efforts to quietly keep this free service running

Looks like powersloshin's and boardsurfr's examples are correct now.

www.ka72.com/Track/t/482965
www.ka72.com/Track/t/483822
www.ka72.com/Track/t/483517

Revisit your personal records, you might be owed some speed.

Select to expand quote

JulienLe said..
Looks like powersloshin's and boardsurfr's examples are correct now.

www.ka72.com/Track/t/482965
www.ka72.com/Track/t/483822

Great work Dylan, we all apprciate your hard work. Cheers

I'll put a damper on the good mood by saying that it isn't normal that devices, logs, other softwares, other developers, and other filter settings have first been tarnished for what ended up being a really simple and inoffensive import mistake. This could have been avoided. It's hard building trust in this sport and this doesn't help. If we want to see it grow again, we'll have to do better.

Thanks for your good wishes, those of you that have them. As has already been noticed, the fix is in the site now, so I'm signing off this thread. Sorry it took so long to pick it up. Please be aware that although people have been in touch with me regarding this situation for some time, I really haven't had time to look at it until yesterday, so there is no sense implying that I've been deflecting or blaming anyone. I get the impression some people think I've been stalling on this deliberately and trying to assert things that I really haven't. Feel free to reach out if you have further questions or issues.

Yes, my tracks now appear to be reporting correctly in KA72. Good find Dylan

It doesn't fully explain why the 100m speeds where being reported correctly, I can only assume that the sdop filtering is less stringent for 100m than it is for 2 sec peaks. Although some of my 10 secs also where incorrect and a 10 sec run is generally a longer distance than 100m.

Anyway the problem is solved now, so we can all get back to bitching about why we can't post with Garmins, or when will those 'changes' finally happen to GPSTC.

Select to expand quote

tbwonder said..
Yes, my tracks now appear to be reporting correctly in KA72. Good find Dylan

It doesn't fully explain why the 100m speeds where being reported correctly, I can only assume that the sdop filtering is less stringent for 100m than it is for 2 sec peaks. Although some of my 10 secs also where incorrect and a 10 sec run is generally a longer distance than 100m.

Anyway the problem is solved now, so we can all get back to bitching about why we can't post with Garmins, or when will those 'changes' finally happen to GPSTC.

I mentioned earlier that one or two points thrown out from a dozen over 2 seconds will have a much bigger impact than over 100m, where the same one or two points will be thrown out from hundreds.

Select to expand quote

remery said..

tbwonder said..
It doesn't fully explain why the 100m speeds where being reported correctly, I can only assume that the sdop filtering is less stringent for 100m than it is for 2 sec peaks. Although some of my 10 secs also where incorrect and a 10 sec run is generally a longer distance than 100m.

Anyway the problem is solved now, so we can all get back to bitching about why we can't post with Garmins, or when will those 'changes' finally happen to GPSTC.

I mentioned earlier that one or two points thrown out from a dozen over 2 seconds will have a much bigger impact than over 100m, where the same one or two points will be thrown out from hundreds.

There are different ways to implement the filters. The last time I looked, GPSResults did not allow 2 sec and 10 second top speeds to include any filtered points, but some of the longer distance speeds were allowed to include them (for example alpha 500 and nauti).

From the observations posted in this thread, ka72 seems to follow a similar approach, and the 100 m may already use the "longer distance" kind of filtering. That would include the filtered points which cannot be part of the 2 seconds (possibly replacing their speed with the average of the neighbor points, of something similar), and thus give a faster 100 m speed.

Select to expand quote

JulienLe said..
I'll put a damper on the good mood by saying that it isn't normal that devices, logs, other softwares, other developers, and other filter settings have first been tarnished for what ended up being a really simple and inoffensive import mistake. This could have been avoided. It's hard building trust in this sport and this doesn't help. If we want to see it grow again, we'll have to do better.

For as long as I can remember there has been nothing but all positive feelings and words about the motion product, we all value what you bring to the sport thanks so much Julien.
Don't take this the wrong way but the real damper is the much talked about supply issues of motion screen orders, the ones that are leaving soon, the ones still in transit without tracking, the ones that were returned to sender
Have a great Christmas we all have our fingers crossed for a better 2022
Cheers Rod

> the ones still in transit without tracking
Doesn't ring a bell sorry.

> the ones that were returned to sender
Two parcels, delivered ages ago.

But you're right, things are going to change.

Have a great Christmas too!

Dylan, you may want to look at this track from a team mate today.
Clearly a spike, but KA72 is saying it is a valid 2 sec.
www.ka72.com/Track/t/483901

The sdop is not great but is ok. But I believe the 1hz acceleration filters should have picked this up.



Interestingly GPSSpeedreader and GPSresults also report the 2 sec peak incorrectly, But not as badly as they both filter out the first part of the spike. But incorrectly allow the following two points. It would seem reasonable to reject the next point after a spike of this size.

RealSpeed reports correctly.

Remember we are talking about 1hz data from a GT31

I had a look at that one too. It's and interesting one as even when I tried quite a few filter settings it was hard to get rid of. No filters are perfect, which does mean that a bit of old fashioned vigilance is always necessary.

Interesting that you say RealSpeed picks it up. I will have a look at that and see if I can find out why.

Interesting spike, with a sudden jump from 19.1 knots to 30.5 knots. That gives an acceleration of 5.85 m/s2, which triggers the acceleration filters in Speedreader and GPSResults.


Pretty rare to see such things in GT-31 data, but not the first one I've seen, either.

There would be pretty straightforward ways to improve the filters, which would be needed here. You'd need to also filter adjacent points in this case. Similarly, error estimate filters for data from u-blox chips (Motions) should be adjusted to take into account that u-blox error estimates rise very slowly. Current filters miss some artifacts.

But while this would be relatively easy to do, I can't see it happening. If I just put better filters in Speedreader, users will see that some sessions give higher numbers in other software, and stop using Speedreader. Seems that ka72.com does not use acceleration filters for GT-31 data at all, or has a threshold that's too high.

Note that the current threshold that ka72.com uses for GT-31 data (3 m/s = 5.7 knots) is so high that it can never be triggered by data from GT-31s, since the maximim SDoP value the devices write is something like 4.97. So the accuracy filter is never used for GT-31 data on ka72.com. Which strikes me as pretty ironic.

Select to expand quote

boardsurfr said..

Note that the current threshold that ka72.com uses for GT-31 data (3 m/s = 5.7 knots) is so high that it can never be triggered by data from GT-31s, since the maximim SDoP value the devices write is something like 4.97. So the accuracy filter is never used for GT-31 data on ka72.com. Which strikes me as pretty ironic.

I thought KA72 rejected areas of the track with an sdop >2 for a GT31

Select to expand quote

tbwonder said..
I thought KA72 rejected areas of the track with an sdop >2 for a GT31

The number is 3, but the more important thing is the units.

If you look at the table Dylan posted, the point with an SDoP above 3 are marked as rejected. But his units are m/s, not knots, and 3 m/s equals 5.83 knots.

For the Motion tracks that gave incorrect results, ka72.com multiplied the speed accuracy with a factor of 10, so points with and error of 0.6 knots would have the (incorrect) error of 3.08 m/s, which triggered the filters.