high deviation between elapsed time and duration, GPS issue?

[Saboe]

Since the update which comes out end of last year (dec. 2021) I've a an issue with the pause time which is high. The pause time is since this update something between 18% and 27% of the duration while this should be 0% and 1% (values from older logs).

During cycling it often happens that the odometer shows 0,0 km/h while my older bicycle computer shows something between 20 km/h and 40 km/h. The duration of the shown 0,0 km/h (unable to calculate the speed) can take few seconds or many second which finally leads to the calculated pause time of something between 18% and 27%. Today I made use of both cycling trackers that I've installed, thus Urban Biker and OpenTracks. OpenTracks shows for today the right time, 1:23:18, the cycling computer shows 1:23:09 while Urban Biker only shows 1:08:51. Urban Biker and OpenTracks are running on the same phone so GPS is working correctly. I've no clue why the odometer and also the time suddenly stops when I'm on the track, outside cities, where GPS receiving should not be an issue. BTW, the shown speed is calculated from the GPS signal so that is my conclusion that this could be a GPS issue.

Additional: Device: Fairphone FP3 with Android 10, build 8901.3.A.0134.20211116 Urban Biker v7.03 no external sensors used

[Sublimis]

Hi Saboe, if possible please try the latest beta version from here (dated 2022-02-01) to see whether this has been fixed with our latest improvements.

Nothing was changed in our code regarding GPS tracking since at least September 2021 (until this beta), so we think your problems must have started after you updated the system to build 8901.3.A.0134.20211116 (released late October 2021), coinciding with the app update.

As a most probable cause we can think of by looking at the code, it appears that this system build is providing GPS locations either 1) without 'speed accuracy' values, or 2) with speed accuracy values too high (meaning more inaccurate). This beta version addresses the first case, so if it doesn't solve your issue then we'll look into the second case, too.

Thanks for the feedback!

[Saboe]

I've now installed version 7.04 (beta) but the results are the same. I've made two short measurement (marked with [1] and [2]) to work and back to home on different routes. On both rides I've also started in parallel OpenTracks (OT) to see the difference because I can't use my bicycle computer on that bike. Normally I don´t start OT with Urban Biker (UB) because I'm not sure if both apps run independently from each other when both make use of GPS and other things.

The results as follows (distance, moving time, total time, max. speed --> result):

[1] OT: 4.92 km, 00:13:11, 00:13:49, max 23.6 km/h --> correct [1] UB: 4.877 km, 00:09:10, 00:13:46, max. 61.4 kmh (33.3% pause) --> partly wrong

[2] OT: 5.81 km, 00:14:55, 00:15:36, max. 23,3 km/h --> correct [2] UB: 5.768 km, 00:10:11, 00:15:32, max. 61,2 km/h (34.3% pause) --> partly wrong

I took the phone in both cases in my pocket that leads not to hear every sound UB makes during the ride. On the first ride [1] I've heard 3x the 'continue' signal (after pause) while I was cycling. I've also heard the 'pause' signal only one time. On the way back to home I've heard the 'continue' sound one time.

The same happened when the phone is placed on the handle bar on my other bicycle thus I hear more often the 'continue' signal but rarely the 'pause' sound. This only as information perhaps it could be helpful.

I believe that you've done nothing with the GPS part in the source code but you've changed other things which in some cases leads to runtime issues. So I assume that this bug (yes, for me this is a bug) has to do with a runtime issue because it occurs irregular. In general, I've nothing changed on my phone within the last month. No new apps or OS updates nor any changes in the settings so this bug has nothing to do with the OS. It´s until today the same since the last upgrade which I've done in October of November last year.

[Saboe]

Probably not fixed. With version 7.20 (28/03/2022) today I took a short measurement by a non-stop ride over 36 minutes.

(distance, moving time, stopped time, avg. speed --> result) Open Tracks: 15.17 km, 00:34:13, 00:00:27, avg. 26.6 km/h --> correct, 27 sec. neglectable due to start/stop phase Urban Biker: 15.282 km, 00:35:59, 00:06:00 (16.7% pause), avg. 30.6 kmh --> partly wrong, the stopped time about 6 minutes is too high for a non-stop ride about 36 minutes.

During my ride I saw that the odometer shows 0,0 km/h several times. If this happens after 4 seconds the confidence/stall indicator was shown and increasing. After around 8 seconds in total the current speed was back. This happens in irregular intervals. Perhaps this is more clearly by the following graph. I don't understand why the graph is not showing the real measured speed. Why do the curve not go down to zero when 0,0 km/h is measured?

[Sublimis]

Hi, please observe the image below for a difference between "Duration" and "Elapsed time". It may well be that translations of these terms to your language are not clear enough.

[Sublimis]

Probably not fixed. With version 7.20 (28/03/2022) today I took a short measurement by a non-stop ride over 36 minutes.

(distance, moving time, stopped time, avg. speed --> result) Open Tracks: 15.17 km, 00:34:13, 00:00:27, avg. 26.6 km/h --> correct, 27 sec. neglectable due to start/stop phase Urban Biker: 15.282 km, 00:35:59, 00:06:00 (16.7% pause), avg. 30.6 kmh --> partly wrong, the stopped time about 6 minutes is too high for a non-stop ride about 36 minutes.

The data all looks okay, but your calculations are not correct. Average speed is about 25.5 km/h (15.282 km for a 36 min ride). 6 min pause on a total of (36+6)=42 min activity is about 14.2% (this is how the Stopped time percent is calculated in the app).

During my ride I saw that the odometer shows 0,0 km/h several times. If this happens after 4 seconds the confidence/stall indicator was shown and increasing. After around 8 seconds in total the current speed was back. This happens in irregular intervals. Perhaps this is more clearly by the following graph. I don't understand why the graph is not showing the real measured speed. Why do the curve not go down to zero when 0,0 km/h is measured?

Key point is that when the confidence/stall indicator is shown, the speed cannot be trusted and its value is merely a guesswork. Charts/graphs only show data saved ("real" data); the app will never save "guesswork" data.

Description of loosing speed in irregular intervals is indicative of GPS signal and accuracy issues. Please make sure that you are using Google Play services in Settings > Tracking/GPS > Advanced > GPS provider. On the same screen, scroll below and try changing the Recalculate speed option too, if the above does not help.

If duration and speed measurements accuracy is of paramount importance to you, please consider using a wireless Speed sensor, for example Garmin Speed 2 is doing a very good job. More info: https://urban-bike-computer.com/faq/#sensors.

Hope this helps. Thanks for the feedback!

[Saboe]

Hi, please observe the image below for a difference between "Duration" and "Elapsed time". It may well be that translations of these terms to your language are not clear enough.

I know the difference between both. To be clear, I've done the following steps for a comparison between Open tracks and Urban Biker.

1. I took my bike.
2. I started up Open Tracks and set it active = start measurement.
3. Next I started Urban Biker and set it also active.
4. Now I begun to cycle non-stop over the next 36 minutes. The lowest speed during this ride war around 15 km/h for two times for few seconds.
5. When I was back home I stopped Urban Biker (stop/pause -> final stop) then Open Tracks.

There was also no important delay which explains the 6 minutes pause/inactivity. So my assumption is that the 32 seconds pause = the difference between moving time and total time measured by Open Tracks has to do with the start/stop phase and looks explainable to me. But this is not for the 6 minutes of pause/inactivity I got from Urban Biker.

The data all looks okay, but your calculations are not correct.

I've nothing calculated. The values are from both apps, I've only written off these values. But I think we have a misunderstanding. Urban Biker logged the following:

Open Tracks logged this for the same ride:

Description of loosing speed in irregular intervals is indicative of GPS signal and accuracy issues. Please make sure that you are using Google Play services in Settings > Tracking/GPS > Advanced > GPS provider. On the same screen, scroll below and try changing the Recalculate speed option too, if the above does not help.

There's nothing changed. The defaults are still the same as you described thus Recalculate speed is switched on.

If duration and speed measurements accuracy is of paramount importance to you, please consider using a wireless Speed sensor,

It should only working as expected so Open Tracks it does, nothing more. But such large inactivity percentage with several randomly shown 0,0 km/h values during a ride are IMO not explainable. For comparison, I have several logs left from end of last year where this percentage seems to be correct. With the update of Urban Biker I've done end of December last year the story of large inactivity times begun. In the meantime I've nothing changed, neither something in the settings nor anything on my phone.

This is the last correct measurement (29/12/2021) I have from Urban Biker but I don't know with which version this was done.

Two days later after the update the story beguns. NB: During this ride I've heard more than 15 times the "bling"-sound = going on after a break. After that I've stopped counting but the "plok"-sound = break, I've never heard or only few times, I didn´t know anymore.

That is one of the worst log I have:

[Sublimis]

Thanks for the detailed feedback. So it appears that duration is incorrect (too short), not the elapsed time (which we wrongly assumed based on some earlier feedback).

Can you please test with the latest beta version (just released)? You can grab it from here: https://play.google.com/apps/testing/com.sublimis.urbanbiker. Unfortunately we cannot reproduce the issue in order to be certain that it was fixed.

Also, please try with the "Recalculate speed" option disabled (which is the default).

If nothing helps and beta version hasn't fixed this, would you mind sending us the track file of the incorrectly measured activity (e.g. the one from 2022-02-27 above)?

[Sublimis]

Hi, could it be that the "Adaptive GPS update interval" feature is the culprit? If possible, please try setting the GPS update interval to "1 second" or "Fastest" instead of "Adaptive (default)". We introduced this feature in v7.01 dated 2021-12-23 which agrees with the time frame you gave above.

BTW version of the app that recorded the track is written inside the track summary file, but is not exposed in the History, it can only be read manually. Also, if you will be sending us some track files, please do it over the email for privacy reasons, of course.

Thanks again!

[Saboe]

Hi, could it be that the "Adaptive GPS update interval" feature is the culprit?

I don´t think so. I've set the GPS interval now from adaptive to fastest and there's no change. I've also changed the "Recalculate speed" option to disabled with also no change except that I more often see the 0,0 km/h value when I'm cycling.

Another "feature" I've detected, that I've heard four different sounds when I was cycling (annoying!). The sometimes (not always) Break/Go-on sound and two unknown sounds in between which sounds like in a game by example, something like "you're shot!" (sounds that something bad happens, generally a decreasing frequency) or "you got a med pack" (sounds like something nice happens, generally a increasing frequency).

[Sublimis]

Hi, sorry for that, just ignore the response. It's just Google complaining about ZIP attachments, and there's no way to circumvent this behaviour of theirs...

[Sublimis]

Here are the results.

As it turns out, there's nothing really wrong with the app; It's just wrongly set up. Step Detector sensor is the culprit.

More precisely, you've added the Step Detector sensor to the profile (this is most probably the internal sensor, embedded in the phone), and left it with its default settings. By default, Step Detector sensor is used for measuring duration (always possible), and speed and distance (only if step length is given).

Step Detector measurements have precedence over GPS measurements. This is the root cause of the problems you describe, because Step Detector sensor gets activated many times while you ride. Those sensors are not very reliable, and can get activated from vibrations. Every time Step Detector gets (wrongly) activated, it takes over duration measurement. Duration is then wrongly measured during this time (because you're obviously not running).

Solution: Either remove the Step Detector sensor from this profile, or open its properties and uncheck the "Use for speed" and "Use for distance and duration" options there. If you DO want to measure step count in this profile (cyclists sometimes do walk...), it's maybe a good idea to enable the "Physical activity recognition" option, to make the sensor more reliable in detecting walking patterns.

Hope this helps. Thanks for the feedback!