Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[run v0.17] Distance is wrong #3116

Open
pavelmachek opened this issue Nov 29, 2023 · 4 comments
Open

[run v0.17] Distance is wrong #3116

pavelmachek opened this issue Nov 29, 2023 · 4 comments
Labels
area-apps type-bug Something isn't working

Comments

@pavelmachek
Copy link
Contributor

Affected hardware version

Bangle 2

Your firmware version

2v19

The bug

Distance in kilometers is pretty much wrong.

a) On startup, very frequently large distance is added when acquiring GPS fix. It may be distance to previous GPS fix or something like that.

b) When stationary, random position noise from GPS means that distance is growing quite rapidly. [Possible solution might be to test distance from last point; if it is less then 10m, ignore GPS measurement. if it is more, save current position as last point and add the distance].

c) When user returns to the clock, track recording seems to continue but distance is not accounted properly. Straight-line distance is taken from last point when Run was running, or something like that. [Possible solution might be for "Recorder" to do the distance calculation, and make "Run" ask "Recorder" for distance.]

Installed apps

No response

@bobrippling bobrippling added type-bug Something isn't working area-apps labels Nov 29, 2023
@bobrippling
Copy link
Collaborator

I like the sound of your proposed fixes, specifically:

  • We wait until we have a stable fix at the start
    • Perhaps we wait until two consecutive GPS fixes are less than 10m apart, or more than 30 seconds has passed with more than 3 fixes during this time?
  • Like you say - we pause the run/recording if the user hasn't moved over 10m in the past 30 seconds or so, it'd mirror what apps like Strava do for cycling ("auto-pause") and so on
  • Your last point sounds like a combination of the two previous - we'd need to detect resuming after a "pause" (2nd point) and then re-acquire regular fixes (1st point)

Does that all sound good to you? If so, we have a plan

@pavelmachek
Copy link
Contributor Author

a) Yes, that should do the trick. Waiting for altitude to stop changing may be easiest (we have barometer, so we can tell the altitude is not changing).
b) Yes, stopping recording at low speed would work, too.
c) I'm proposing something else. Do the distance computation in Recorder (not in Run), so that distance is still updated when Clocks are running.

@bobrippling
Copy link
Collaborator

Great, sounds like a plan.

About c) (in fact, this applies to all points, but specifically about where the change should be made), I don't believe Run records distance, nor does Recorder (funnily enough), it's done by the exstats module, setup here in Run and Recorder doesn't calculate distance at all, it just notes down each GPS point as it comes in.

So I believe the fix would be to change exstat's distance calculation, which would then be picked up by Run/Runplus automatically, since they display the stats.

For exporting runs, we'd need to apply similar logic to the Recorder - I think for this we'd want Recorder to continue to write raw coordinates, and we apply the logic in interface.html when we're exporting routes.

@bobrippling
Copy link
Collaborator

gipy's latest update has some logic around this too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-apps type-bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants