runnerup icon indicating copy to clipboard operation
runnerup copied to clipboard

Wrong time reporting

Open jerous86 opened this issue 6 years ago • 5 comments

Sometimes runnerup reports the wrong time. For example, today I started tracking my run at 13:44 (according to the Android clock; in the GPX file the start was at 2020-04-21T11:49:29Z, but apparently it only started recording after six minutes as it had refound the GPS signal, but this shouldn't matter). When I checked again 15 minutes later (at around 13:59, 2020-04-21T11:58:20Z) a time of 22 minutes was reported in runnerup, which can clearly not be true as I started running only 15 minutes earlier.

I cannot reproduce this reliably, but I sometimes encounter it when the GPS has been ready for a while (i.e. the blue play button is visible), but it is only after e.g. 20 minutes that I go out for my run and start tracking.

jerous86 avatar Apr 21 '20 13:04 jerous86

RU logs timestamps using GPS time, also the duration. So if the GPS was much off when starting, this could be happen. But it should not be this difference for the GPS time, when it locks to satellites, the time should be correct down to nano seconds. The GPX may show more info, but the likely is: Make sure GPS is Good before starting an activity.

gerhardol avatar Apr 21 '20 19:04 gerhardol

I have a similar issue. The history/summary shows the run lasted longer than the individual data points (and my experience)

I have exported the sqlite data and examined it. The "activity" table shows an errenous total time used (giving me a bad average rate). I do not know if the start time is right or wrong. The "lap" table shows correct values and summing/averaging time&distance I get the correct speed. Likewise the "location" table.

(The sqllite database selects and output available if needed)

M-square avatar Apr 22 '20 09:04 M-square

If this is due to starting with bad GPS, maybe start should be blocked (are you sure? dialog). GPX export of the activity should see the time jumping at one point. Logging of extended data (see Settings-Recording) will be helpful too

gerhardol avatar Apr 22 '20 15:04 gerhardol

The first part of the start of the gpx (with extended data enabled) is (I removed the fractional part of the GPS coordinates)

...
<metadata>
    <time>2020-04-21T11:49:29Z</time>
  </metadata>
  <trk>
    <trkseg>
      <trkpt lat="51" lon="4">
        <ele>29.8507752949842</ele>
        <time>2020-04-21T11:49:29Z</time>
      </trkpt>
...

which, as mentioned before, is 7 minutes after I started recording. When I checked after 15 minutes of running, it reported here 22 minutes.

However, a bit later I indeed find time a time jump:

      <trkpt lat="51." lon="4.">
        <ele>10.875631808775</ele>
        <time>2020-04-21T12:05:36Z</time>
      </trkpt>
      <trkpt lat="51." lon="4.">
        <ele>11.8749744545188</ele>
        <time>2020-04-21T12:10:49Z</time>
      </trkpt>

But despite the 5 minute jump, the reported time for the track segment seems correct ... I don't recall if during my run the reported running time was off here, though.

jerous86 avatar Apr 23 '20 08:04 jerous86

I have done a "Select time from location where activity_id=33" on a exported copy of the database, and compared all adjacent rows, there is no timejump greater than 3 seconds (there is a point where I run through a tunnel - but that is only a temporary GPS reception drop)

My current theory is that it picks the "wrong" time (local clock, GPS clock, program start time?!) but i need to verify that. Oh, and should perhaps note that I have v2.0.2.1 Andriod 10, Oxygen.

M-square avatar May 02 '20 13:05 M-square