I undertook this project over Easter and thought it probably worth sharing to the technically inclined within this forum.

Hopefully it'll prove to be an interesting read to anyone who's ever wondered how alphas can be calculated with minimal computational overheads.

Working code is also included (written in Python) and is heavily commented to show it working in practice.

logiqx.github.io/gps-wizard/alpha-racing/

Nice. A couple of quick comments:
- 250 m as the minimum is too high. Legitimate alphas can be 50 m or dy > 50. That avoids the sqrt and the **2 calculations, which can be very costly when done on minimal (watch etc.) hardware. The square root can be dropped completely, since we know what the square of 50 m is
- Alphas generally can have filtered points, including low speed points.

Instead of stopping the inner loop when you reach a low speed point, a similar approach is to set a maximum for the elapsed time, based on a minimum speed threshold for the alpha result (for example 8 or 10 knots). That has a large effect if you look at tracks that have longer stationary periods in them, where going on until you reach the 500 m max would take way too long.

The shortcut to look at the angle difference can theoretically be incorrect, since both the beginning and start of an alpha run are allowed to be more than 45 degrees of the wind. In reality, this will be very rare, though.

To test the performance of improvements, make sure to use 10 Hz data from long sessions, including some with longer breaks. Even non-optimized algorithms can do ok for 1 Hz data, but will be 100-fold slower at 10 Hz, since the core of the algorithm will have N-squared performance (which is still true for the optimizations you described, at least with respect to Hz rate).

Thanks for the feedback, very much appreciated. I've now removed the sqrt entirely (silly of me not to see that one) and added individual dx and dy checks to avoid an unnecessary xDelta ** 2 + yDelta ** 2 where possible. Removing that final sqrt means the Pythagoras calculation is now devoid of all the costly CPU instructions used by the Haversine formula; e.g. trig functions, sqrt and division.

# Cost comparison of math and trig operations which cannot be cached
# Haversine Cost: Asin = 1, Sin = 2, Cos = 0, Sqrt = 1, Divide = 2, Square = 2, Multiply = 3, Subtract = 2, Add = 1
# Pythagoras Cost: Asin = 0, Sin = 0, Cos = 0, Sqrt = 0, Divide = 0, Square = 2, Multiply = 1, Subtract = 2, Add = 1

I investigated max time to see how well it would work but the savings were quite modest with my speed filter still in place (>= 1 m/s) and the overheads actually costed more than they gained. Whilst my speed filter might drop some valid alphas, the gains are pretty huge (> 50% saving on one of my test tracks) and outperformed the max time approach when I tested it in isolation. I feel the speed filter (>= 1 m/s) is a reasonable compromise to make in this instance, especially when calculating alphas in real-time. It is an effective way to ignore beach time and drifting around whilst any genuine alphas containing a speed < 1 m/s are probably of zero interest.

The angular difference is of course another pragmatic compromise that I'm reasonably comfortable with but I'd be genuinely interested to see if anyone does any alphas where they approach their entry point at 90 degrees. I think you'd have to sail upwind (say to within 45 degrees) on alpha entry and then do the same on exit which I think would be quite difficult and not good for your alpha result. Sailing across the wind during entry to the alpha and then straight into the wind on exit is also feasible over short distances (well, maybe on a foil) but would be a terrible alpha tactic imho. :D

When it comes to 10 Hz data which as you say, suffers from an N-squared performance profile, I think for real-time calculations it may simply be better to either downsample and report 1 Hz alpha results or do a multi-pass approach where you start by downsampling to 1 Hz and then do a second pass (or even a binary-search) between the most promising downsampled alpha results to find the optimal alpha. I can't say whether it would be worth the effort without doing some analysis but it may be worth looking into if people want perfect 10 Hz results in real-time.

Thanks again for taking the time to look at the code and provide feedback.

I'm particularly pleased to see that final sqrt is no longer present. :)

Interesting stuff. Pity you didn't write this two years ago, it would have saved me the trouble of working it all out for myself.
For my Garmin Datafields I check for alphas between 200 metres and 500 metres in length. Also the alpha has to be completed in 60 seconds. Limiting to 60 seconds was initially a constraint of the older watches that I was trying to support that have only 16k or 32k of user memory. This memory disappears very quickly when you start having to define multiple high precision 60 word arrays.

As I am calculating and displaying the alpha in real time, as well as graphically drawing the shape of the alpha on the screen I was concerned that the Haversine formula would take to much time. I did consider simplifying the Haversine calculations, but it was never necessary. I have no idea how much processing time per second is allocated to Datafields but I have never had a problem with the code not completing in time.

Select to expand quote

tbwonder said..
Interesting stuff. Pity you didn't write this two years ago, it would have saved me the trouble of working it all out for myself.
For my Garmin Datafields I check for alphas between 200 metres and 500 metres in length. Also the alpha has to be completed in 60 seconds. Limiting to 60 seconds was initially a constraint of the older watches that I was trying to support that have only 16k or 32k of user memory. This memory disappears very quickly when you start having to define multiple high precision 60 word arrays.

As I am calculating and displaying the alpha in real time, as well as graphically drawing the shape of the alpha on the screen I was concerned that the Haversine formula would take to much time. I did consider simplifying the Haversine calculations, but it was never necessary. I have no idea how much processing time per second is allocated to Datafields but I have never had a problem with the code not completing in time.

Ah, sorry about the timing. It is an interesting topic to explore but I only recently decided to look into it.

One of my motivations for this project (aside from the "fun" aspect) is that I'd like COROS to fix the alphas on their watches. I figured some working open source code, tested using FIT data from an APEX Pro can only be a good thing!

In terms of the computational cost we should consider the available time window (available CPU clock cycles) and power usage (battery life) so I think it could still be good to avoid the Haversine costs, even if processing time is not an issue at 1 Hz.

I like the concept of your realtime display on the Garmin. I don't own a Garmin myself but nice work!

Agreed, there is no point in unnecessary calculations. It would be nice to know how long my code takes to execute on the Garmin watches. AFAIK there is no tool to calculate this. I am not aware of a tool on the PC simulator that measures the run time either.

My algorithm searches only for the highest avg speed over the 500 m distance (actually the speedpoint just before the 500m). Therefore, I will not always have the correct max alfa value . But the cases that a "record" alfa is within a distance much smaller then 500m is rather unlikely !
So, no loops are necessary with every new sample.
Avg speed over the 500m is calculated out of a buffer with speed-points. With every new sample, the pointer of the "start" position of the 500 m is adjusted. The total sum of all the speedpoints within this 500 m is then adjusted in the same way : The new sample is added, and the old "starting" point samples are subtracted. Avg speed is then total sum/nr of samples.
I still had a sqrt in it, but this is obviously not necessary, thanks for the tip !
I also added some extra fields on the display, so you can aim for the 50 m distance. The "exit" is the predicted distance, the window is the actual distance !
Algoritm behind is the mathematical distance between a line and a point.

Select to expand quote

rp6conrad said..
My algorithm searches only for the highest avg speed over the 500 m distance (actually the speedpoint just before the 500m). Therefore, I will not always have the correct max alfa value . But the cases that a "record" alfa is within a distance much smaller then 500m is rather unlikely !

That may be true for "records", but it is often not true for the best alpha in a session. That depends a lot on how long the runs are, how many jibes are good, how steady the wind is, and if you have alpha markers. Short runs and gusty winds make shorter alphas more likely. Someone who is still working on jibes, or sailing in chop, may have only a few fast jibes per session, which also makes shorter alphas more likely.
Here's an example from a random Lake George session where the best alpha 500 run was only 348.8 m long:



This is from a 39 km session with 40.1 knots top speed in flat water, so this is a relatively good speedsurfer.

For real-time calculations in the watch, fixing the run length to "exactly" 500 meters is also unnecessary, since you already have one end of the range fixed. Instead of iterating over all possible end points, you only need to look at a start point. Compared to post-run analysis of a track, this reduces the computation time by 4 to 5 orders of magnitude. For example, finding alphas from the track above, which has 53 thousand points recorded at 10 Hz, takes about 0.1 seconds on a computer (using only 1 thread, allowing 100-500 m). This looks at 48862 possible end points, and (on average) at 655 possible start points per end point, for a total of about 32 million start-end combinations. With a fixed end point, the algorithm has to look at only 655 points - something an ESP32 certainly certainly can do in a lot less than 0.1 seconds.

The problem with shortcuts like "exactly 500 m", or looking at the COG angle difference, or stopping when the speed drops below 2 knots for a single point, is that they sometimes fail to give the correct alpha result. These failures are unpredictable, since they depend on the characteristics of the track: "untypical" data will cause failures.

But these shortcuts are not necessary. They can be replaced by shortcuts that give predictable results. For example, tbwonder's limit to 60 seconds means that alphas slower than 16.1 knots (500 m / 60 seconds) are likely be missed, but all faster alphas will not be be affected (although the algorithm may report lower speed alphas for shorter distances, depending on the exact implementation). In GPS Speedreader, there's a similar maximum time of 194 seconds, which means alphas under 5 knots will not be reported. But Speedreader runs on much faster hardware, so it can look at a larger window.

Besides picking the right shortcuts, avoiding costly and unnecessary calculations is very important, and the original post gives some great examples for that.

I very much like the idea of a GPS telling you if you are on track for an alpha in realtime. It would make it so much easier to try for decent alphas, or so I would imagine!

When I developed and tested my alpha code over easter, I decided to use GPSResults as a baseline for "expected" results. I used a few distinct types of session (speed, slalom and foil) to check what results were being generated by my code. However, despite differing kit and gybing styles to suit, it was still me gybing so not representative of all sailors and styles.

In all of the sessions that I tested, I got exactly the same alpha results as the top 50 listed by GPSResults, but I also found some additional alphas where the runs "overlapped" (i.e. back to back gybes with hardly any straightline sailing) where GPSResults ignored the slower of the two alphas. I guess it is debatable whether alphas should be allowed to overlap (e.g. one starts a few seconds before the previous one finishes) but imo it seems reasonable to consider every distinct gybe to be distinct alphas.

What is now clear is that no two pieces of software currently produce the same list of alpha results; GPSResults, GPS Speedreader, GpsarPro, ESP, GW-60, COROS, Garmin Datafields, or myself. In theory a set of reference data and results could be published with expected speeds so that all of the developers can automatically test their software; via unit tests, or whatever. I'm not necessarily proposing that idea, just making a general comment about what could be done with the will.

Ultimately by far the best alpha optimisations that I found were avoiding the Haversine formula. Good ol' Pythagoras provides more than enough accuracy for alphas at a fraction of the cost of Haversine, plus the ability to re-use computed values. The other hacks / filters can either by tweaked or dropped entirely, depending on the particular use case but from a purest point of view, I'd be inclined to agree with boardsurfr.

Thanks for all of the comments and insights detailing the different approaches being taken by different developers. All contributions have been very interesting and thought provoking.

Select to expand quote

K888 said..
What is now clear is that no two pieces of software currently produce the same list of alpha results; GPSResults, GPS Speedreader, GpsarPro, ...

When developing GPS Speedreader, I compared the results in all disciplines, including alpha, to both GPSResults and GPSAR Pro, using something like 100 files from different sailors, locations, and GPS units, looking at the top 5 results in the GPSTC disciplines. In the vast majority of cases, the results were identical for the 3 programs (within 0.1% to allow for small rounding errors and differences in reported precision).

There were just a few cases where the differences were larger (between 0.1% and 1%). A couple of times, the alphas were significantly shorter than 500 meters since the ends pulled apart. The different programs apparently use different methods to calculate gate widths, so run lengths chosen for the alpha results differed by a one or a few points. The biggest difference in alphas (above 8 knots) was in one file where the #5 alpha included a point that exceeded the acceleration thresholds. GPSResults simply included this point (so it did not use the acceleration filter at all in alpha runs), while Speedreader set the speed of this point to zero. That resulted in a speed of 25.134 in GPSResults, and 25.049 knots in Speedreader. The difference is smaller than the accuracy estimate (+- 0.14 knots).

Since then, there have been a few cases with reported alphas where the programs gave different results, especially if the filter thresholds were modified (e.g. by using a lower accuracy threshold for Motion data). But in the vast majority of cases, and in all top alphas in the test data set, GPSResults, GPSAR, and GPS Speedreader gave exactly the same results. In general, this is also true for files analyzed on ka72.com (although there seem to be some differences in filter thresholds, which cannot be adjusted on ka72).

If I recall correctly, GPSAR actually adjusted how it calculates alphas when we ran these tests. It originally had not allowed runs to be much shorter than 500 m, but changed this to follow the same rules as GPSResults etc.

The biggest differences in the tests were actually not in the alpha calculations, but in the 1 hour calculations. One problem occurred with files recorded with a speed minimum, which caused some programs to pick the wrong 1-hour range, and under-report speeds by a knot or so. Another issue was that some programs would give 1 hour averages of 0.0 for sessions shorter than 1 hour, which resulted in even larger differences.

Select to expand quote

tbwonder said..
It would be nice to know how long my code takes to execute on the Garmin watches. AFAIK there is no tool to calculate this. I am not aware of a tool on the PC simulator that measures the run time either.

If you really want to know, do the equivalent of println debugging. Run you code in a loop, setting the result to the loop counter. Show the results once a second, and you know how often per second you can run your code.

I'm using a similar approach when benchmarking even on a desktop computer where I have all the measurement tools quite often to verify profiler results. As useful as profilers are, they can sometimes give quite misleading pictures.

Select to expand quote

K888 said..>>> What is now clear is that no two pieces of software currently produce the same list of alpha results; GPSResults, GPS Speedreader, GpsarPro, ESP, GW-60, COROS, Garmin Datafields, or myself. In >>>.

The GW60,does 1 thing different to all /most of the rest. It calculates the end separation by doppler position.
We tried to talk them into using positional data like every body else. But Tom Chalko had convinced them that doppler is more accurate.
That may be true with head mounted devices when the sat view is uninterrupted through the whole run. But the GW60 can have a few seconds of bad reception and a changing sat view at the gybe point. This can make +/- a meter or so difference at the 500m mark. So there will be differences in allowable alphas. Very disappointing when the watch says you have a PB, but your software says that alpha had a separation of 51 metres.

Select to expand quote

decrepit said..
The GW60,does 1 thing different to all /most of the rest. It calculates the end separation by doppler position.
We tried to talk them into using positional data like every body else. But Tom Chalko had convinced them that doppler is more accurate.
That may be true with head mounted devices when the sat view is uninterrupted through the whole run. But the GW60 can have a few seconds of bad reception and a changing sat view at the gybe point. This can make +/- a meter or so difference at the 500m mark. So there will be differences in allowable alphas. Very disappointing when the watch says you have a PB, but your software says that alpha had a separation of 51 metres.

From my memory of it, I don't think Tom Chalko would have said that Doppler derived proximity position is "more accurate". I am pretty sure he knew the issue with that method and why it was rejected. My understanding is that use of Doppler derived position for the proximity circle was to dramatically reduce processing overheads in the GW-60 watch. The 'Genie' reports in the Locosys devices were only ever meant to be an indication for 'on the water feedback'.

For GPS-TC, the rules state that one must post from one of the recognised software analysis programs and may not simply post the screen results, or from internal calculations reported by the GPS device. (For some of the reasons well illustrated above. )

Quote from GPS-TC rules: 'Note: Posting from the screen results or the text digest file is specifically not allowed.'

Perhaps this needs further clarification in the rules text, as it could possibly be misinterpreted that this only applies to certain devices, which is not the intention or the case.

Mal Wright conceived and defined the 'Alpha' category and his pioneering GPS analysis software "RealSpeed" included it from almost the very first edition (Circa 2004). He actually included Alpha categories for 250m, 500m and 1000m, not being certain which would be most practical or which would catch on. It turned out that the A500 was the one that caught on and this was further reinforced when GPS-SS and GPS-TC included it in their rankings. Yann and Manfred were quite diligent in the way they implemented the A500 to make sure all three programs got the same results. Likewise for Peter when the excellent GPS-Speedreader program was developed.

Alas, RealSpeed is no longer supported or being developed, but it is still available for those who want to play with it. It has some limitations with 5hz and 10Hz data, but can still do some things that other programs cant do. The last version, that got some updates to better deal with 5 and 10Hz, is V2.001. It is now free to use, but there is no support from Mal. It is Windows only.
.
PS: I just ran my 10Hz track with my best 2022 Alpha in RealSpeed V2.001 and it worked fine. It was very slow to calculate, but that could be partly because I run Windows7 in my MacBook Pro under VMware emulation.

I don't understand how you could calculate the 50 m proximity circle out of the doppler data. There is only information about he speed, so how could you derive the exact distance between two positions which have a total path of 250 m / 500 m ?
You could integrate from point to point with the speed and the heading, but this looks total ridicoulous, as the error will integrate as well.

Regarding differences between GPSResults, GpsarPro and GPS Speedreader. This data was from a recent foiling session of mine on a small lake with lots of short runs and tight-ish turns. It's actually the same session that made me look at acceleration artefacts caused by 10Hz data.

It was completely by chance that I used this as the main session whilst testing my alpha code and it picked up the following differences between the "big 3" tools. The 1 Hz GT-31 track produces 3 distinct lists of the top 5 alphas, selected from 6 unique runs.

I've colour coded the runs so they can be visually matched up. GPSResults and GpsarPro both ignore 20 knot foiling alphas which I suspect is to do with the close timings. They are basically back-to-back alphas but not quite overlapping. As an aside, my alg actually allows these two alphas to overlap by a few seconds. Trying to optimise multiple alpha results to avoid any overlaps would be a right can of worms!


This particular session also highlighted (to me) the significance of an inbuilt "mininmum distance" for alphas. I initially tested my code using a 100m minimum distance (completely independently of GPS Speedreader which has also been using 100m) as it seemed like a good distance to use. It was only when I started comparing the top 50 results with GPSResults (based on start/end times, results and distances) that I increased the minimum distance to 250m to make reviewing any differences less tiresome. I'd be happy to use 100m again, since it makes little difference performance wise but I kept 250m to avoid discrepencies with GP3S posts.

At the end of my testing, I'd concluded that my code produces lists of alphas which match the GPS Speedreader algorithm, picking up alphas that neither GPSResults or GpsarPro will allow / discover. Most of the differences between my code and GPSResults tend to happen further down the alpha list (sometimes still top 10 but often times down at #30 and below) but nevertheless, I think the results that GPS Speedreader and my code identify are more thorough. I'm aware that I ignore runs where speed drops below 2 knots but that was a conscious decision.

I also considered exploring the difference(s) when using Doppler + COG for proximity checks but decided it wasn't worth the effort since it would be highly inaccurate for COROS tracks where COG is an integer. That's also ignoring the fact that we know lat + long proximity checks are more appropriate for older devices from past studies, quite likely true on modern devices as well.

Each watch has decided on its own compromises - GW-60 (Doppler + COG proximity checks), Garmin (max time 60 seconds would ignore some of my lightwind wingfoil gybes) and then there is COROS (no proximity check at all).

The COROS is the one that I find most disappointing. To see a 27.8 knot "alpha" on my wrist after one of my fastest gybes ever lead to huge disappointment when I discovered it was actually >50m proximity and that the next best was 22 knots on that day!

Select to expand quote

rp6conrad said..
I don't understand how you could calculate the 50 m proximity circle out of the doppler data. There is only information about he speed, so how could you derive the exact distance between two positions which have a total path of 250 m / 500 m ?
You could integrate from point to point with the speed and the heading, but this looks total ridicoulous, as the error will integrate as well.

Yes, every Doppler data point has a heading as well as a velocity. That is how it was done: point to point heading extrapolation. The big problem with that approach is that any small error in the heading, especially on the Gybe (where a heading error seemed to be more likely anyhow) affected the path from there on. This could cause to big discrepancy for the proximity circle (too small to too large) and often did when we tried it. It was common for a heading error in the gybe to cause the path to go off at a wider angle and the track in the calculation would not be anywhere near the 50m, resulting in no alpha result when there should have been one. Likewise, an error in the heading could result in a calculation of an Alpha, when in reality, there was none. Even a small error that tightened up the turn could result in a faster Alpha, as it put the calculation point at a longer distance inside the 50m circle for a longer track (but still under the 500m limit).

From memory, Mal didn't put any minimum distance on his Alpha calculation, but of course the track had to hit the 50m circle.

For practical purposes, Manfred chose 100m min, and this makes sense. We are usually really only looking for, and interested in the top few alphas in any session, and they tend to be the ones pretty close to the maximum 500m distance the vast majority of the time.

Select to expand quote

sailquik said..
From memory, Mal didn't put any minimum distance on his Alpha calculation, but of course the track had to hit the 50m circle.

For practical purposes, Manfred chose 100m min, and this makes sense. We are usually really only looking for, and interested in the top few alphas in any session, and they tend to be the ones pretty close to the maximum 500m distance the vast majority of the time.

It would appear that Manfred has implemented a 125m minimum for @250, 250m minimum for @500, and 500m minimum for @1000. This is only anecdotal but it's all I can see, whereas when I change the limit in my code, I get some shorter alphas not listed by GPSResults.

Under normal circumstances one of the nice things about the 100m min is that it takes you roughly 50m clear of the proximity circle (i.e. 50m from the start point to perimiter + 50m further beyond). This feels kind of "nice" for a traditional alpha with a typical run up to the gybe.

Totally agreed on the top alphas usually being close to 500m. That's why I feel it's fair enough for the ESP to make that compromise in its realtime alpha results. GP3S / GPSTC posts can (in principle) only ever be faster than the device under those circumstances.

Select to expand quote

K888 said..

Each watch has decided on its own compromises - GW-60 (Doppler + COG proximity checks), Garmin (max time 60 seconds would ignore some of my lightwind wingfoil gybes) and then there is COROS (no proximity check at all).

Although I only look at the last 60 seconds, my software regularly records gybes that are in the 10-15kt speed range whilst foiling. Obviously these gybes are not 500 metres long, but typically over 350 metres.

With the modern watches I could increase the alpha timer to 90 seconds, but is anyone really interested in accurate alphas that are slower than 16 kts anyway.

Select to expand quote

tbwonder said..

K888 said..

Each watch has decided on its own compromises - GW-60 (Doppler + COG proximity checks), Garmin (max time 60 seconds would ignore some of my lightwind wingfoil gybes) and then there is COROS (no proximity check at all).

Although I only look at the last 60 seconds, my software regularly records gybes that are in the 10-15kt speed range whilst foiling. Obviously these gybes are not 500 metres long, but typically over 350 metres.

With the modern watches I could increase the alpha timer to 90 seconds, but is anyone really interested in accurate alphas that are slower than 16 kts anyway.

Even 16 knots is tricky for people on a wing. It's not my primary focus but some people might be interested in their alphas and use them as a measure of their progress.

Technically speaking though the original alpha rules stated you had to be on a windsurfer, iirc.

Select to expand quote

sailquik said.. >>>> From my memory of it, I don't think Tom Chalko would have said that Doppler derived proximity position is "more accurate". I am pretty sure he knew the issue with that method and why it was rejected. My understanding is that use of Doppler derived position for the proximity circle was to >>>

Well I was talking to "Formosa" the locosys code writer, and he said some thing along the lines. "Tom Chalko sys this the most accurate way, and unless you have a qualified person prove other wise it's staying as it is. He then went on to say that even if we proved it, the resources of the GW60 were too limited to implement it.
Tom then contacted me and asked me to do some simulated alpha runs in my car to prove doppler position was more accurate than positional. And with the GPSs attached to my roof above the driver, it was hard to say one way or the other.
When I pointed out the problems with the GW60 in an actual gybe. He said a good alpha gybe needs to be very smooth so it shouldn't be a problem, and anyway you have the +/- values.
I gave up after that.

@decrepit. Thanks for sharing your recollections. It is interesting to read some history and I had wondered how Locosys had implemented alphas, way back when I first got my first GW-60. I also recall the speed genie config had an impact and you had to make sure it was set to a value no higher than your typical min speed during a gybe, otherwise no alphas were reported. It's great to hear the various decisions people have made when implementing alpha functionality.

Select to expand quote

decrepit said..
Well I was talking to "Formosa" the locosys code writer, and he said some thing along the lines. "Tom Chalko sys this the most accurate way, and unless you have a qualified person prove other wise it's staying as it is. He then went on to say that even if we proved it, the resources of the GW60 were too limited to implement it.

They used the same excuse for not showing 1 hour readings, if I recall correctly. I'd say the limited resource here was the ability of the programmer to write good code. tbwonder has shown that you can get very good results in watches with very limited resources (as have others before him who calculated decent alphas).

The most primitive implementation of distance calculations would re-calculated distances every time using very complex math, which some watches cannot do in real time. But K888 has shown quite nicely that there are much better ways.

Select to expand quote

K888 said..
Regarding differences between GPSResults, GpsarPro and GPS Speedreader. This data was from a recent foiling session of mine on a small lake with lots of short runs and tight-ish turns. It's actually the same session that made me look at acceleration artefacts caused by 10Hz data.

It was completely by chance that I used this as the main session whilst testing my alpha code and it picked up the following differences between the "big 3" tools. The 1 Hz GT-31 track produces 3 distinct lists of the top 5 alphas, selected from 6 unique runs.

I've colour coded the runs so they can be visually matched up. GPSResults and GpsarPro both ignore 20 knot foiling alphas which I suspect is to do with the close timings. They are basically back-to-back alphas but not quite overlapping. As an aside, my alg actually allows these two alphas to overlap by a few seconds. Trying to optimise multiple alpha results to avoid any overlaps would be a right can of worms!


This particular session also highlighted (to me) the significance of an inbuilt "mininmum distance" for alphas. I initially tested my code using a 100m minimum distance (completely independently of GPS Speedreader which has also been using 100m) as it seemed like a good distance to use. It was only when I started comparing the top 50 results with GPSResults (based on start/end times, results and distances) that I increased the minimum distance to 250m to make reviewing any differences less tiresome. I'd be happy to use 100m again, since it makes little difference performance wise but I kept 250m to avoid discrepencies with GP3S posts.

At the end of my testing, I'd concluded that my code produces lists of alphas which match the GPS Speedreader algorithm, picking up alphas that neither GPSResults or GpsarPro will allow / discover. Most of the differences between my code and GPSResults tend to happen further down the alpha list (sometimes still top 10 but often times down at #30 and below) but nevertheless, I think the results that GPS Speedreader and my code identify are more thorough. I'm aware that I ignore runs where speed drops below 2 knots but that was a conscious decision.

I also considered exploring the difference(s) when using Doppler + COG for proximity checks but decided it wasn't worth the effort since it would be highly inaccurate for COROS tracks where COG is an integer. That's also ignoring the fact that we know lat + long proximity checks are more appropriate for older devices from past studies, quite likely true on modern devices as well.

Each watch has decided on its own compromises - GW-60 (Doppler + COG proximity checks), Garmin (max time 60 seconds would ignore some of my lightwind wingfoil gybes) and then there is COROS (no proximity check at all).

The COROS is the one that I find most disappointing. To see a 27.8 knot "alpha" on my wrist after one of my fastest gybes ever lead to huge disappointment when I discovered it was actually >50m proximity and that the next best was 22 knots on that day!

Very interesting example. GPSAR does indeed give different numbers, and picks the top 2 in a different order. I must admit that I focuses on comparing to GPSResults (I think largely because the version of GPSAR I used did not compute short alphas at all).

Looking at the data closely gives a hint what is probably going on:

Alphas 2 (top) and 4 (bottom) picked by Speedreader are very close, but do not overlap. But the reason they do not overlap is that alpha 4, as picked by Speedreader, is only 267.6 meters long. Picking a longer region for alpha 4 gives a higher alpha for this jibe, but then, the two alphas would overlap. Overlapping runs are not allowed (allowed this should apply here could be discussed).

It seems that GPSResults and GPSAR find the two "full length" alphas here, see that they overlap, and throw out the slower alpha. Speedreader also throws out one of the full-length alphas, but still has the shorter alpha so it can use it.

One possible explanation for the differences is a simple change in the order of steps. Speedreader (where I know what happens) does the following:
- find the best alpha for each (end) point
- sort alphas by speed
- remove alphas that overlap with faster alphas

I don't know what exactly the other programs do, but it is possible that they do this:
- calculate alphas for each point
- as soon as a new alpha result is calculated, compare it to known alpha results, and discard it if it overlaps
- when all alphas are calculated, sort them by speed

This is a pretty subtle difference, but it explains why two programs do not show an alpha that GPS Speedreader shows.

Note that this does not really affect real-time calculations on watches if you're displaying only the top alpha result. It could theoretically affect the alpha shown for the last run if it overlaps with the previous run, and the previous run was faster, but that's easy to avoid for "last run" displays.

It's a pretty interesting example that is quite foil-specific - both with respect to the short runs and with respect to the speed kept in jibes (best 10 average 15.3 knots!). It illustrates that having a well-defined test set with defined "correct" results would make sense.

Select to expand quote

decrepit said..

sailquik said.. >>>> From my memory of it, I don't think Tom Chalko would have said that Doppler derived proximity position is "more accurate". I am pretty sure he knew the issue with that method and why it was rejected. My understanding is that use of Doppler derived position for the proximity circle was to >>>

Well I was talking to "Formosa" the locosys code writer, and he said some thing along the lines. "Tom Chalko sys this the most accurate way, and unless you have a qualified person prove other wise it's staying as it is. He then went on to say that even if we proved it, the resources of the GW60 were too limited to implement it.
Tom then contacted me and asked me to do some simulated alpha runs in my car to prove doppler position was more accurate than positional. And with the GPSs attached to my roof above the driver, it was hard to say one way or the other.
When I pointed out the problems with the GW60 in an actual gybe. He said a good alpha gybe needs to be very smooth so it shouldn't be a problem, and anyway you have the +/- values.
I gave up after that.

I stand corrected. I concur that the ultimate answer/excuse from Locosys was about computational resources.

I remember that at one stage, Manfred was also keen on the idea that the Doppler Heading could be more accurate for Proximity, and implemented it in a version of GPS-Results, but after I showed him quite a few examples where it went horribly wrong, he agreed it was not a good way to go and reverted to positional proximity data. All the examples I used were from windsurfing. Most of the errors occurred in the gybe (where they have the greatest effect) and are probably influenced by the rig flip movements.

Select to expand quote

boardsurfr said..

Looking at the data closely gives a hint what is probably going on...
One possible explanation for the differences is a simple change in the order of steps...
This is a pretty subtle difference, but it explains why two programs do not show an alpha that GPS Speedreader shows.

It's a pretty interesting example that is quite foil-specific - both with respect to the short runs and with respect to the speed kept in jibes (best 10 average 15.3 knots!). It illustrates that having a well-defined test set with defined "correct" results would make sense.

Thanks for looking and yes, I think what you describe is very likely to be the explanation.

I hadn't looked at my gybe results for that session but it is probably one of my better days on a foil. It feels like I'm finally getting the hang of gybing the foil and I think it kinda shows in those best 10 min speeds.

I have a few ideas for a possible framework for defined tests + results so I'll add it to my growing list of project ideas. I'll drop you a PM before I actually do any work to see what you think, rather than clutter up the forum.

Yes, send me a message. I have a collection test files that may be useful, but what also would be great would be specific "special cases". I have a few of these around, too, and always thought I should organize them ...

So I worked out how to log the millisecond time to a file so I can measure how long my code takes to run. I found that whilst doing a typical alpha my code was taking approximately 580ms to execute. When stationary the execution time is about half this.
I was a little concerned that this number is so high, as the watch has a lot of things to do apart from running my code. However who knows how the internal processes operate, perhaps the watch is interrupting to run other processes as my code runs.
I did a fair amount of testing on the simulator to prove that my new code was producing the same results. I also removed the final sqrt command to save a little bit extra.
Due to next to no wind for the last month, and several false starts with code bugs, it has takjen some considerable time to finally get a typical session logged.
The result today was an execution time of around 480ms.
So a considerable and worthwhile saving.