Complete
over 5 years ago

WERETECH-8574

Bug: Activity.Info.elapsedDistance is way off if playback a .fit file using simulator 3.1.6

Activity.Info.elapsedDistance is way off not only due to lat/lon = [0.0, 0.0]

https://forums.garmin.com/developer/connect-iq/i/bug-reports/initial-values-lat-lon-0-0-if-replaying-a-fit-in-simulator

but rather it seems there are more bugs in the sim.

info.elapsedDistance should be the sum of the distances between the recorded position points lat/lon. So I've calculated the sum of this distance increments and compared it to the value of info.elapsedDistance. I've only used a fast and easy formula to calculate the distances between 2 position points without any smoothing or interpolation. Thus my calculated elapsed distance may differ somewhat to info.elapsedDistance.

By replaying a .fit I get the following values
My sum of distance increments = 125.82m
Activity.info.elapsedDistance = 194.69m
This is a difference of >54% which is well way off.

In the .tcx file of the .fit for the same lat/lon there is stored the value
<DistanceMeters>123.29000091552734</DistanceMeters>

If I don't use the "Playback File" option but instead use the option "Simulate Data" I get this values
My sum of distance increments = 124.67m
Activity.info.elapsedDistance = 129.09m
This is a difference 3.5% that seems to be reasonable to me.

Since "Simulate Data" generates random values the distances are different to the "Playback File" values.

  • The sim has an option in the menu Settings > Units Display > Metric/Statute . I don't understand for what is this?

    In the discussion forum you have recommended:

    "And when testing you may want to start recording in the sim before you start playing back the fit to avoid missing the first part of the recording."

  • when you play back a fit, you always see the data in metric and it's up to your app to convert to statute if needed.

    You really don't want to start the timer before you play back a fit.  That would explain the [0,0]

  • Thanks Jim, your hint is very helpful for me. Now I know that I'm the only one with this issue.

    I'am pretty sure that the .fit is correct.

    In the discussion forum

    forums.garmin.com/.../replaying-fit-file

    I've already posted a graph from

    BaseCamp distance = 0 - 0.21km (current speed ~ 7 ... 9 km/h)

    Garmin Connect distance = 0 - 2km (pace ~ 8:30 ... 7:30 min/km -> Speed ~ 7 ... 8 km/h)

    Simulator distance = 0 - 0.2km (my calculated current speed = (d2-d1)/(t2-t1) ~ 10 ... 15 km/h)

    Since (t2-t1) = 1 for 1s recording, the speed is simply (d2-d1).

    I always start my activities after at least 30s continuous GPS fix (green circle) and as you can see in the above graphs there is no GPS gap.

    As I've shown above the .tcx distance is also OK.

    Now I've another suspicion that sounds reliable for me. The difference of info.elapsedDistance is about 54% and this is pretty near of the difference mi/km = 1609m/1000m=1.6 resp. 60%. My .fit is recorded in metric unit system and info.elapsedDistance is always in m as described in the API documentation. If I use statute unit system, the sim must convert from mi to m. I've used both in the sim but not seen any difference between metric and statute. For testing I've used miles = info.elapsedDistance / 1.6 and this looks much better. But I'm not sure that this is the reason.

    Also lat/lon [0,0] I can reproduce regardless of the .fit . If I first start the timer in the sim and subsequently start playback file info.elapsedDistance is a huge value as is shown in the table in the discussion forum.

  • Post your .fit that you're seeing this with.  Like I said, I'm not seeing it with any of mine.

  • Are you sure it's not the fit file(s) you're using?  I've not seen the [0,0] and my distances are correct with the fit files I've tested. (some past 5k's etc)

    Things to consider  like, did you have a green GPS before you started recording?  Were there GPS drops due to a tunnel or anything?