We are pleased to announce that on March 4, 2025, an updated Rich Text Editor will be introduced in the MyFitnessPal Community. To learn more about the upcoming changes, please click here. We look forward to sharing this new feature with you!
Elevations - Cyclemeter vs RidewithGPS vs Strava

Spokez70
Posts: 548 Member
I am a little confused about the Elevation reading on my GPS. I am using the Cyclemeter app with an iPhone 4s and then uploading the GPX file to both Ride with GPS and Strava. Both of the websites seem to have their own little take on the data with minimal differences on speed and ride time and such- but the elevation data seems way way off.
On a recent relatively flat ride Cyclemeter logged that Assent was 91' and Decent was 110' (I know that's off because I rode straight out and back on the same route.) When I uploaded the file to Ride with GPS it prompted me to verify the elevations based on their data and corrected it to +151/-151 ft. But when I uploaded the same exact file to Strava it zero'd out the elevation changes completely.
http://ridewithgps.com/trips/880892
http://app.strava.com/activities/19983617
Another example on a more hilly route Cyclemeter gave me 291' assent and 296' decent- meanwhile RidewithGPS 'corrected' that one to +1074/-1077 ft and Strava said 421 ft overall. This route is very undulating with quick short hills so maybe that confused things?
http://ridewithgps.com/trips/880894
http://app.strava.com/activities/19983620
Any ideas why the big discrepancy or which of these may be more accurate?
On a recent relatively flat ride Cyclemeter logged that Assent was 91' and Decent was 110' (I know that's off because I rode straight out and back on the same route.) When I uploaded the file to Ride with GPS it prompted me to verify the elevations based on their data and corrected it to +151/-151 ft. But when I uploaded the same exact file to Strava it zero'd out the elevation changes completely.
http://ridewithgps.com/trips/880892
http://app.strava.com/activities/19983617
Another example on a more hilly route Cyclemeter gave me 291' assent and 296' decent- meanwhile RidewithGPS 'corrected' that one to +1074/-1077 ft and Strava said 421 ft overall. This route is very undulating with quick short hills so maybe that confused things?
http://ridewithgps.com/trips/880894
http://app.strava.com/activities/19983620
Any ideas why the big discrepancy or which of these may be more accurate?
0
Replies
-
I don't seem to get accurate or consistent elevation data from my Garmin Edge 800 either, which is a bit frustrating for how much it cost. I do the same route to and from work and each time it's different! I then try letting Garmin Connect enable elevation corrections, but even then it's still not consistent.
Would be interested to hear how others calibrate theirs or get more accurate elevation data0 -
thing is, all GPS based solutions will come up with different readings - I did an experiment yesterday and ran 3 different trackers - endomondo on my Android Phone (HTC Wildfire S) A Garmin 800 and a Garmin 705.
They're all on the 30th August here - http://www.endomondo.com/workouts/87040125
Android - 204 m ↑ / 156 m ↓ ascent/descent, 40.41 km ride length, 3409kcals
Edge 800 - 314 m ↑ / 321 m ↓ ascent/descent, 40.64km ride length, 1205kcals
Edge 705 - 141 m ↑ / 133 m ↓ ascent/descent, 40.71km ride length, 1949kcals
(I also imported the same file from the Edge into strava, which "tweaks" the calculations somewhat...435m ascent and 929kcals....)
the differences in distance can pretty much be explained by the degree of accuracy of the GPS circuitry... it's possible to see how accurate the GPS is running on the edge's - some of the time, position was only accurate to a "circle of probability" of around 30 metres when I was in the woods, with restricted satellite lock coverage. Different recievers lock on the satelites differently - even 2 identical edge units won't come up with exactly the same figures, on the same ride, even mounted to the same handlebar! It'll be close enough to not matter a damn, but it won't be exact. To get real "military grade" precision, you'd need to be using something MUCH more expensive than a £300 bike computer. The GPS units that the Ordnance Survey used to use a couple of years ago, for example, are the size of a medium rucksack, and have a satellite aerial on them...
Domestic/General use GPS units are, I believe, optimised to concentrate more on location on the x/y axis - i.e. location - rather than the z axis - i.e. altitude. Hence the "barometric" add-in's on the Garmin's (800 and 705 have barometric sensors I know - though my 705 is somewhat knackered in this respect!) I doubt that the Mobile Phone has the same circuitry, and will be inherently less stable/accurate. Of course, the barometric only really registers change in air pressure, so a strong wind blowing into the unit could confuse the set a little, as of course could a large weather front crossing your path and the pressure dropping/rising quickly... But, if the units concentrate on x/y, and are STILL slightly inaccurate between units, then the z-axis readings will be even less accurate.
The "corrections" that for example Garmin Connect or Strava employ, just ignore the figures from the GPS unit, and work "from the map" - which CAN be more accurate, provided they've bought in an accurate set of map datum's... if they're calculating altitudes from (for example) the UK 1:50,000 ordnance survey mapping, the contour lines, and hence the altitude data is in 10m intervals. So, you could possibly ride 16km on a road that went up from 11m above sea level to 19m, then back down to 11 and up and down every 160m in a series of 10% ramps up and down, climb 800m descend 800m, and have a ride that showed up pan-flat! Even on the UK 1:25,000 mapping, the contours are at 5m intervals, which can still miss out some of the "rolling hills"
The Calorie values are an entire other can of worms, and I'm not going to even start getting into that issue here...0
This discussion has been closed.