Last updated on August 31, 2011
Past experience with wildly varying data has prevented me from trusting GPS-based devices for accurately logging distances while riding mountain bike trails, but after hearing reassuring reports of modern units and seeing how useful it could be to have one unit logging data for all three of my bikes and automatically aggregating it I decided to give it a go. I purchased a Garmin Edge 500 cycling computer and a GSC 10 wheel speed / pedaling cadence sensor a month ago and after beginning to use it things seemed quite accurate, but I continued to be a bit suspicious that it may not be providing as accurate of data as it could. So, I decided to do some tests.
The results of these tests have shown that when the Edge 500 is used in conjunction with the GSC 10 it is just as accurate as a wheel-based computer and can be relied on to provide sufficiently accurate distance measurements while riding curvy mountain bike trails. Coupled with all the extra data that the system can log (heart rate, location, temperature, cadence, etc) it’s quite a nice system for recording data.
Without the GSC 10 (using only GPS-based data recording) the Edge 500 showed drastic undermeasurement, 20.70% on a typical Southeast Michigan trail ride and 33.87% in a worst-case test scenario.
The Problem
When a GPS (alone) is used to record a route a series of samples are taken recording the device’s position. Math is then done to calculate the distance between the current and previous positions, and this distance taken in conjunction with the elapsed time this calculation can be used to determine speed.
When a bicycle traverses a curve this method of sampling results in the curve being broken into a series of straight lines the sum of which have a shorter length than the curve itself. Multiple tight curves compounded over a lengthy ride can cause a drastic under measurement of trail length. This is a real world example of a problem known as aliasing.
The image to the right illustrates this type of aliasing by showing a trail in black, red spots for the points where measurements are taken by the GPS, and green lines illustrating what the GPS (based on calculations) feels the distance between each point really is. These green segments are shorter than the actual black length of the trail, and this shorter measurement can add up over an entire ride resulting in the logged distance being considerably shorter than what was actually traveled. Thus the variation in measurement between actual route length and measured length can be compounded based on sample rate, speed, and how curvy the trail is, but other factors including GPS accuracy can come into play as well.
Traditional bicycle computers rely on a sensor watching for each rotation of a bicycle wheel and then use the count of rotations in conjunction with the circumference of the wheel and a clock to calculate distance, speed, etc. These devices don’t have a problem with aliasing because they are simply measuring the distance traveled by the bicycle wheel, a value which is almost always equal to the length of trail traveled. (While skidding wheels on downhills, spinning while climbing, and moving through the air may affect these results, the amount of time spent doing these is typically so minimal as to render these situations indistinguishable from background noise.)
The Edge 500 + GSC 10 system has all the instrumentation necessary to overcome aliasing by using a wheel sensor as a traditional bicycle computer does and incorporating these results into the overall logged data, but nothing in Garmin’s documentation illustrates (or even claims) that it does this or anything else special to ensure most-accurate recording. Garmin’s website for the GSC 10 doesn’t mention any distance accuracy benefits, choosing only to tout the fitness feature of measuring one’s cadence:
Monitor your pedaling cadence as you ride with this self-calibrating, wireless speed/cadence sensor. It measures and reports your pedaling strokes per minute, providing feedback for optimal performance.
Garmin’s only mention of the GSC 10 as being used to record distance data comes from this cryptic blurb from Page 28 of the Edge 500 Owner’s Manual (PDF):
If there is no GSC 10 paired, GPS data is used to calculate the speed and distance.
Anecdotal evidence from friends and various online forums point to apparently accurate data being received when using the Edge 500 along with the GSC 10, and their suppositions have proven to be correct. When used with a GSC 10 wheel diameter (the most accurate measure available as it bypasses aliasing) is used for calculating distance; exactly what I was hoping for.
(Note that technically any trail of any curvyness could be effectively recorded by sampling discrete points, but as dictated by the Nyquist–Shannon Sampling Theorem the sample rate must be greater than 2x the frequency of the curve. Most GPS units only record up to 1 second accuracy, meaning that any curve which can be traversed in less than two seconds cannot be accurately measured. This, of course, also ignores GPS accuracy issues (complicated further by tree cover, mountains, cliffs, etc) which throw another wrench into our measurement accuracy.)
The Solution
In short, the use of a Garmin GSC 10 wheel speed / pedaling cadence sensor connected to the Edge 500 along with an accurate wheel diameter setting (auto calculated or otherwise) ensures accurate distance results when riding trails. This is because, when available, the Garmin Edge 500 will use the wheel rotation information to determine distance.
The Testing
To determine if the Garmin Edge 500 + GSC 10 uses the wheel speed sensor for logging speed and distance, I set a bike up with a second, traditional style bike computer (a Sigma BC 1609). This computer’s sensor was positioned next to the GSC 10 and using the same spoke magnet, ensuring that it would receive wheel rotation pulses at essentially the same time as the Garmin system. A series of self-calibration routines for the wheel were run by the Garmin to ensure that a consistent reading was received, and then this diameter was entered in the BC 1609 so both units were set to use the identical wheel size (2190mm circumference). Photos of this setup can be seen here and here.
All tests were performed with the Garmin Edge 500 in Smart Recording mode, which Garmin describes as follows:
Smart Recording records key points where the fitness device changes direction, speed, heart rate or elevation. This recording type allows the user extended record time given that it is recording less track points thus taking less memory to store these points.
This varies from the Every Second mode and is likely the less accurate of the two, but in the interest of determining potential for inaccuracy leaving this default setting should suit our needs nicely. Testing Smart Recording versus Every Second is worth of further research, but that’s work for another time.
Three scenarios were then set up for testing, a worst case, a typical trail ride, and a typical suburban ride to a trail system, around the trails, then back. Amongst these a total of six test cases were set up, all designed to compare the resulting data from the Edge 500 to the BC 1609; tests to determine the GPS function by comparing it to the known standard of a traditional bike computer.
The Results
The data resulting from these test cases are as follows:
Worst Case: A series of tight loops, frequent turns, switchbacks inside of garages, and slow speed riding through the courtyard in front of my garage; roughly a 60′ radius paved loop. This was specifically chosen to be difficult for GPS to track. Three tests were run, one with GPS + Wheel Sensor, one with Wheel Sensor Only, and one with GPS Only.
This test shows that the Garmin Edge 500 and the Sigma BC 1609 nearly match when a GSC 10 wheel sensor is used. However, as soon as the wheel sensor was disabled the GPS-only distance determinations showed a tremendous amount of under recording. Over the course of three miles the GPS-only Edge 500 lost a full one third (33.98%) of the distance. While this really was a very challenging route to follow (image here), it illustrates that GPS-only data recording is prone to error on tightly curving paths.
Stony Creek: Typical southeast Michigan single track, with a good mixture of curving trail and straight sections. Used to compare the Edge 500 to the BC 1609 using GPS + Wheel Sensor to GPS Only. Two tests runs were made, each consisting of one non-stop loop of the MMBA Wednesday Night Group Ride route, one with GPS + Wheel Sensor and another with GPS Only. (This route can be seen using this map and following points 25-28-24-21-22-4-5-6-19-18-20-16-15-25.)
The Stony Creek test shows a 20.70% under recording of distance on this typical trail and route when using just the Edge 500‘s GPS sensor (in Smart Recording mode) for recording the route. This is nearly one mile lost for every five ridden.
River Bends: Riding to a local trail from my house, around for two laps, and then back home. This is a typical ride for me, partially road/pavement and partially single track. This test shows that under this situation the Garmin Edge 500 and Sigma BC 1609 match, which is as expected.
Garmin Configuration:
· Garmin Edge 500
· Software Version 2.80, GPS Version 2.40
· Data Recording Mode: Smart Recording
Testing Assumptions:
The following assumptions were made during this testing:
· 1% – 2% variance between computers (GPS vs. traditional) is acceptable. Due to a number of factors (wheel size, specific path followed down trail, Coastline paradox, etc) it is not possible to get a perfect number. A good number that doesn’t vary much is acceptable.
· GPS (in)accuracy is not taken into account.
· Wheel size can only be determined with a certain degree of accuracy. As a bicycle tire (in particular a large, squishy mountain bike tire) deforms while riding the circumference changes frequently while riding. An incorrect value could exacerbate or diminish variance between the Edge 500 and BC 1609 and would also lead to overall distance measurement errors. While as accurate as possible for this testing, it must be accepted that the circumference used is also not perfect.
· Variances in Moving Time are likely caused by slight differences in how movement is detected and potential landing (when stopped) of magnet between the wheel sensors and can be ignored.
Hi, your post on the MMBA forums brought me here. Does the 500 allow you to set the sample rate for GPS readings? I’m wondering if 1 sec intervals are enough to accurately capture elevation change of a trail. If you’re going 8 mph, you’d travel 11.7 feet in a second. At 15 mph, it’s 22 feet. Thoughts?
John Cox: Hey there. Sorry, but I don’t know. I don’t think it’d help much, though. As in your example, since you’re familiar with biking you know how much elevation (or distance) can change in that period of time, particularly if you’re going up and down rollers. I could see distinct elevation changes (which would count as climbing) being obscured by that.
I think it needs testing, mostly.
Thanks for pointing me here. You did a ton of research here. Appreciate it. I bought the same computer. My main concern with my bike is the cadence sensor….The gap between my crank arm and the chainstay is not enough to allow the cadence sensor to fit. Although…I just put a large deposit on a new bike (2012 S Works Stumpy), which my sponsoring shop allowed me to race at P2P. In looking at clearance issues on the bike stand, it looks like the gap between the S Works crank and the chainstay is enough to allow the sensor. Regardless….I can still put on the speed sensor and not worry about it, judging by your experience.
Thanks again. Although my newer training regimine is more time based than miles….it’s nice to see accurate data after a ride. My downloads onto Training Peaks without the sensor show a lot of inaccurate data, which is frustrating. Do you think my theory on why the speeds get so high (67 mph) is correct?? I didn’t see where you addressed that issue specifically, but as my wife points out for me regularily, I do tend to miss things…..:-) I was just thinking that the GPS looses signal, and then when it regains it, it just calibrates a MPH for that distance traveled without taking time into consideration.
Thanks c0nsumer!
~Mark
Mark Spore: No problem; I post stuff like this in the hopes that people will find it useful.
For the cadence sensor you don’t have to use the magnet from Garmin that straps to the back of the crank arm. I’ve heard of other folks having clearance issues and instead using small neodymium magnets either glued (epoxy would work well for this) or just simply stuck to the back of the crank arm or pedal spindle. This would just take a bit of playing, but should be pretty easy as the GSC 10 has an LED which can be illuminated during setup to show that it’s properly detecting the magnets. Or, as you say, you could just skip cadence. I like recording it, but I don’t really think it’s that useful for MTB.
I’m figuring your brief speed jumps are from GPS not-quite-accurately recording locations and calculating the speeds between the two. I always assume this will happen, and I didn’t even bother testing for it because there’s no solution. It’s just a fact of using GPS for speed recording. I suspect that because ~60MPH is not an unreasonable speed for a cycling computer to see then any sort of noise correction in the device doesn’t filter it out.
FWIW, software like TopoFusion can interpolate a spline to minimize the effects of the aliasing errors. Plus, it will do it in 3 dimensions.
I should get the GPX files you used (including the worst-case scenario) to see if a bit of post-processing can minimize the perceived errors *sufficiently*.
BTW, people seem to get much more repeatable tracks with the 305 than seem to come out of the 500 and 705. Dunno why….
I just noticed that you used “Smart Recording” (yeah, I should have noticed that before). As I’ve mentioned on any number of occasions, so-called “Smart Recording” is of insufficient granularity to give anything resembling accurate data. Not including a 1 second/point track for comparison kinda puts doubt on your greater conclusion that GPS’s do not give accurate distances.
FWIW, I ran some tracks through the TopoFusion interpolation function mentioned above, and with tracks of point/second frequency, interpolating a spline through the given points makes very little difference in the distance shown. This seems to indicate that a point/second frequency is more than sufficient to give accurate distance data for all intents and purposes.
Very useful research. Thanks.
I understand that distance from the wheel sensor is more accurate than distance from GPS. But how does Garmin resolves this conflict when recording information into the .FIT file? The record must include latitude, longitude, elevation and time. Are these coordinates modified to somehow conform to the wheel sensor data?
When I upload my ride to ridewithgps.com and export it as .TCX or .GPX file, and calculate speed and distance from the coordinates, I see large errors in speed, which could not have come from the wheel sensor. So it appears that the wheel sensor data is not recorded. Does anyone know a better way to view the contents of the .FIT file?
The limitations of the low sampling rate (aliasing problems) may be at an acceptable level, but does Garmin document the accuracy of the time record in the .FIT file?
Osman Isvan: Here is the FIT documentation.
Thank you, cOnsumer!
The FIT data format appears to be flexible enough to support a wide range of devices. With the Garmin Edge 500, what is the minimum accuracy (i.e., maximum +/- timing error) of the time stamp, relative to the preceding and following time stamps?
And when the GSC 10 wheel sensor is used during a ride, is the time /lat /lon /elev data in the .FIT file modified to fit the accurate speed and distance data obtained from the wheel sensor?
Osman Isvan: No idea, sorry. Sounds like a good research project for you, though… ;)
When the Garmin Edge 500 is paired with the GSC 10 wheel sensor, distance is sampled from wheel rotations and elevation change is sampled from the barometric altimeter. Therefore the data need not be contaminated by GPS errors at all. Indeed, when the GSC-10 accessory is present, average speed and total distance for a given ride are sufficiently accurate. But unfortunately the Edge 500 does not record the sampled data with an accurate time stamp; as a result, instantaneous speed and instantaneous vertical speed contain large (+ / -) errors due to inaccurate recording of time. This “bug” (or unreasonable limitation) in Garmin’s data acquisition system hinders all efforts for calculating power and energy from the uploaded data (for example, Strava, estimates instantaneous power and does a pretty good job of analyzing it, from this erroneously recorded data). GPS technology is needed only for showing the ride on the map; and even with distance aliasing, the Edge 500 is accurate enough for that limited purpose. The rest of the data can be recorded with a wheel sensor, altimeter and clock. Does anyone know of a data logging bike computer (not necessarily GPS-enabled) that can record time, distance and elevation?
Great post. I just got an edge 500, before that I was use phone based gps/app to track the distance and I was getting ~5.5 miles even with edge 500 gps. I then turn on the speed/cadence sensor I start logging 8 miles on the same trail. I still don’t trust this difference. I’m planning to do a similar comparison with a traditional computer at least to validate the distance aspect.
Thanks for the extensive research into this issue. My experience has also been that GPS gives wildly inaccurate distance and speed data on twisty trails, but your post was the only place I could find on the internet where someone has done the research and documented the solution to the problem. I hope Garmin take note and publicize this. Maybe they should give you a job! You are doing a better of documenting the value of the product than they are.
Dave C: Thank you, and you’re welcome. I’m glad to hear it came in handy. For what it’s worth, I’ve been finding that the Edge 510 with GLONASS enabled is much better than the 500, but it’s still not perfect. Thus, I continue to use a wheel sensor with my current 510.
Very good site you have here but I was wanting to know if you knew of any community forums
that cover the same topics talked about in this article? I’d really like to
be a part of online community where I can get comments from other
knowledgeable individuals that share the same interest. If you have any recommendations, please let me
know. Many thanks!