Garmin, Strava and RWGPS accuracy

[Paul Nevins]

How high do you actually climb? RWGPS uses the "digital elevation model" (DEM), which for the US probably came from the USGS 7.5' maps and is not that accurate. Each contour is 40 feet. The pressure sensors in the bike computers are not super accurate, so when it says you climbed 3 feet, maybe you climbed 4 and maybe you dropped a few feet. It seems to be a little more accurate when there are large differences in elevation. Anyway, none of them are super accurate. If you upload your route to Strava or similar, and the GPS bounces around off the road due to tree cover or other factors, then the bouncy lines pick up extra elevation gains and losses due to the DEM. Apparently Strava will overinflate elevation by as much as 200%!

Side by side Garmin 500s can be off by 5-10% on the same ride.

Read this post on how wildly inaccurate elevation data is and why.
http://regex.info/blog/2015-05-09/2568



Cyclemeter 1493 feet vs Strava 2123 feet 🙊🙈🙉🤷🏼‍â™,️🤷🏼‍♀️🙀


Morning Ride

[karlos]

RWGPS has a great discussion how THEY do it - https://ridewithgps.com/help/grade-and-elevation. Also, time series analysis and advanced signal processing were part of my ~40 yr career as a mathemetician, in academia and at SAIC. Strava is known to be lacking in their ability to do time series analysis, not only with elevation data. There was at least a 3 yr old thread on Strava Support Forums because their moving time is also typically inflated, resulting in lower average speeds. It has been deleted by Strava support because it got out of hand. Since time series analysis and digital filtering was one of my areas of expertise and I even wrote the original algorithms at the Aerospace Corp for GPS's geolocation functions in GPS receivers (of which our phones inherit today), I offered python code to Strava that does ALL the calculations using standard time series analysis where you have controls like you are "stopped" when your speed is less than 3 mph (a flexible setting). Strava never really wanted to dive into the math I sent them. My codes generally agree with both the RWGPS app and Garmin devices. Of course, signal processing has a stochastic component (atmosphere, ionosphere distortions and all kinds of other goodies) and so you don't expect exact agreement. GPS elevation would be more accurate if your GPS receiver could "see through the earth" as your GPS antenna would be completely surrounded by all the satellites nicely separated (another optimization we provided at Aerospace) on basically a sphere. Because the satellites used are located roughly on a hemisphere above the horizon, there is a bias and a barometric adjustment actually improves differential (not absolute) elevation and it is elevation differences that provide total ascent and descent on a ride (notice RWGPS also provides descent numbers).

If anyone wants my python code, which will read your post-ride .gpx or .fit files, to analyze, just email me privately and you can waste even more time after a ride.