obstacles to progress

This subpage is dedicated to reporting special problems associated with accessing and interpreting the ride data recorded by a Garmin Edge 500 bicycle computer. The recorded information, which is stored in .FIT file format, can be accessed by a PC-based analysis software such as Garmin Training Center, or by cloud services such as Garmin Connect, Ridewithgps and Strava. Analysis includes generating a graph of elevation and speed versus distance. Some of these programs have utilities to convert some of the data into common file formats such as GPX, TCX, CSV, KML, etc.  File formats that can be opened in Microsoft Excel are of particular interest for independent analysis. Interestingly, a JSON file can be parsed by Excel and contains additional columns that include distance and speed, all of which are copied directly from the .FIT file in the GPS device. 

Distance, time and speed are redundant, and Garmin Edge 500 apparently records all three, but they don't agree with each other (the values in each sampling interval do not satisfy the equation: speed = distance / time). Discrepancy in redundant data is not a problem, but the problem is not knowing which data is the more accurate one. This discrepancy is shown in the scatter graph below, recorded during a 70 mile bike ride with a bicycle that is not equipped with a wheel sensor accessory. So, speed or distance could not have been measured independently; they had to be derived from the GPS data. 

The data recorded as "speed" has a range between 0 and 35 mph. The speed computed from distance and time data has values in excess of 50 mph, which did not occur during this ride. Therefore, if the discrepancy stems from a single source of error, that error appears more likely to be found in time or distance values than in the speed value. It is noted that there is a high density of (distance / time) values that are clustered near exactly twice the speed value. There appears to be another band near 1.5 multiple. This phenomenon is another clue suggesting that the "bug" is in distance rather then speed.

Interestingly, speed that is calculated from the longitude, latitude, elevation and time data has a better correlation with the recorded speed, as shown below. This suggests that the recorded time may be accurate, leaving "distance" as the most likely culprit.

If the speed data could have been obtained from a wheel sensor accessory, this observation would suggest that speed and time may both be accurate, and the scatter may be due to the known inaccuracy of GPS coordinates. After all, this assumption was the reason for connecting a wheel sensor accessory to a GPS device in the first place. But the Garmin Edge 500 records a "speed" even if no wheel sensor is present. So, it is not clear how Garmin calculates this speed. Apparently it is different than the formula that I am using. One possible explanation is that the sampled points are connected by splines rather than straight lines, making the distance between consecutive samples longer than the shortest distance on the surface of the earth. 

Another perplexing observation is that when the wheel sensor is present, the discrepancy between the GPS-derived distance and the "direct distance" doesn't disappear. In fact, the integer multiples become more evident. See the graph below. This data is from a different ride on different terrain that is longer and hence has more track points.

Another way to look at the phenomenon is to document the discrepancy between the sampling intervals calculated from recorded speed versus GPS speed.

According to Garmin's documentation, a pressure sensor is used for increasing the accuracy of elevation measurements. But it is not explained how the pressure data is used to augment the redundant GPS elevation. It appears that the recorded elevation is obtained directly from the barometric altimeter, although it is recorded as a GPS coordinate. Perhaps GPS technology could be useful for calibrating the pressure altimeter based on the long term history of the difference between pressure altimeter and GPS altimeter values; but that is not happening beacuse after about 5000 miles of use my Edge 500 still has a consistent elevation offset from actual elevation. 

Garmin is aware of this problem but have no plans to fix it. Regarding this issue, I received the following information from techsupp@garmin.com:

Dear Osman Isvan,

When you spoke to product support you got some of the information about how the unit records data. The FIT files used on the device do have two different strings of recording data the unit is receiving. When the activity is saved the two strings are married together and what is imported into Garmin Connect is the finished file. So there are not different clocks, but the information being recorded does not have a set time. Like the older Garmin Fitness devices they would could read data at every second. So when our newer devices came out we have to rewrite our programs to read the files correctly. There is no work around because there are no ways to edit the FIT file or to change any settings on the device.

There are third party sites that have been written to work with our FIT file devices. Training peaks being one of them when we switched to this new format. Until the site was updated there were gaps in the data and the reason was because that each track point may not contain heart rate, speed, cadence or power data. They were able to program their program to read the information being shown in the file and draw the graphs correctly.

We do not have any recommendations for cleaning the GPS data in the file. The accuracy of the device at the time the activity was created is stored with the coordinates. I do not know of any programs that will correct this.

The speed coming from the GSC10 is separate from the GPS speed. When using the Edge 500 the unit will take the GSC10 information first. For the activity the speed comes in meters/seconds. The distance is figured on the Edge 500 itself from the speed information coming into the device. Although the GPS tracks are used to draw the maps the speed is from the sensor.

The GPS elevation only effects the baro(barometric altimeter) initially when starting the workout. When you save a location on the device the elevation for the point is from GPS. This is used to help the unit calibrate it faster when you are within 50 meters of that point. For the rest of the workout the baro is used strictly for elevation readings and is recorded for the activity.

A track point is from GPS only. As we now know the device records the other information separately during the workout. So you can have a elevation reading and speed reading separate from GPS track points altogether. So GPS is only used to draw where you have been when using a GSC10 with the Edge 500. This is then used to draw the graphs you see in Garmin Connect.

The newer Fitness devices will not offer a file that will contain the information on every track point. We do understand that this would be ideal for what you and others are attempting to do. But once the switch was made to the new file structure. The information is no longer available even when the TCX file is exported from the Garmin Connect site. I want to thank you for your time and have a good day.


With Best Regards,

Steven B
Product Support Specialist
Outdoor/Fitness Team
Garmin International
913-440-8280 (fax) Att: Steven B, Associate #6998

It appears that a bicycle computer with the ability to record speed from a wheel sensor and elevation from a barometric altimeter with an accurate time stamp, would allow us to estimate instantaneous power and total calories more accurately than it is possible to do so from data recorded by Garmin fitness products. A GPS receiver, which can be used as an accessory to such a computer, would allow the user to view a ride on a map. The potential accuracy of speed, power and calories estimated from a GPS-only device that can record its location with an accurate time stamp, remains to be explored.