I have noticed a large difference of roughly between .5 and 1.5 knots in alpha speeds calculated by KA72 and GPS Speedreader. KA72 is higher. I've sampled tracks going back to early 2018 (prior to "week rollover"). Is this a known thing? Alpha is the most important category to me so I want to get it right. This seems like a big disparity.
I'd be trusting GPSSpeedreader. Peter is a professional analyser, it's his job to write analytical software.
Alfa tracks can suffer from bad data at the gybe transition, depending where the GT31 is worn.
I went thru GT31 data for a sailor getting poor accuracy during gybes. He was wearing the GT31 so he could easily read the display. So when he leaned into a gybe, the antenna was pointing at the water. His team captain disallowed a PB alpha because of a spike in the gybe. So we determined that the the best data for accurate alphas, was to wear the GT31 on the upper shoulder pointing slightly away from the face.
Unless you are doing that you will have some bad data in your file.
KA72 filters are much more lax that GPSSpeedreader, I think that's where the extra speed is coming from in KA72.
Can you post the speed graph of an alpha with a big discrepancy? with the accuracy data.
I too am trying to improve my alphas. I wear a GW60 on my wrist and a Motion on my bicep. I send all my results through KA72, so I decided to see if opening my top five alphas in GPS Speed Reader changed anything. The last four are pairs on the same day from different devices. It all seems extraordinarily close. I generally upload to KA72 from the carpark and then download from KA72 to my laptop when I get home so I can look more closely with GPS Speed Reader. I doubt KA72 would edit to downloadable file?....
KA72 GPS-SR FILE UNIT
22.588 22.639 SPB MOTION
22.597 22.597 SPB GW60
22.835 22.835 OAO MOTION
22.943 22.943 SPB GW60
22.887 22.887 SPB MOTION
23.023 23.023 SPB GW60
23.053 23.053 OAO MOTION
Select to expand quoteShifu said..
I've worn my GPS on the shoulder strap of my life-jacket for the last ten years.
Well that's probably the reason, on your shoulder, when you lean into a turn, a lot of the sats that were previously being used are shadowed by your shoulder. That means the GPS has to refresh available sats, then when you gybe it all changes again. So just before the turn and just after the GPS is in a state of confusion. The GT31 is only using 1 GNNS so the number of sats is limited to start with.
Have a look at the accuracy numbers when you turn, I bet they are quite high, under the KA72 filters, but over the GPSSpeedreader filters.
In Remery's examples, only i alpha is different, that's the one with the spike mid turn I bet.
Rob can you post the speedgraph of that alpha?
I can't see anything out of the ordinary there.
Have you tried turning the GPSSpeadreader filters off. That should put it in the same mode as KA72.
If there's still a difference, that's a new mystery.
Other things to look for,
1/ missed points, KA72 and speedreader may handle missed points differently.
2/ acceleration, ms/s^2 (you can include that in the top column), There's definitely a big difference here, but just looking at the tracks, there doesn't seem to be a big enough spike to cause that.
Select to expand quoteremery said..
This is the 22.639 Alpha. The one that KS72 calculated as 22.588.
I agree with Mike, I cant see anything out if the ordinary here either. The very small difference can be due to things like if one file is 10Hz and the other is 5Hz. therefore it could be very slightly different start and end points.
Also, the way the software algorithm is implemented may be very slightly different and shifting the start and end points one ot two points either way.
Anyhow, they is still very close and probably insignificant for all intents and purposes.
It looks like the other results you published up higher are identical. thats great, but probably slightly unusual too! 
Often when comparing Alpha results in different software from the same file I gets results that are 0.001 apart, and sometime even 0.01 different if there is round up or down (as in GPSAR-Pro with gives results rounded to two decimal places). Thats from the same file and is pretty much insignificant IMHO.
Yes, I thought it was odd that many alphas were identical whether processed by KA72 or GPS Speed Reader. Maybe I messed something up.
Thanks to sailquick I have learned that turning off filters in GPSSpeedreader gives results very close to KA72 as it had been filtering out some gybes presumably affected by masking of the GPS unit in the turn. It doesn't seem that the option exists in the Linux version though.
I've moved back to placing the GPS on the upper arm, but it's an uncomfortable solution at present.
If you turn filters off it will refuse to upload to the GPSTC.
And on my linux version I can turn filters off. V2.2.1
Settings > Filter settings > untick "use default settings for filters" and "apply filters"
Select to expand quoteremery said..
I haven't updated for a while and there is no Filter option on my version.
Must be years Rob, filter selection has been there for a long time.
My version says the shortcut is Alt-F.
Give that ago and see what happens?
Totally weird, just updated to 2.2.2 and I still have the filter options in settings. Maybe ask Peter what's going on.
Is it a Java difference between our machines?
Mine is,
openjdk 11.0.20.1+1
Select to expand quoteShifu said..
Version 2.2.2. No filters menu item
Under preferences, look at the bottom of the menu and select 'show expert menus items and columns'
After ticking that. close it. Open the 'settings' menu again and you will see the filter settings.
Best not to fiddle with them as they are set for the default GPSTC settings. If you turn filters off, it won't let you post to GPS-TC, but it is sometimes quite useful to troubleshoot, as it is in this case.
I only remembered this step when I loaded the windows version to test it.
Select to expand quoteremery said..
This is the 22.639 Alpha. The one that KS72 calculated as 22.588.
If you look at the error estimates (sAcc) in your track, you can see a bunch of sAcc values between 1.0 and 1.5. With the default threshold of 1.2, a bunch of points in the faster approach leg will be ignored. That's assuming that your data are u-blox data (Motion or ESP32 logger).
This high error estimates indicate that the GPS was worn in a way that did not let it get a good reception in one direction. That's often seen in GW60 data when an underhand grip is used.Select to expand quoteShifu said..
I have noticed a large difference of roughly between .5 and 1.5 knots in alpha speeds calculated by KA72 and GPS Speedreader. KA72 is higher. I've sampled tracks going back to early 2018 (prior to "week rollover"). Is this a known thing? Alpha is the most important category to me so I want to get it right. This seems like a big disparity.
You are using a GT-31, which often gets just enough satellites for accurate GPS speeds when worn properly. But you're wearing it on a life jacket strap, which means your body is often blocking satellite signals, creating crappy data. ka72 does not care because it does not use SDOP filters (in theory it does, in practice the thresholds are wrong). GPS Speedreader finds the bad points and does not use them to calculate alphas. Since the GT31 logs just once every second, the effect is much larger than with newer units that log 5 or 10 times per second.
Newer u-blox based units that use a lot more satellites than the GT31 have a lot more robust data quality. Nina (my wife) always wears a u-blox logger in a bag that's attached to her harness when winging. Even with the sub-optimal placement, the accuracy estimates are pretty much always below the filter thresholds. The only exception are crashes, where she often gets 200 knot spikes when the GPS is fully submerged and starts to make up stuff. Those spikes are easily removed by the filters in Speedreader (don't know about ka72 since she does not use it).
Select to expand quoteboardsurfr said..remery said..
This is the 22.639 Alpha. The one that KS72 calculated as 22.588.
If you look at the error estimates (sAcc) in your track, you can see a bunch of sAcc values between 1.0 and 1.5. With the default threshold of 1.2, a bunch of points in the faster approach leg will be ignored. That's assuming that your data are u-blox data (Motion or ESP32 logger).
This high error estimates indicate that the GPS was worn in a way that did not let it get a good reception in one direction. That's often seen in GW60 data when an underhand grip is used.
Thats was with a motion which may well have slipped under my bicep.
Trying to work out a better way of attaching the GT31. Tried it on my upper arm the other day, but it's slipped down a few times until I had it tourniquet tight. 
