Messages

Thanks Orux! Very helpful.

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.

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>

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.

I do. I'm using Velohero and Strava in parallel. Elevation in Velohero, Strava, and Oruxmaps deviates. Up until recently, Strava had higher elevations in the mountains, but lower (and more accurate) elevations in Strava. Since the beginning of this year, I always need to correct elevation in Strava because newly uploaded rides give ridiculous elevation, even though the values within Oruxmaps are pretty accurate. Velohero is much closer (and virtually identical to post-correction Strava elevation), but still above Oruxmaps' value as shown in the track statistics.



For instance, on a flat ride around Milan today Oruxmaps says 21m elevation, and Velohero says 111. Strava says 128 post-correction and said ~360 pre-correction. 21m elevation is likely too low, as I crossed four highway bridges.

I've had a similar impression, but it's not as strong and I'm not sure it's due to OruxMaps. I haven't yet been able to do a full-drain ride, but I'll post results here as soon as I have done one.

Sorry, only saw the reply now - three months later. Thank you very much for the hint.

+1 for this one. Displaying current power is just one side of the coin. I've also recently acquired a power meter and started to use it for indoor training. While it's still winter, soon this will change, and I'll still want to use power data for training analysis. Hence, it would be great if Oruxmaps could offer support for .fit files. I'd very much love to avoid to buy another device which for everything but power analysis would be completely redundant.