Logiqx / gp3s-coros

GPS3S wishlist for future COROS firmware releases
Creative Commons Zero v1.0 Universal
1 stars 0 forks source link

Problems with run detection #4

Open Logiqx opened 2 years ago

Logiqx commented 2 years ago

Run detection affects the total number of runs reported on the watch + app but it also affects how the 5 best 10s results are identified, thus affecting the 5 x 10s average that is reported by the watch + app.

The detection of runs ending is currently relient upon speed dropping below a specified threshold. However, when sailing back and forth, many good windsurfers will rarely drop below 12 knots when gybing / turning so the turns themselves should be treated as the end of one run and start of another.

The current "run entry speed" logic can often miss some 10s results when the board speed never drops below 12 knots. This affects the top 10s speeds listed on the watch and the 5 x 10s average. You should try to imagine typical recreational windsurfers sailing back and forth in the shape of the infinity sign, gybing (turning) at both ends. ∞

To solve the run detection issue, the watch should look for significant changes of direction / COG. A simple but effective approach to gybe detection is to look for a COG change >= 120 degrees over the last 10 seconds. This can be achieved by comparing the current COG to the COG 10 seconds earlier. This test should be performed once every second, throughout the session but only when speed >= "run entry speed" (typically 12 knots) and no sooner than 10 seconds into the current run.

When a 120 degree COG change is detected (during the past 10 seconds) the current run should be regarded as complete and the run count should be incremented. The 5 best 10s results and the 5 x 10s average are currently re-calculated by the watches every second, and there is no change required to that existing logic. If relevant, the watch should still beep and display any alerts like 2s best, 10s best or 5 x 10s best, as it currently does after each run where improvements have been made.

The next run should be deemed to commence when the current speed >= "run entry speed" (e.g. 12 knots). This might be immediately as the 120 degree turn is detected (e.g. if the speed never even dropped below 12 knots) or it might be some time shortly afterwards, in which case the usual "run entry speed" logic should detect speed >= "run entry speed" (e.g. 12 knots) and regard the next run as having started.

When a run is determined to have ended due to a 120 degree turn, the COG logic to identify a turn should not be performed during the first 10 seconds of the new run, otherwise it could keep firing every second. It is crucial that this 10 second period is based on when the new run begins (i.e. speed >= "run entry speed") and not when the previous run finished. If the windsurfer crashes (or stops) during a gybe, the COG check should not be performed until 10 seconds into the next run (i.e. 10 seconds after speed >= "run entry speed").

Once the run detection logic described above has been implemented, total run counts and the 5 x 10s averages should become trustworthy on all of the COROS watches. I will also implement this algorithm in Python so that the logic is clear.

Note: Run detection should not affect 100m, 250m, 500m, nautical mile, alpha 500, distance, 1/2 hour or 1 hour speeds where turns are allowed and do not indicate the start / end of a run. Those categories are a straight forward "fastest during the session" as far as the COROS watch is concerned.

Ingolf2310 commented 2 years ago

Gybe = making a turn to the opposite direction.

Logiqx commented 1 year ago

Additional note:

This issue is one of the most significant for many users as it is impossible for us to know the 5 x 10 seconds average during a session when runs are essentially ignored.

It is a realtively simple fix but will make a huge difference to all COROS users.

The same is true of the issue #1 (relating to alphas)