Jump to content

Elevation ascent displayed on device vs. FIT track record


Recommended Posts

I found a curious mismatch in data yesterday and want to see if anyone else has noticed this… While recording a bike ride on my Oregon 750t, the total elevation gain (ascent) recorded and shown on the device screen was 3425’. However, after downloading the FIT (and GPX) files to Basecamp, Garmin Connect, and Strava… all say the track total ascent is 3235’. Not sure why there is a ~200’ difference between what the Oregon screen said and what the actual track data shows.

 

I have seen reports from other Garmin devices that the FIT file elevation output depends on the altimeter calibration setting, and that even changing the calibration mode at the end of a recorded activity (before saving the track), can change the recorded elevation profile. My guess is that the device records the GPS elevation and barometric elevation simultaneously and then does the averaging or tossing of one of the data sets at the end right as you save the track/activity. Can anyone confirm?

 

For example, I have my Oregon set to "continuous calibration", while in theory, the device display could be using only the barometric elevation to show calculated ascent, until the very end when the track/activity is saved and the GPS and baro data are averaged and exported, thus losing my 200’ of ascent.

Edited by jmvdigital
Link to comment

Very common, and it depends on how each site retrieves and processes the data. On the Strava site, the following Help page gives some explanation:

 

https://support.strava.com/hc/en-us/articles/216919447-Elevation-for-Your-Activity

 

The Connect site utilizes a *correction*, which I'm guessing involves comparing data from your device to topograhic data for the area.

 

I've noticed similar inconsistencies when loading a Route vs the actual Tracklog when I get home afterwards. Invariably, the Tracklog shows a significant increase in the elevation profile stats vs, the Route information I downloaded off of NG Topo or some other source.

 

My tendency is to regard the topo data a bit more trustworthy than the what I retrieve off my device. Things like pressure differences during the course of the day, the loss of satellite retrieval due to tree coverage et al, gives a bit more bias to the data IMO. Although, I'll be the first to admit that I'm a bit of old school when it comes to data analytics, and my preference is for paper maps over the new technology.

Link to comment

Many of the fitness sites will correct elevation according to worldwide elevation database based on location. Corrections can help smooth elevation data, but aren't necessarily any better than your GPS since the scale at which this data is collected is larger than the resolution of your GPS.

 

Here's another thought, though. Are there any discrepancies in track distances from the trip computer on the GPS? Two things come to mind. 1. You don't have the trip computer synced to track data. The GPS samples location more often than it is recorded to track and that can lead to longer distances and larger elevation gains on the trip computer that don't get recorded to the track. If the 700 series is anything like the 600 series, there is an option to couple/decouple the trip computer from the track.

 

2. Your track is getting clipped during the saving process whereby the number of track points is reduced. (I don't know if the GPS actually does this if the track doesn't approach the maximum length of 10000 points)

Link to comment

Sorry guys, I guess I should have been more explicit… This is NOT a matter of online elevation correction by the various sites. I am very well versed in what Garmin Connect and Strava do to "correct" elevation data. This is what led me to getting a Garmin with a barometric altimeter. Got tired of the inaccuracies of Strava’s elevation corrections.

 

If I view that saved "activity" on the device today it still says total ascent is 3425’. But importing the same FIT file (straight from Oregon via USB) into Basecamp or Strava shows 3235’. Basecamp does absolutely no elevation smoothing or correction that I’m aware of. I’m trying to figure out why the device itself displays a different elevation total for the same file than any other software.

Edited by jmvdigital
Link to comment

Here's another thought, though. Are there any discrepancies in track distances from the trip computer on the GPS? Two things come to mind. 1. You don't have the trip computer synced to track data. The GPS samples location more often than it is recorded to track and that can lead to longer distances and larger elevation gains on the trip computer that don't get recorded to the track. If the 700 series is anything like the 600 series, there is an option to couple/decouple the trip computer from the track.

 

2. Your track is getting clipped during the saving process whereby the number of track points is reduced. (I don't know if the GPS actually does this if the track doesn't approach the maximum length of 10000 points)

 

I don’t know how to decouple the trip computer from the recorded track. I’m viewing the "activity" file on my Oregon, and viewing the same FIT file on Basecamp/Strava/GC… the trip computer shouldn’t have anything to do with any of it, should it?

 

Oh but I do see what you’re saying about the GPSr sampling more locations than is recorded to the track! That makes total sense. But then why when viewing the saved track/activity does it still show the higher elevation? Wouldn’t it show the recorded track elevation? If it is showing the raw GPS samples versus the recorded track, then where does it store those totals, because I can’t figure it out.

 

I suppose this brings me to a question about what to set my recording interval to to get the most accurate track. Losing 200’ of elevation gain is kind of a big deal for me. I currently have it set to "Auto - Most Often". Auto-pause is off. For this particular ride, total time was 2:53 hr, 16.2 miles, 1895 track points… which averages to a point every 5-6 seconds.

Edited by jmvdigital
Link to comment

DISCLAIMER: In a previous thread wherein determinations of elevation was discussed, my posts were characterized as "pseudo-scientific dribble":

http://forums.Groundspeak.com/GC/index.php?showtopic=318508&view=findpost&p=5337463

 

Now, having presented that cautionary note, I will offer my opinion:

1. Regarding elevations calculated purely from GPS considerations, barometric data excluded,

2. I assume that the errors in successive elevation values will be normally distributed,

http://en.wikipedia.org/wiki/Accuracy_and_precision

3. If so, I also assume that sum of a statistically significant number would approach zero as the number of values grows.

 

Consequently, if you take readings every 10 seconds and subtract start and finish elevations of every 10 second interval for an hour, I would expect the sum of the errors for those 360 increments to be essentially zero.

Link to comment

Consequently, if you take readings every 10 seconds and subtract start and finish elevations of every 10 second interval for an hour, I would expect the sum of the errors for those 360 increments to be essentially zero.

 

Except.... We are talking elevation gain and loss. So if you include the spikes, it will show a lot more gain and loss than actually occurred. If you are just looking for actual elevation readings, what you state may work depending on the cause of the error.

Link to comment

Usually the units with barometers work best as they don't get that spikey. You need to watch out for the auto-calibration. This normally happens shortly after the unit turns on. You want to make sure that is cut out of the track. It is easy to spot.... It helps to turn the GPS on well before the trip starts.

Link to comment

I think I know what's going on here so bear with me. Tracklog data on the unit is recorded at a rate of once per second regardless of the recording interval. So if you have the tracklog set to Auto-Most Often, you will still have values calculated once per second regardless of the smoothing "Auto" setting dictates. When you bring that tracklog into BaseCamp, the distance and elevation are calculated using the track points in the tracklog (truncated by the Auto setting). This was done to address those complaining about incorrect distance values who didn't understand that any interval setting less than 1 per second would smooth or truncate the values.

 

The symptoms here support the theory. The tracklog values, when read on the GPS, are showing you the data at intervals of once per second. This would lead to higher elevation and distance values then when the truncated tracklog is brought into BaseCamp/Strava which reads only the data in the trackpoints (which is truncated by the "Auto" setting making the values lower.

 

To test this theory, simply change your recording interval to once per second on the GPS device. The "once per second" data will be identical to the tracklog points. All three, the GPS, BaseCamp, and Strava should all be the same.

Link to comment

Consequently, if you take readings every 10 seconds and subtract start and finish elevations of every 10 second interval for an hour, I would expect the sum of the errors for those 360 increments to be essentially zero.

 

Except.... We are talking elevation gain and loss. So if you include the spikes, it will show a lot more gain and loss than actually occurred. If you are just looking for actual elevation readings, what you state may work depending on the cause of the error.

Want to look at some hypothetical numbers?

OK, going up from actual elevation of 1,000 ft to 2,000 ft and taking GPS readings every 100 ft.

GPS readings: 980, 1100, 1190, 1330, 1380, 1520, 1620, 1690, 1810, 1890, 2010

GPS intervals: 120, 90, 140, 50, 140, 100, 70, 120, 80, 120

GPS intervals summed: 120, 210, 350, 400, 540, 640, 710, 830, 910, 1030

Total error of 1000 feet: 30 feet

Average error per interval: 3 ft

Edited by Team CowboyPapa
Link to comment

I think I know what's going on here so bear with me. Tracklog data on the unit is recorded at a rate of once per second regardless of the recording interval. So if you have the tracklog set to Auto-Most Often, you will still have values calculated once per second regardless of the smoothing "Auto" setting dictates. When you bring that tracklog into BaseCamp, the distance and elevation are calculated using the track points in the tracklog (truncated by the Auto setting). This was done to address those complaining about incorrect distance values who didn't understand that any interval setting less than 1 per second would smooth or truncate the values.

 

The symptoms here support the theory. The tracklog values, when read on the GPS, are showing you the data at intervals of once per second. This would lead to higher elevation and distance values then when the truncated tracklog is brought into BaseCamp/Strava which reads only the data in the trackpoints (which is truncated by the "Auto" setting making the values lower.

 

To test this theory, simply change your recording interval to once per second on the GPS device. The "once per second" data will be identical to the tracklog points. All three, the GPS, BaseCamp, and Strava should all be the same.

 

This makes sense, but makes a big assumption that the device saves this 1-sec raw data somewhere (or at the very least, a summary of it), in addition to the smoothed FIT/GPX file that is exported when you save an activity. If it is saving that 1-sec raw data, it would then be reading from that, even when you go back and review a previous activity’s saved FIT file. Correct?

 

Why is there a recording interval setting at all on these modern devices? The FIT/GPX files are still so tiny compared to mapping data files and the size of internal storage. The FIT file from this ride is only 63kb. If it was doing 1-sec recording that would still only be like 315kb. Is there any down side to just setting it to 1-sec intervals then? The data will be smoothed by Garmin Connect or Strava anyway.

Link to comment

Usually the units with barometers work best as they don't get that spikey. You need to watch out for the auto-calibration. This normally happens shortly after the unit turns on. You want to make sure that is cut out of the track. It is easy to spot.... It helps to turn the GPS on well before the trip starts.

 

True. But I don’t think this has to do with what I’m seeing. That would be more of an issue for the overall recorded accuracy of the elevation gain, not why a single FIT/GPX file shows a different total on the device than on the computer.

 

That said, from what I’ve read about the auto-calibration is that it slowly progresses the barometric elevation toward the GPS elevation over up to a 30 minute period. I’m not sure of the best way to handle it for accuracy, unless like you say, you turn it on well before your trip start, but you’d have to be stationary at the trailhead for that to work. If you’re driving to your destination, your elevation will be changing the whole way and won’t really help the auto-calibration, will it?

Link to comment

.......

 

That said, from what I’ve read about the auto-calibration is that it slowly progresses the barometric elevation toward the GPS elevation over up to a 30 minute period. I’m not sure of the best way to handle it for accuracy, unless like you say, you turn it on well before your trip start, but you’d have to be stationary at the trailhead for that to work. If you’re driving to your destination, your elevation will be changing the whole way and won’t really help the auto-calibration, will it?

IM(not so)HO, the auto-calibration of barometric data by GPS derived data is like the old admonition: "..can't make a silk purse out of a sow's ear".

Link to comment

True. But I don’t think this has to do with what I’m seeing. That would be more of an issue for the overall recorded accuracy of the elevation gain, not why a single FIT/GPX file shows a different total on the device than on the computer.

 

That said, from what I’ve read about the auto-calibration is that it slowly progresses the barometric elevation toward the GPS elevation over up to a 30 minute period. I’m not sure of the best way to handle it for accuracy, unless like you say, you turn it on well before your trip start, but you’d have to be stationary at the trailhead for that to work. If you’re driving to your destination, your elevation will be changing the whole way and won’t really help the auto-calibration, will it?

 

The difference is from different sample rates. Higher sample rates will always show more elevation gain. Trust me, I've been looking at tracklog from different GPS devices for 20 years.

 

The auto calibration does it in one big jump a bit after the unit is started from what I've seen and then minds it own business. If there are correction later on, they are not easy to spot.

Link to comment

Want to look at some hypothetical numbers?

OK, going up from actual elevation of 1,000 ft to 2,000 ft and taking GPS readings every 100 ft.

GPS readings: 980, 1100, 1190, 1330, 1380, 1520, 1620, 1690, 1810, 1890, 2010

GPS intervals: 120, 90, 140, 50, 140, 100, 70, 120, 80, 120

GPS intervals summed: 120, 210, 350, 400, 540, 640, 710, 830, 910, 1030

Total error of 1000 feet: 30 feet

Average error per interval: 3 ft

 

The reality is the units take samples at fairly high rates, not every hundred feet. Samples are every few seconds or meters with most settings. You go up 5 feet, but the accuracy jump up 15. The next 5 feet it jump back down. You walk into some heavy trees and the reading wanders off jumping up 50 feet. You walk out of the tree and it goes back down. The tracklog shows an elevation gain and loss of 50 feet. The higher the sample frequency, the more erroneous elevation gain that is recorded. I've studied a lot of track logs and their elevation profiles and compared side by side units doing the same climbs. This is not theory. It is real life...

Link to comment

Thread side topic: Red90, if you're saying a high interval track log (i.e.,1-sec interval) will lead to erroneously high elevation gains... do you have a recommended interval for the best accuracy? I primarily track my mountain bike rides, which can gain and lose altitude quickly, along with fast turns and switchbacks. I can lose 1,000'+ in under 10 minutes. On paper a 1-sec interval would seem like the most accurate to capture all the nuance and most accurate distance and elevation gain.

 

As for auto-calibration, what is your recommendation? It seems like as long as the unit is on long enough prior to recording, that elevation accuracy should be good? How long does that calibration take? Is there a better "best practice" ... Say you arrive at a trailhead with an unknown exact altitude or pressure? Is it better to leave calibration off and know that while your exact elevation reading will likely be off, the relative elevation gain/loss will be more accurate?

Edited by jmvdigital
Link to comment

Thread side topic: Red90, if you're saying a high interval track log (i.e.,1-sec interval) will lead to erroneously high elevation gains... do you have a recommended interval for the best accuracy? I primarily track my mountain bike rides, which can gain and lose altitude quickly, along with fast turns and switchbacks. I can lose 1,000'+ in under 10 minutes. On paper a 1-sec interval would seem like the most accurate to capture all the nuance and most accurate distance and elevation gain.

 

As for auto-calibration, what is your recommendation? It seems like as long as the unit is on long enough prior to recording, that elevation accuracy should be good? How long does that calibration take? Is there a better "best practice" ... Say you arrive at a trailhead with an unknown exact altitude or pressure? Is it better to leave calibration off and know that while your exact elevation reading will likely be off, the relative elevation gain/loss will be more accurate?

 

I believe we will never get an exact elevation any where anyhow....It's the nature of the beast. Seems the only way to get correct is to have known readings at points and recalibrate often at those points. I've tried many things..and read plenty... it's common in just 45 minutes the barometer can change say .01 vary slightly due to weather very fast. Throwing off your readings by 50 ft.

 

I've left auto on and re-calibrated known elevation at the trail head and had mixed results. I think just using gps elevation will be off more. Auto uses gps and the barometer to come up with a figure. But it needs to settle in at the turn on I think. But the best way so far for me is to turn it on then leave it for about 15 minutes running. Reset track,trip data and then go on your way. It calibrates fast..seems about 10 mins or so. I have glonass/gps/waas settings and I think that helps.

Link to comment

........

I believe we will never get an exact elevation any where anyhow....It's the nature of the beast. Seems the only way to get correct is to have known readings at points and recalibrate often at those points. I've tried many things..and read plenty... it's common in just 45 minutes the barometer can change say .01 vary slightly due to weather very fast. Throwing off your readings by 50 ft.

 

.........

.01 what? .01 inHg? .01 psia? .01 nanoPascals?

Link to comment

Thread side topic: Red90, if you're saying a high interval track log (i.e.,1-sec interval) will lead to erroneously high elevation gains... do you have a recommended interval for the best accuracy?

 

My suggestion is to record in auto-most and filter the data later. This means you don't lose information especially on location and can make intelligent judgements to filter for determining elevation gain.

Link to comment

I grabbed a sample tracklog and attached screenshots showing when the auto-calibration happens. In this case, 4 minutes after the log (and unit) started). It all happens in one track log interval. The GPS was just sitting on top of the car the whole period and not being moved from the start of the track log until around point 30. This is with a 64S.

 

Untitled2.png

 

Untitled.png

Edited by Red90
Link to comment

Thread side topic: Red90, if you're saying a high interval track log (i.e.,1-sec interval) will lead to erroneously high elevation gains... do you have a recommended interval for the best accuracy?

 

My suggestion is to record in auto-most and filter the data later. This means you don't lose information especially on location and can make intelligent judgements to filter for determining elevation gain.

 

This is my newbie coming out, but I’m not sure what that filtering would look like, how to do it, or why it helps? Can you elaborate a little bit? I’m assuming the Garmin Connect and Strava both do their own proprietary filtering, right?

 

FWIW, I usually leave the device on, without recording, while I’m getting the rest of my stuff ready. And then only start recording once ready to get moving. I have not noticed any initial elevation jumps in my track, but then again, your example is pretty slight, so I’m not sure if I would notice that or not. As for exact accuracy, I compared two recent tracks on the same trails and found the same high point was recorded within 25’ of each other which I think is pretty good considering both tracks had elevation gains of 5500’ and 26 miles recorded between them.

Link to comment

Use Basecamp. Make a copy of the tracklog and choose "filter". See it in the screenshot above. Manually delete the stuff at the beginning and end that are not part of the actual trip, especially the beginning as you can see you get erroneous data as the GPS gains accuracy.

Link to comment

Use Basecamp. Make a copy of the tracklog and choose "filter". See it in the screenshot above. Manually delete the stuff at the beginning and end that are not part of the actual trip, especially the beginning as you can see you get erroneous data as the GPS gains accuracy.

 

I see. You’re just talking about trimming the tracklog. I envisioned "filtering" to be some sort of data massage that smoothes the track, removes stops, etc.

 

Red90, I may as well take this topic totally off the rails and get your input on auto-pause while we’re at it. I initially had it turned on, but found that even with the minimum 1.5 mph setting, it was pausing my track while I hike-a-biked steep sections or had to walk because I was beat. So I would end up with unrecorded gaps when viewing the tracklog on a map. So I turned it off, and quite frankly, don’t see the point of it. With auto-pause off, Garmin Connect and Strava both still seem to calculate moving time and elapsed time just fine. Basecamp only appears to show elapsed time anyway.

Link to comment

I see. You’re just talking about trimming the tracklog. I envisioned "filtering" to be some sort of data massage that smoothes the track, removes stops, etc.

 

No, I'm talking about filtering as well as trimming. Click on the filter button and you get a bunch of filtering options.

Link to comment

Basecamp only appears to show elapsed time anyway.

 

Basecamp shows moving and stopped time. You can see it in the screenshot I posted. I've never used the auto-pause feature.

 

I thought that I'd like the auto-pause feature, but it turns out to be somewhat of a nuisance. I hike just slow enough, especially when backpacking and ascending steep slopes, to trigger the auto pause when I'm still "moving," and if I'm tired enough, I don't resume fast enough to trigger the auto start. So when I'm hiking, I have auto pause and auto start turned off and I'll manually pause tracking when I make stops. For cycling, it's more useful.

 

Pausing the track in general is the main reason I upgraded to an Oregon 600. It eliminates birdnesting during breaks and I can pause tracking if I have to make a short side trip to pee or find a geocache. Little things that I don't really want to be included in my trip statistics.

Link to comment

Since elevation is defined as the height above sea level, and with

, how can anyone expect the value from their consumer grade GPSr to be absolute?

 

I don’t think any of us are asking for absolute accuracy in elevation. I’m far more concerned with consistency and total elapsed elevation changes on a track.

Link to comment

This whole thing is a mathematical can of worms. I know it sounds simple, but it's not.

 

The issue here is that total elevation gain is a fractal property. The higher the resolution of the data, the larger the value will be, even for perfectly accurate data.

 

Think of it this way: when you are walking with your fitbit, your wrist moves up and down as you walk and swing your arms. Should those up-and-down motions be included in your total elevation gain? Most people would say not.

 

What about climbing over a fence?

 

What about small waves in the road?

 

Once you have decided the scale of your interesting elevation changes, you then have to decide whether to record (and filter) them temporally or spatially.

 

The point here is that two different programs can look at the same data and give two totally different answers that are both correct.

 

Before telling me to "just average the data," be aware that a moving average (so-called "boxcar averaging") gives a demonstrably wrong answer that always misses the highest and lowest elevations.

 

My personal approach is to use Savitsky-Golay smoothing, which preserves the maximum and minimum elevations pretty well. I choose to smooth temporally rather than spatially, mainly because it is easier. But the results I get from recorded tracks are still somewhat sensitive to the order of the S-G filter I use.

 

Many GPS devices don't filter the data at all and thus over-estimate the total elevation change. In my experience, Basecamp also tends to over-estimate total elevation compared to my algorithm, but not as badly as the GPS units.

 

Short answer: there is no right answer to the question, so you'll have to live with the inherent uncertainty.

Link to comment

Here is some reading for you.

 

Barometric Pressure and Altimeters

 

Modern GPS receivers (GPSr) often include a barometric altimeter. Barometric pressure is essentially a measurement of the weight of the air above a given point. When a high pressure weather system is in the area, barometric goes up because the air is more dense or heavier - this is what pushes the rain clouds away. Low barometric pressure usually means more clouds. Barometric pressure is typically reported in inches of Mercury (e.g., 29.92 inHg) or in millibars (e.g., 1013.25 millibars).

 

A barometric altimeter is tool that measures the amount of air pressure at that location. A GPSr with a barometric altimeter can provide more accurate elevation data (sometimes within 10 feet or so) than it can obtain from using the GPS satellites alone (sometimes within 100 feet or so - yes, elevation accuracy from satellites kinda sucks, and it gets worse as your elevation increases because you're closer to the satellites making it harder to determine your distance from them).

 

A GPSr with a barometric altimeter knows that if the pressure decreases, that there is less air above it. Thus one of two things has occurred - either the GPSr has moved to a higher elevation OR the natural barometric pressure for that location has decreased due to weather changes. The problem is that the GPSr doesn't know which has occurred.

 

Altimeter Calibration

 

To get accurate elevation readings, the GPSr must be calibrated so it can equate a pressure reading to an elevation.

 

There are four ways to calibrate the GPSr barometric altimeter:

1. Enter the KNOWN elevation when your barometric pressure is unknown.

2. Use the GPS-calculated elevation when your barometric pressure is unknown.

3. Enter the ADJUSTED barometric pressure when your elevation is unknown.

4. Let the GPS-calculated elevation help auto-calibrate the barometric altimeter over time.

 

Method #1 tells the GPSr that the currently measured barometric pressure in the GPSr is what should be expected for that exact elevation.

 

Method #2 does the same thing, except that it uses the rather inaccurate (+/- a couple hundred feet) GPS-calculated elevation.

 

Method #3 allows the GPSr to determine the current, accurate elevation by determining the difference between the measured pressure in the unit and the sea-level adjusted pressure you provide.

 

Once the GPSr has a good idea of what the accurate elevation is for the internally measured pressure, changes in pressure can more accurately be represented as increases or decreases in elevation. For example, a pressure change of .01 inch of mercury as measured by the internal barometer equates to ~10 feet of elevation change.

 

But, your GPSr assumes that the the only thing that changes pressure is it moving higher or lower - it ignores the fact that weather also affects pressure. Thus, if the atmospheric pressure around you changes, your elevation accuracy will suddenly be out of whack. This means you should only calibrate your altimeter using pressure or elevation if you want increased accuracy over short periods of time (shorter if the weather/pressure changes) and if you'll remain within a small geographic area (because changing locations is more likely to result in an atmospheric pressure change).

 

So which calibration method is best?

 

Methods #1 (known elevation) or #3 (known pressure) arguably provide the same level of accuracy, though using a known elevation is typically better because it is a finer value than the measures used for barometric pressure. Either way, the calibration values should only be entered outdoors, out of the wind (which can arguably affect barometer readings), and once your GPSr has been on, immobile, and well established for some time. All GPS altimeters require good GPS reception AND accurate pressure readings. Using the GPS altimeter in your car or indoors will not result in high accuracy - and could result in VERY poor accuracy (e.g., 1000's of feet off).

 

Letting the GPS auto-calibrate the altimeter is BY FAR the easiest - and by far the most accurate over long periods of time or distance or weather. This method uses the GPS-computed elevation to hone in on a 'best-guess' elevation and then uses the altimeter to help maintain accuracy and consistency of the displayed elevation over time. Most units recalibrate every 15 minutes using this method. Once your GPS location is well established, the accuracy of auto-calibrated altimeter readings are only slightly less accurate than manually calibrated readings. The advantage of auto-calibration is that you can be assured that natural pressure changes are not distorting elevation readings over time.

 

In short, there really are very few advantages to manual calibration over auto calibration. Perhaps the only notable advantages are increased accuracy within a short period of time after proper calibration and that most manually calibrated GPSr units can provide high accuracy almost immediately after turning them on - you don't have to wait for the unit to establish your position before getting a highly accurate elevation reading (e.g., the unit can read the barometric pressure much faster than it can triangulate your position).

 

If you calibrate your GPS altimeter with known pressure or known elevation, you must turn off "Auto-calibrate" function in your GPS otherwise it will ditch your entered value and go back to the best-guess GPS elevation in a matter of minutes. Most units prompt you to turn this off after manual calibration. But be sure to turn this function back on later otherwise the reported elevations will likely be WAY off because the pressure will likely have changed.

 

Some tips on using pressure calibration

 

If you choose to calibrate using a known pressure value, be sure to use sea-level adjusted pressure readings(sometimes referred to as ASL, MSL, or elevation adjusted). You can get these from local weather reports and from airport METARreports. METAR reports for your local airport are available here - just find the numbers after the A and put a decimal point in the middle. For example, my local airport METAR contains A3035, so my current sea-level adjusted pressure is 30.35 - or 30.35 inches of mercury. METAR and weather station pressure values are typically accurate for perhaps 100 miles from the reporting station/airport (naturally less if the weather is changing).

 

Your GPSr expects an elevation adjusted pressure. The pressure can typically be entered in inches of Mercury (inHg) or in millibars.

 

If you're using a home weather kit, barometer, or get the pressure from another GPS system or weather station data feed, these will typically NOT report elevation or sea-level adjusted pressures. Using these values will cause great inaccuracies - higher inaccuracies the higher your elevation. Because one inch of change in mercury represents ~1000 feet of elevation, if you live at 5000 feet elevation, your elevation adjusted pressure might be 30.10 inches, but a barometer would probably show a local (unadjusted) pressure of 25.10 inches. If you enter 25.10 inches into your GPS, elevations shown on your GPS will be off by 5000 feet!!!

 

Some tips on using elevation calibration

 

The optimal method for calibrating using a known elevation is to use an elevation benchmark. Go tohttp://www.geocaching.com/mark/ and enter your zip code and try to find a benchmark you could use (U.S. only). Be sure to look for one that has recently been found in good shape (has a smiley face icon) and that has an adjusted (e.g., very accurate) elevation (check the description for "Altitude is ADJUSTED"). Benchmark elevations are VERY accurate - usually within a few 1/10s of an inch - pretty remarkable considering most were placed in the 20's and 30's.

 

Because the GPS unit itself is only accurate to within 10 or so feet of elevation at very best, you may be just as well off using a good topographic map or even Google Earth to determine your location's elevation for calibration. One good method is to use a benchmark initially then use that to determine your home's elevation - then use this elevation to calibrate your unit each time you leave home. Be sure to measure an elevation outdoors - taking it inside or calibrating inside will ruin your accuracy.

 

GPS altimeters and aircraft altimeters

 

It is important to note that airplane altimeters and GPS altimeters may vary a lot except when on the ground. One reason is that the airplane altimeter uses the pressure at some nearby airport to provide a basis by which the elevation is determined. This is why pilots are constantly updating the pressure setting on their altimeter - not only to ensure accuracy for when they land or fly over local terrain, but also so that their pressure setting is the same as every other plane's in the immediate vicinity.

 

When you're flying at 15,000 feet, the pressure will be significantly lower than at the airport below because there is less air above you than the airport (just like the local, unadjusted pressure at Denver is much lower - ~5 inches of mercury lower - than at sea level). But you want all airplanes in the immediate area to have one uniform pressure setting in their altimeters - otherwise you could risk collisions. One plane flying at an indicated altitude of 15,000 feet with a pressure setting of 29.75 and another plane with an indicated altitude of 14,000 feet but a pressure setting of 30.52 will be MUCH closer in ACTUAL altitude than 1000 feet.

 

Planes flying above 18,000 feet tend to fly faster and thus use a standard pressure setting of 29.92 so that all planes up there are reporting the same indicated altitude and don't have to update their pressure settings every few minutes as the pressure at the ground changes below them. Because of this standard setting, a plane flying at 35,000 feet with a standard pressure setting of 29.92 might actually be flying much higher or much lower than 35,000 feet above sea level. All that pilots care about is that what they think is a certain altitude is the same as what everyone around them thinks. They only care about really accurate altitude when landing.

 

If you take a GPS on your flight (make sure it's OK with your airline before using it in-flight!), you'll notice that the GPS elevation and the reported airplane altitude may vary a lot. Also note that GPS elevation accuracies decrease slightly as you gain elevation. Oh, and be sure to disable your GPSr barometric altimeter on a pressurized plane or the results will be, well, WAY off.

This post has been edited by apollosmith: 03 January 2010 - 05:27 PM

Link to comment

FWIW, I have another example. This time I noticed that there is a difference in what the total elevation the Oregon states when viewing a saved FIT/Activity file vs. a GPX track. This could be the root of the original discrepancy I noticed. On this particular ride, the 2096’ ascent number appears to be the correct one. I compared with a buddy who was also recording the ride, and I had recorded it on Strava on my phone (which I know does it’s own elevation corrections, but it was 1966’ total ascent). The 2424’ is not correct. Furthermore, I imported both the FIT and GPX files into Basecamp and they both show the same ascent at 2096’. Interestingly, the files do show a 3’ different in max elevation and total descent, and an 8-second difference in elapsed time. While those are teeny tiny difference, it does point to the fact that there is some slightly processing difference in how it creates an Activity/FIT file vs a GPX track.

 

Also notice in the device screenshots that the mileage and max elevation numbers don’t match (and don’t match what Basecamp says). I also find it interesting that despite being the more robust file type, the FIT file screen on the Oregon shows far less data than viewing the GPX.

 

FIT file screenshot:

Garmin_FIT_HJ.jpg

 

GPX file screenshot

Garmin_GPX_HJ.jpg

 

I guess the moral of the story is for now that there is some sort of calculation/display bug, and don’t rely on the device-displayed elevation numbers for an Activity file.

Link to comment

I guess the moral of the story is for now that there is some sort of calculation/display bug, and don’t rely on the device-displayed elevation numbers for an Activity file.

 

Did you not even bother to read my detailed post above? I thought I explained what is going on very clearly.

 

The right answer is: both numbers are correct. They just answer slightly different questions.

Edited by fizzymagic
Link to comment

I guess the moral of the story is for now that there is some sort of calculation/display bug, and don’t rely on the device-displayed elevation numbers for an Activity file.

 

Did you not even bother to read my detailed post above? I thought I explained what is going on very clearly.

 

The right answer is: both numbers are correct. They just answer slightly different questions.

 

Yes, except that’s not what’s happening. Did you not read that when I import both the FIT and GPX into Basecamp, both read almost the same? It’s only when reading the FIT file on the device is the elevation way off. If it’s as you say, that the GPS device does not have any filter and thus over-estimates what is basically the same raw data… then why does it not do this consistently with an Activity and a track record? And honestly, it seems a bit much for it to over-estimating by 328’ out of only 2,100’ total.

 

PS: Is there some way to put your theory to an actual test? Is there a tool that will read a FIT and GPX file and apply NO filtering? Which I can then compare to Basecamp? I couldn’t find any info that Basecamp does any default filtering of track data. If it does, it’s consistent between the GPX and FIT files.

Edited by jmvdigital
Link to comment

I guess the moral of the story is for now that there is some sort of calculation/display bug, and don’t rely on the device-displayed elevation numbers for an Activity file.

 

Did you not even bother to read my detailed post above? I thought I explained what is going on very clearly.

 

The right answer is: both numbers are correct. They just answer slightly different questions.

 

Yes, except that’s not what’s happening. Did you not read that when I import both the FIT and GPX into Basecamp, both read almost the same? It’s only when reading the FIT file on the device is the elevation way off. If it’s as you say, that the GPS device does not have any filter and thus over-estimates what is basically the same raw data… then why does it not do this consistently with an Activity and a track record? And honestly, it seems a bit much for it to over-estimating by 328’ out of only 2,100’ total.

 

The GPX file is, in general, not the same data it uses to calculate the total elevation gain. So it's NOT the same raw data. Generally speaking, GPS devices filter the data so that your GPX file does not actually include every measurement that it made. Sometimes the frequency with which it outputs point to the GPX track is user-configurable, but more often it just does it automatically. Look at your GPX file. Modern GPS devices measure position 10 times per second; older devices once per second. How often are the points reported in yours? Some GPS units report points to the GPX file based on distance traveled rather than time. In that case the points will be unevenly spaced in time.

 

If your GPX file has a point for every second, then perhaps you have found a genuine bug. Otherwise, I would just say that the GPS does it for every measurement it makes and that the results are not useful to you. But a 10% variation is certainly not unheard-of.

Link to comment

The GPX file is, in general, not the same data it uses to calculate the total elevation gain. So it's NOT the same raw data. Generally speaking, GPS devices filter the data so that your GPX file does not actually include every measurement that it made. Sometimes the frequency with which it outputs point to the GPX track is user-configurable, but more often it just does it automatically. Look at your GPX file. Modern GPS devices measure position 10 times per second; older devices once per second. How often are the points reported in yours? Some GPS units report points to the GPX file based on distance traveled rather than time. In that case the points will be unevenly spaced in time.

 

If your GPX file has a point for every second, then perhaps you have found a genuine bug. Otherwise, I would just say that the GPS does it for every measurement it makes and that the results are not useful to you. But a 10% variation is certainly not unheard-of.

 

In the example I just posted screenshots for, there are 9,833 points over a 14.8 mile track, with a total elapsed time of 2:43:51. By my math, that is 9,831 seconds. So it was recording at roughly once a second on average. My Oregon 750 is set to record on "auto - most often" so I realize there is some variability in there. Does that change your answer?

 

And I absolutely get that the device does not necessarily record every measurement it takes while you’re active. That recorded frequency is controlled by whatever you set the device to. However, the core issue that I’ve been trying to get at is how the heck the device is showing 2 different elevations for the basic same set of RECORDED data. The FIT file and the GPX file only contain the recorded points at the frequency you set, correct? They don’t contain that native data with EVERY point the device calculated. So they only contain the data at the frequency you set, which is likely lower frequency than what the device is tracking during the activity. We all agree on that, correct? So I believe we can basically ignore the device’s native tracking, because that info is not saved in the FIT or GPX file once you stop and save your track/activity. I’m not talking about viewing the trip computer during an activity and comparing it to the saved GPX file later. I’m talking about comparing two sets of recorded data long after the activity is over. Both files contain the same number of points (9,833 in this example), so the frequency of those points is irrelevant (it’s not like the FIT file has twice as many points, so the elevation resolution is much higher). I’m NOT questioning whether the total elevation would be different for a track recorded once every 10 seconds to one recorded every 1 second.

 

If you’d like, I can share the FIT and GPX file and you can see if you see any meaningful difference in the dataset that would account for a 328’ foot elevation difference. If you can’t, I believe I have found a bug.

Link to comment

This whole thing is a mathematical can of worms. I know it sounds simple, but it's not.

 

The issue here is that ....

I will not take issue with that post above as it applies to the unit as it calculates its elevations along a trip.

 

However, here is what I expect that it would do after it determines each elevation:

1. Subtract from each elevation after its determination the most recent elevation to calculate the most most recent elevation increment, either positive for ascent or negative for descent.

2. Then add algebraically that increment to the sum of the previous to determine net ascent (positive) or net descent (negative).

3. Also add all positive increments for total ascent and add all negative increments for total descent.

4. Alternatively, the subtraction of the first elevation from the last should yield the net ascent or descent.

 

Note that I am avoiding the difference between calculating the intervals between all calculated elevations or just the recorded elevations.

Link to comment

Just an update… I’ve been talking with Garmin Support about my findings. They have confirmed that they can’t explain it yet and no one else has reported this yet. They are transferring me to work with their engineering team.

 

Here’s a comparison showing multiple bike rides and what the Oregon 750 shows depending on whether you are viewing the Activity/FIT or the Track/GPX on the device…

 

oregon_fit_gpx_spreadsheet.jpg

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...