You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it comes from the erg, it seems as though data might get "cut off" if the piece ends before that piece of data has completely finished collecting.
What i mean is examples like the following:
rowing a piece thats roughly 200 strokes. Stroke 199 is the last complete stroke that data is received for. After stroke 199, there are 5 meters left in the piece and the piece ends just as the rower gets up to the catch. There is never any data received from stroke 200
during a fixed intervals piece the rower stops in the middle of the rest after the last interval and ends the piece by pressing menu back once or twice. Since the last interval wasnt technically fully complete (the rower didnt wait until the end of the rest) the erg likely (need to confirm) wouldnt send an interval data packet for the last interval.
In both cases this seems like it might be up to the user to reconstruct the missing data by:
finding the the total piece distance/time (as calculated by adding every stroke or interval together)
comparing this against the data from the workout summary packet with the actual totals
Taking the difference between these values and reconstrucing a datapoint representing the partial interval or partial stroke that makes up the difference.
In keeping with the Silent Protector development principle, this seems ljke something the library should be at least somewhat responsible for making easier for the implementor/end user.
The text was updated successfully, but these errors were encountered:
As it comes from the erg, it seems as though data might get "cut off" if the piece ends before that piece of data has completely finished collecting.
What i mean is examples like the following:
In both cases this seems like it might be up to the user to reconstruct the missing data by:
In keeping with the Silent Protector development principle, this seems ljke something the library should be at least somewhat responsible for making easier for the implementor/end user.
The text was updated successfully, but these errors were encountered: