As OP already stated the values from playback a .fit are way off. I've still the same problem with the sim 3.1.6. Though the .fit is recorded every second but info.elapsedDistance is way off. I'd like to playback a .fit for validating and calibrating my DF and analyzing my real activities. Therefore I've further investigated this issue.
I'm starting the playback of the .fit as follows:
1) Eclipse: starting the sim
2) sim: Simulation > FIT Data > Playback File > selecting the .fit > open
3) sim: (with different time delays) klick on start button in the Fenix 5 picture
By klicking the start button on F5 the timer starts and begins to read the .fit. I don't know exactly what is stored in the .fit but it seems to me that the sim uses its own timer time for info.elapsedTime, not the time stored in the .fit. Then the sim looks in the .fit for the proper time period and calculates/interpolates the info.elapsedDistance.
In my DF function compute(info) I directly print out info.elapsedTime and info.elapsedDistance.
I've done 3 playbacks with the same .fit and different time delays (t = 1s, 5s, 10s) between open the .fit and starting the timer i.e. klicking on button start.
All 3 playbacks differ depending on the time delay between opening the .fit and starting the timer. For info.elapsedTime = 60000ms an info.elapsedDistance = 190m to 208m is output, which corresponds to an average speed of about 11.4km/h to 12.5km/h.
Displaying the same .fit with GC or BaseCamp Graph shows an average speed for the first 60s of roughly 8km/h which is different by nearly 50% from the above 11.4km/h to 12.5km/h from the sim.
Either, I've made something wrong or there is a bug in the sim.
Any hints for solving this problem would be appreciated.
From the feedback it seems that no one else, but only OP and I have this issue that the values from replaying a .fit with the simulator are way off. I wonder how can DF and apps are validated without using data from a real activity.
Here are some graphs that shows the diffences in speed
1) Simulator
The current speed is calculated as speed = (d2-d1)/(t2-t1) using the following code
function compute(info) { if (info.elapsedDistance != null) { var elapsTimeTest = info.elapsedTime; // [ms] var elapsDistTest = info.elapsedDistance; // [m] var speedTest = (elapsDistTest - elapsDistTestOld) / (elapsTimeTest - elapsTimeTestOld) * 3600; elapsTimeTestOld = elapsTimeTest; elapsDistTestOld = elapsDistTest; System.println(elapsTimeTest + " " + elapsDistTest + " " + speedTest); } ...
2) BaseCamp
BaseCamp Graph directly offers the option for plotting speed from a .fit.
3) Garmin Connect
GC displays only the pace, but with speed = 1/pace it can easy converted.
The pace for the first 0.2km is shown of about 8min/km which relates to a speed of 7.5km/h
BaseCamp and GC shows roughly the correct speed in the range of 7-9km/h, but the info.elapsedDistance from the sim is way off and delivers a speed in the rage of 10-15km/h.
So, the question remains "what is wrong?"
When playing back a fit, you'll probably have the best luck if it was recorded with 1 sec recording and not smart (smart is the default on most devices.).
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.
Thanks Jim. The .fit is already recorded every second, because I'm aware of the former bug in the sim regarding the smart recording.
If I first starting the recording in the sim and immediately after that starting the FIT playback I get the following values:
t[ms] dist[m] speed[km/h] 1218 0.000000 0.000000 // starting recording in sim 2281 0.000000 0.000000 3250 0.000000 0.000000 4281 0.000000 0.000000 5281 0.000000 0.000000 6281 0.000000 0.000000 // starting .fit playback 7281 5834499.500000 21004198.000000 // huge distance ??? 8281 5834500.000000 1.800000 9281 5834501.000000 3.600000 10281 5834502.000000 3.600000 11281 5834503.500000 5.400000 12281 5834505.000000 5.400000 13281 5834506.500000 5.400000 14281 5834508.500000 7.200000 15281 5834510.500000 7.200000 16281 5834513.500000 10.800000 17281 5834516.500000 10.800000 ... 57281 5834655.500000 16.199999 58281 5834659.000000 12.600000 59281 5834662.500000 12.600000 60281 5834666.500000 14.400001 61281 5834670.000000 12.600000 62281 5834673.000000 10.800000 63281 5834676.500000 12.600000 64281 5834679.500000 10.800000 65281 5834683.500000 14.400001 66281 5834687.500000 14.400001 67281 5834691.000000 12.600000
The info.elapsedDistance provides suddenly a huge distance and I've no clue why.
If I starting in reverse order i.e. first starting the FIT playback and immediately after that starting the recording in the sim I get the following values:
t[ms] dist[m] speed[km/h] 812 0.286220 1.268955 // starting .fit playback and immediately recording in the sim 1812 1.187548 3.244782 2812 2.086517 3.236288 3812 3.751678 5.994579 4812 5.299979 5.573884 5812 6.814125 5.450923 6812 8.894515 7.489406 7812 11.115501 7.995551 8812 14.025583 10.476295 9812 16.960127 10.564357 10812 20.208660 11.694719 ... 50812 158.823059 13.268902 51812 162.429001 12.981390 52812 166.528244 14.757276 53812 169.789856 11.741803 54812 172.738480 10.615045 55812 176.005661 11.761853 56812 179.038315 10.917554 57812 182.988708 14.221417 58812 187.025085 14.530958 59812 190.664734 13.102735 60812 194.976593 15.522693
This seems more realistic as the above values but unfortunately still way off.
I'm going to take a wild guess on line 8 in your first record. There was a GPS drop at the time and the sim was confused. Try the same .fit but also display lat/lon (accurancy will always be what you set in the sim and not from the data itself)
In the meantime I've further investigated this issue and have found that by first starting the timer in the sim and subsequently the replay of the .fit the first value of info.elapsedDistance is very large, as can be seen in above table line 8. The reason for this issue is due to the initial values in the sim lat=0.0 and lon=0.0 . For my understanding if replaying a .fit the starting position lat/lon in the .fit i.e. the first position should be used instead of 0/0.
This seems now also observed in the thread forums.garmin.com/.../sdk-3-1-7-is-now-out
The original issue described at the start of this thread and shown in the graphs above is still unsolved.
info.elapsedDistance is way off not only due to lat/lon = [0.0, 0.0] 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.
The same .fit is used as in the above graphs and tables and I get the following values
Sum of distance increments = 125.82m
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
Sum of distance increments = 124.67m
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.
Any ideas about the difference with playback .fit?
Little come back to this problem with the FIT simulator.
I am working on a datafield that needs to calculate the pace. So I recorded a FIT file using my Forerunner 230 and was planing to use that file as a reference for developing my datafield.
But the simulation seems to return incorrect time data (using info.elapsedTime). My FIT file was recorded every seconds.
As an example, the FIT file contains the following data
time --> distance
0s --> 0m
10s --> 11m
20s --> 25m
30s --> 39m
40s --> 51m
50s --> 64m
60s --> 77m
etc.
while in the simulator, after the same elapsedTime (every 10s) I got the following values :
time --> distance
0s --> 0m
10s --> 16m
20s --> 35m
30s --> 53m
40s --> 68m
50s --> 85m
60s --> 102m
etc.
Seems that time is not one of the FIT file, but something running roughly 25 to 30% quicker than reality.
No needs to say that Pace calculation is totally inaccurate.
Any idea ?
For information, I am using SDK 3.1.8 running under Linux Ubuntu.
Thanks.
Sylvain