Average speed on Strava | Moving time always equal to total time

[potifa]

This is a thing which I keep noticing for a long time now, but since I'm currently in the process of switching entirely to Strava, I thought it's worth bringing it up: Net average speeds in Strava do not match net average speeds in Oruxmaps. Instead, Strava's moving time is the same as Oruxmaps' total time, not Oruxmaps' moving time.



If I have a look at Strava's analysis graph, I notice that indeed my breaks (e.g. due to traffic lights) are just interpolated values between the last recorded speed before the break and the first recorded speed after the break. The interpolation, I suspect, is done by Strava, but Strava apparently does not receive the moving time from Oruxmaps. Velohero, which I'm also using, does recognize breaks correctly and, hence, also shows a correct net average speed.



The problem is independent of (1) uploading directly to Strava, (2) sending a .gpx-file to my computer and uploading this to Strava, and (3) sending a .tcx-file to my computer and uploading this to Strava.

[potifa]

I'd quickly like to expand on the issue, as I've spent some time to analyze it this morning.



I have gone back in my activity history. In the way I describe it, the problem seems not to occur with all activities. During activities that were recorded last Summer, Strava still recognizes breaks - it also recognizes them when I re-upload these activities today. Then I thought maybe this happens when breaks are too short, i.e. only traffic light stops. Indeed, that seemed to be the case for recent activities, so I had a closer look yet again. In fact, moving time on Strava will always be longer than moving time on OruxMaps. However, once the difference between elapsed time and moving time in OruxMaps falls below about three minutes, Strava (and also Garmin Connect, by the way) will usually report moving time to be equal to elapsed time. Looking closer at it, breaks need to have a minimum length to be counted, and this minimum length apparently is different from OruxMaps.



So I had a look at the .tcx-file of one activity to understand better which data Strava gets submitted. It seems that OruxMaps usually stores data at intervals of 3 seconds, but as soon as one stops, it stores at intervals of 1 minute, and resumes 3-second-intervals as one starts moving again. The problem then is that Strava interpolates from the last record before the stop to the first record during the stop, and interpolates from the last record during the stop to the first record after the stop. Hence, if an individual break is shorter than two minutes, and therefore has only one stopped record, Strava never gets the break: there are two interpolations, but no 0. This I'm sure about. The next point is speculation: Instead, OruxMaps (and likely VeloHero) seem to not interpolate. Instead, they define a stop as an entry where recorded movement relative to the previous point in meters (translated to a longitude/latitude-based difference) is less than a specified threshold. As a consequence, a single stopped record is enough.



One solution then would be to continue to fill the .gpx/.tcx-files in 3-second-intervals. I recognize that this would increase file sizes and potentially have an adverse effect on battery life. For that reason, allow me to refer to the last point of this conversation on a similar problem with another software:



http://www.rubitrack.com/forum/viewtopic.php?t=2166">http://www.rubitrack.com/forum/viewtopic.php?t=2166



Based on this, OruxMaps would need to tweak the TotalTimeSeconds tag in .tcx-files and upload .tcx-files rather than .gpx-files to Strava. Unfortunately, briefly playing around with either solution would fix the problem only on Garmin Connect, but not on Strava. Nonetheless, the above-mentioned issue is the cause of the problem.



Below a short section of a .tcx-file to illustrate this. I highlighted the last record before the break, the record within the break, and the first record after the break with blue font color and the times in general with red font color.



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4477910</LatitudeDegrees><LongitudeDegrees>9.1545557</LongitudeDegrees></Position><AltitudeMeters>118.04</AltitudeMeters><HeartRateBpm><Value>157</Value></HeartRateBpm><Cadence>7</Cadence></Trackpoint>



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4478729</LatitudeDegrees><LongitudeDegrees>9.1547923</LongitudeDegrees></Position><AltitudeMeters>121.36</AltitudeMeters>

<HeartRateBpm><Value>155</Value></HeartRateBpm><Cadence>61</Cadence></Trackpoint>



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4480514</LatitudeDegrees><LongitudeDegrees>9.1549453</LongitudeDegrees></Position><AltitudeMeters>118.47</AltitudeMeters><HeartRateBpm><Value>

154</Value></HeartRateBpm><Cadence>65</Cadence></Trackpoint>



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4482535</LatitudeDegrees>

<LongitudeDegrees>9.1549174</LongitudeDegrees></Position><AltitudeMeters>119.85</AltitudeMeters>

<HeartRateBpm><Value>151</Value></HeartRateBpm></Trackpoint>



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4484414</LatitudeDegrees>

<LongitudeDegrees>9.1548819</LongitudeDegrees></Position><AltitudeMeters>119.43</AltitudeMeters>

<HeartRateBpm><Value>109</Value></HeartRateBpm></Trackpoint>



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4486459</LatitudeDegrees>

<LongitudeDegrees>9.1548151</LongitudeDegrees></Position><AltitudeMeters>119.85</AltitudeMeters><HeartRateBpm><Value>

119</Value></HeartRateBpm><Cadence>44</Cadence></Trackpoint>



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4486304</LatitudeDegrees>

<LongitudeDegrees>9.1544903</LongitudeDegrees></Position><AltitudeMeters>119.17</AltitudeMeters>

<HeartRateBpm><Value>126</Value></HeartRateBpm><Cadence>71</Cadence></Trackpoint>



<Trackpoint><Time>2017-03-10T16]<Position><LatitudeDegrees>45.4485881</LatitudeDegrees>

<LongitudeDegrees>9.1541933</LongitudeDegrees></Position><AltitudeMeters>119.14</AltitudeMeters><HeartRateBpm><Value>

133</Value></HeartRateBpm><Cadence>74</Cadence></Trackpoint>

[potifa]

Kept reading on this and found: http://labs.strava.com/blog/improving-auto-pause-for-everyone/">http://labs.strava.com/blog/improving-a ... -everyone/">http://labs.strava.com/blog/improving-auto-pause-for-everyone/



"We started by looking at the process we have on our server for calculating moving time after upload and figuring out how to make that happen in real-time. The moving time calculation on the server looks for portions of the activity where the athlete was moving below a certain speed threshold for more than 15 seconds and removes that time as "resting time", leaving the remainder as moving time."



Now, let me see if I understand this correctly: This would imply that in my case (the data above), I seem to have approached the traffic light stop too fast, so that the (interpolated) speed value was still above Strava's/Garmin's threshold before I started moving again, while it was below OruxMaps'/VeloHero's threshold. (And that seems a recurring pattern.) In that case, one way to fix this might be to add, say, five additional records in the usual 3-second intervals once someone stops. This should lead Stata to trigger the below-threshold-average speed earlier without massively increasing file sizes.



But then: I'm just reading on this and trust that you (and others) have a more profound understanding. Essentially, I just try to provide as much information as possible.

[orux]

Kept reading on this and found: http://labs.strava.com/blog/improving-auto-pause-for-everyone/">http://labs.strava.com/blog/improving-a ... -everyone/">http://labs.strava.com/blog/improving-auto-pause-for-everyone/



"We started by looking at the process we have on our server for calculating moving time after upload and figuring out how to make that happen in real-time. The moving time calculation on the server looks for portions of the activity where the athlete was moving below a certain speed threshold for more than 15 seconds and removes that time as "resting time", leaving the remainder as moving time."



Now, let me see if I understand this correctly: This would imply that in my case (the data above), I seem to have approached the traffic light stop too fast, so that the (interpolated) speed value was still above Strava's/Garmin's threshold before I started moving again, while it was below OruxMaps'/VeloHero's threshold. (And that seems a recurring pattern.) In that case, one way to fix this might be to add, say, five additional records in the usual 3-second intervals once someone stops. This should lead Stata to trigger the below-threshold-average speed earlier without massively increasing file sizes.



But then: I'm just reading on this and trust that you (and others) have a more profound understanding. Essentially, I just try to provide as much information as possible.

Hello;



If you want strava and others be able to see those stops, you have to change your settings-->sensors-->gps-->minimum distance and minimum time to zero.



If minimum distance is > than zero, some points are not recorded. OruxMaps knows that you are stopped, but the apps that need to read the created gpx probably not,





orux

[potifa]

Thanks Orux! Very helpful.