[run] displayed distance too long compared to rec's track

[bernhardreiter]

Affected hardware version

Bangle 2

Your firmware version

2v13

The bug

The distance of the displayed during operating "run" is significantly longer than the distance which is shown when displaying the track in rec or with an external application.

Expected is that the displayed distance is the same. (Except for minimal rounding and floating point representation differences.)

How to reproduce

• Activate "run",
• use it to track a reasonable distance, e.g. between 10-20 kilometers.
• Stop the recording, look at the displayed total distance (e.g. 20.3km) and
• then stop the app run (by pressing the button to go to the Banglejs mainmenu)
• Start rec and display the length of the track (which then is less, e.g. 19.6km)
• (alternative to last point): Download track using the app webpage via rec and use a different application to open and display track length, e.g. https://f-droid.org/ta/packages/mobi.maptrek/ (select the imported track and than its entry again) which then shows the same length as the rec track (e.g. 19.6km).

Additional info

A similar defect was there with the old banglerun implementation: #761.

First technical ideas:

• It is took much to be a simple rounding error.
• It does _not: seem to depend on data smoothing
• Maybe different ways to calculate the distances are used, many geographical applications use the great-circle distance or use height information, others may just do x-y cartesian coordinates.

[gfwilliams]

I think this has been discussed a lot in the forum previously, but what happens if you set your recorder recording interval to 1 second and then record a track and compare distances.

By default the recorder does record an average position over 10 seconds (so 10 GPS intervals) so you'd expect there to be slightly less movement, and what you're seeing (19.6 vs 20.3) is the kind of difference I'd expect. If you disable that I bet you'll find you get the same value reported for each.

So in a way what the run app reports is the more accurate distance based on GPS data.

[bernhardreiter]

I think this has been discussed a lot in the forum previously

(Sorry I must have missed it then.)

if you set your recorder recording interval to 1 second and then record a track and compare distances. [..] I bet you'll find you get the same value reported for each.

I'll try that.

Even then it is a usability problem, as it is not directly visible or explainable from the application. Especially the difference when downloading the track and comparing it with the display.

So why not set the recorder to 1 second also, when used from run?

in a way what the run app reports is the more accurate distance based on GPS data.

I am not sure yet, as my positions "jumps" around a lot, which may introduce more distance (which was not run) again. Guess it mus be compared to real measurements on a map or with a more precise GPS device.

Thanks for responding!

[gfwilliams]

So why not set the recorder to 1 second also, when used from run?

Because then you end up with massive GPS logs. They take up a bunch of space, take a long time to download, and take longer to view stats on or plot on the watch.

You can do it, but it makes no sense as a 'default'

I am not sure yet, as my positions "jumps" around a lot

Yes, this is the problem. My point was that the distance you see is the 'unfiltered' one coming straight from the GPS.

The original 'banglerun' app had a Kalman filter, but it broke quite early on and had to be removed. If I could get a nice clean implementation that worked, I'd love to get something added inside the Bangle.js firmware (or at the very least, the exstats lib) and then we could get some better filtered distances.

However even after that, the distances from the Run App will still differ from the recorded GPS log so I'm not sure there's actually any way to fix this 'bug'.

[bernhardreiter]

Okay, understood that a default of measuring the position each second is producing too big GPS logs.

As least my banglejs2's GPS is less precise than the one of the Banglejs1 and making jumps in the data a problem. So now I understand what the Kalman filter was used for. (It can also we used to predict future points which is less useful in this case, you want it to remove the jitter by many less precise measurements.)

My suggestion to deal with the difference is: a) first use the filter to produce "better" measurements b) safe that new points c) use the same calculation of the distance over the linestring for the run and the recorder display.

Then the calculation of the external map viewer, the internal one of recorder and the run display will be the same. I guess this is what users would find most intuitive.

[gfwilliams]

b) safe that new points

I really don't agree with this. Once you save only your filtered data, there is no way to get it back. If I'm logging GPS data I'd expect to be logging the GPS data, not some filtered version of it. I'd be pretty sure good GPS track readers already have ways to apply good filters to the data anyway.

But my point is:

• if you want to update your distance view every second, and log GPS data every 10 seconds, the two values you get will be different.
• If we make the distance values you see dependent on the GPS logging interval, I'd be pretty certain someone will quite rightly file a bug saying: "When I change the GPS logging interval, the track length reported by Run changes"

[bernhardreiter]

Once you save only your filtered data, there is no way to get it back.

Thought about the challenges for a bit, especially from the side of user experience.

My guess is that user do expect that the distance they see in the running app, the GPS part and external map aware apps is the same and the best accuracy they can get from the combination device/software suitable for the purpose (running). So this should be the default as it will have least irritations. (Personally I recommend using more space and battery for this, if necessary. I'd rater have space for 3 "good" tracks than for 10 but with the irritations.)

Looking at the raw data, apply your own filters or optimisations is something I'd expect a smaller group is wanting. So it should be possible, but not default. Maybe a difference between "raw" and normal data can be made. Which is a known concept in other domains (like photography).

Some ideas to improve the situation:

• Implementing "run" in several modes, one for longer and one for shorter runs?
• Or steering the "recorder" interval from the calling application.
• Or having a "raw" mode that saves both, raw and "filtered best" data.

[gfwilliams]

I'd be really interested to hear everyone else's point of view here?

I'm very conscious it's just us two, and that might well not be very representative.

Just to add, if you care about this, it's an easy fix - just set your record period to 1s in record settings, and accept the memory usage that comes with it in order to have the most accurate data

Maybe the best solution here that inconveniences the least people is just to document that.

[Darin755]

I honestly think that having a simple filter would be a good idea.

[gfwilliams]

You think a filter that applies even to the recorded GPS data?

I can understand filtering the distance value, but then if you want the two values shown to be exactly the same, we'll have to modify the GPS coordinates we write

[Darin755]

I honestly think that would be acceptable as long as the filter was very unaggressive.