mschwett
Well-Known Member
- Region
- USA
since a recent thread which discussed the mission control app's interpretation of "time" as different from strava or other apps, i took a look at the data for todays ride a few different ways.
in the past i've compared ride data captured with mission control, rideWithGPS, and cyclemeter and found that there are predictable - and small - differences between the total distance and the exact definition of the route. GPS is imperfect, and has a limited sampling frequency. but those errors for most riding conditions are really quite small, a few percent, perhaps. elevational discrepancies are much greater.
but what happens if we use the SAME source data, captured only in mission control, but then processed and viewed in strava, or specialized's ride app, and compare it to the idealized map data from the RwGPS route planner?
here is the "data": remember - the ride was captured ONLY in mission control.
distance (black/white circles): strava's initial reading of the distance is the same as mission control, assuming there is some rounding going on. 43.15 vs 43.16, whereas "ride" displays that as 43.2. the recorded value is likely 43.15x, or the calculations between points are being done with different degrees of precision. hardly significant. strava's "correct distance" option shifts the distance down by .85 percent, quite a small amount. of note is that it's shifting in the opposite direction from the route planned on the map, a basemap which bears a very high resemblance to the route ridden, including small sections of driveways, pathways, the major roads, intersections, etc. if i had to explain the difference of 1.7 percent between the planned route and the distance traveled, i'd probably put it down to the centerline of the roads, the radiuses at turns, and the inflation pressure of the tires. why strava's correction increases the variance, i could not say.
time (not circled, oops.): this one is very easy to understand. strava and specialized "ride" both use the duration of the ride and a simple algorithm to determine "moving time." i only stopped twice on this entire ride, and both times i paused mission control. those two pauses totaled 34 seconds, and neither of them was long enough (since GPS tracks tend to float a bit when stopping) to trigger a "moving time" pause in strava or ride. i've observed this over and over again, a ride with no stops whatsoever has exactly the same duration, whereas a ride with stops will show increasing variation with the number and shortness of the stops. very long stops will show as stops in either platform.
elevation (blue circles): this one is all over, undoubtedly due to the quality of the elevational basemap used for corrections, the accuracy of the iphone's barometric altimeter, the sampling rate as we go up and down lots of little dips and rises, and the terrible accuracy of GPS elevation. of note, the strava figure and the RwGPS route plan figure are very close (1.96 percent!), leading one to believe they probably use the same underlying topographic model. i had to manually correct a few obvious errors in the elevation profile of the route plan where it spiked up or down for no reason.
power (green and orange circles): the values for average power (green) are in agreement between strava and ride, which makes sense since the total time is also in agreement. the "adjusted power" or "weighted power" obviously uses a slightly different calculation, with specialized's figure 4% higher.
calories (yellow circles): this one is a bit of a head scratcher. the only variable here would be the "efficiency" of the human body, which has been scientifically measured over and over again to be between 20 and 25 percent. mission control and strava are clearly using the same value here, with less than half a percent variance (possibly due to the extra 34 seconds strava thought i was riding hahaha). specialized's own "ride" app, however, seems to be doing something else entirely, which is curious since they obviously have the power data, and the app is made by the same company that makes mission control. clearly, a different intern wrote that code!!
so, all in all, a very high degree of consistency. when i log my ride data, i use the mission control distance, the strava elevation, the mission control calories, the mission control time, and the strava weighted power. i don't actually use ride unless i used the motor, in which case it's interesting to see when i used it and how much, which strava cannot show (since specialized doesn't put in the .fit file!)
in the past i've compared ride data captured with mission control, rideWithGPS, and cyclemeter and found that there are predictable - and small - differences between the total distance and the exact definition of the route. GPS is imperfect, and has a limited sampling frequency. but those errors for most riding conditions are really quite small, a few percent, perhaps. elevational discrepancies are much greater.
but what happens if we use the SAME source data, captured only in mission control, but then processed and viewed in strava, or specialized's ride app, and compare it to the idealized map data from the RwGPS route planner?
here is the "data": remember - the ride was captured ONLY in mission control.
distance (black/white circles): strava's initial reading of the distance is the same as mission control, assuming there is some rounding going on. 43.15 vs 43.16, whereas "ride" displays that as 43.2. the recorded value is likely 43.15x, or the calculations between points are being done with different degrees of precision. hardly significant. strava's "correct distance" option shifts the distance down by .85 percent, quite a small amount. of note is that it's shifting in the opposite direction from the route planned on the map, a basemap which bears a very high resemblance to the route ridden, including small sections of driveways, pathways, the major roads, intersections, etc. if i had to explain the difference of 1.7 percent between the planned route and the distance traveled, i'd probably put it down to the centerline of the roads, the radiuses at turns, and the inflation pressure of the tires. why strava's correction increases the variance, i could not say.
time (not circled, oops.): this one is very easy to understand. strava and specialized "ride" both use the duration of the ride and a simple algorithm to determine "moving time." i only stopped twice on this entire ride, and both times i paused mission control. those two pauses totaled 34 seconds, and neither of them was long enough (since GPS tracks tend to float a bit when stopping) to trigger a "moving time" pause in strava or ride. i've observed this over and over again, a ride with no stops whatsoever has exactly the same duration, whereas a ride with stops will show increasing variation with the number and shortness of the stops. very long stops will show as stops in either platform.
elevation (blue circles): this one is all over, undoubtedly due to the quality of the elevational basemap used for corrections, the accuracy of the iphone's barometric altimeter, the sampling rate as we go up and down lots of little dips and rises, and the terrible accuracy of GPS elevation. of note, the strava figure and the RwGPS route plan figure are very close (1.96 percent!), leading one to believe they probably use the same underlying topographic model. i had to manually correct a few obvious errors in the elevation profile of the route plan where it spiked up or down for no reason.
power (green and orange circles): the values for average power (green) are in agreement between strava and ride, which makes sense since the total time is also in agreement. the "adjusted power" or "weighted power" obviously uses a slightly different calculation, with specialized's figure 4% higher.
calories (yellow circles): this one is a bit of a head scratcher. the only variable here would be the "efficiency" of the human body, which has been scientifically measured over and over again to be between 20 and 25 percent. mission control and strava are clearly using the same value here, with less than half a percent variance (possibly due to the extra 34 seconds strava thought i was riding hahaha). specialized's own "ride" app, however, seems to be doing something else entirely, which is curious since they obviously have the power data, and the app is made by the same company that makes mission control. clearly, a different intern wrote that code!!
so, all in all, a very high degree of consistency. when i log my ride data, i use the mission control distance, the strava elevation, the mission control calories, the mission control time, and the strava weighted power. i don't actually use ride unless i used the motor, in which case it's interesting to see when i used it and how much, which strava cannot show (since specialized doesn't put in the .fit file!)
