I see the same thing on my Garmin 500. I just turned them off in Garmin Connect
http://connect.garmin.com/activity/282329233

Here is practically the same ride recorded on my 310xt
http://connect.garmin.com/activity/282323290

jaretj

Jeez - are we the ONLY person having this problem? I would have thought the ST forums would be up in arms over both the elevation correction and the fact that Garmin support says you can't use it for a 910xt

I just download to Garmin Training Center and then export to WKO+ 2.2. It displays correctly there and in GTC. The only reason I looked at my data on Garmin Connect is cuz you posted that issue.

I just got the Edge 500 last weekend so I don't have any data from before.

jaretj

Garmin seems to be pretty disinterested in post sale support of Connect or the gadgets. TKO/Training Peaks/Golden Cheetah etc.
If "someone" would hack the roms so that we could add our own ant device profiles and remove a few bugs life would be beautiful.

You ask why there are not more "upset" ST-ers for something like this? I wonder the same. I posted last week on the fact that for the Garmin 910xt, trainingpeaks speed data is simply WRONG, no other way to put it, wrong and inconsistant with time and distance in the same software. No interest on the ST forum. Crazy to me, for a company claiming compatibility with the Garmin 910xt. Trainingpeaks says they have fixed the speed issue for the online software, but there seem to be no plan to roll out a patch to WKO 3.0 so the user who paid for said software can get a functional product. Not sure if they are trying to "push" the online version onto paying customers?

That is odd. My elevation corrected tracks show pretty much the same as without correction.

I just look as Garmin Connect as a convenience and not as a tool like WKO+

I think they have taken care of their products with firmware updates fairly well. I own a 310 and a 500. Yes, they still have some issues but those two seem to give me what I need. I can't speek for the 510, 810, 910 and others.

jaretj

Garmin's elevation correction works by looking at the latitude/longitude coordinates in your GPS track and then looks the elevation up on a detailed topographic chart on the server. When it works, this can yield quite accurate data, but it is susceptible to positional errors in the lat/long data when operating near areas where elevation drops off/climbs rapidly (eg riding up a mountain pass, crossing a bridge, etc.). If the GPS error pins you a few meters to the left of where you actually are, for instance, the altitude it looks up could be at the bottom of the cliff rather than the road/bridge/etc. you are actually on.

When compared to the imprecise altitude measurements the GPS system can provide, the dramatically increased precision and accuracy the topographical corrections can provide outweigh those disadvantages. When compared to a (relatively) precise mechanism like a barometric altimeter, however, the advantages are much smaller so the disadvantages are more significant. That's why elevation correction is off by default with barometic devices and on with GPS-only devices.


Looking at this data, it would appear that there is a massive spike somewhere in the corrected elevation data. The corrected elevation plot shows you going from ~300' to a little over 1500', which is a similar delta to the 4,600 to 5800' in the uncorrected data. The corrected data, however, shows a maximum elevation of 5121', which is way off of the chart shown, so I'm going to guess that the lookup grabbed a few erroneous altitude points and measured you going up to it and then down right away. If you were running near an edge and you had a weak satellite signal, it may have been bouncing back and forth between the bottom of the hill and the trail and logging a massive altitude gain/loss each time. It's also possible that they've updated the topographical maps on their servers for your area and there is an error somewhere in that data doing the same thing.


As for the absolute altitude, I don't know the area but looking up that location on a map I would guess that the corrected elevation is more accurate than the uncorrected one? If that is the case, one of the weaknesses with barometric altimeters is that they have to be calibrated each time you go out with them. They measure changes in barometric pressure, so their readings are affected by both altitude and weather systems passing through. If you calibrate the unit while a high pressure system is around and then run a couple of days later under a low pressure system your absolute altitude readings will be way off (the relative data should be fine though). Typically, weather systems won't change the pressure a whole lot over the duration of a run/ride/etc, but over a few days it can shift quite a bit.

Most of Garmin's units (including the 910xt) can automatically calibrate if you store some preset locations in them (eg your house, bike shop where rides start, etc.). If you are in proximity to one when you start a session, the watch will automatically look up the altitude stored in that location and use that to calibrate the altimeter. Without that, it will try to use GPS to seed the altimeter, but GPS isn't very good at altitude readings and if you don't give it time to settle before starting the run/ride/etc. that reading can be pretty bad. Either way, adding some locations is relatively simple (especially if you have a survey map for your lot) and can help dramatically with the absolute altitude data.

The weirdest part about this whole situation is that everything was working FINE even on this exact same run, numerous times, until just about 2 weeks ago. The elevation correct settings work perfectly on those previous workouts. Something happened in the past 2 weeks on the webserver end that is causing my elevation correction to go nuts.

I'm also still peeved that Garmin's wimping out and just saying 'we don't support elevation correction for 910xt - just use the barometer.' From my prior workouts, I know for sure that when it's working, the elevation correction is substantially more accurate and reproducible than the barometer.

It's possible that they updated the topographical data they have for your region and that's what's triggering the problem. If they switched from low resolution map data to higher resolution data (eg satellite versus aerial survey), for instance, it could amplify the effects of positional errors. That is, with a lower resolution plot interpolation may have softened the descent on cliffs/bridges/etc. whereas when higher resolution data became available the sharper gradients created a falling-off-a-cliff problem (ie one sample on the deck of the bridge, next down in the valley (-100'), next back up on the bridge (+100'), rinse and repeat dozens of times) with erroneous data.

The other possibility is that they may have tweaked the algorithm a little and that is causing the problem. You can filter out a lot of these types of inflection errors by smoothing the data, but doing so often reduces the amount of detail in the resulting plots. They may have been responding to complaints that the corrected data was missing details and cut down on smoothing. Doing so would make other users data better but make yours worse, so it's a tricky thing for them to balance. The smart way to do it would be to compare the survey data with the measured data and detect errors that way (eg it's unlikely you suddenly descended 100' without the barometer picking anything up), but that would be computationally more expensive than just replacing the data wholesale with a bit of smoothing.


You likely got a low-level technician that doesn't actually understand the underlying problem and is trying to fit your description into a script. The elevation correction mechanism simply replaces the elevation data in your file with the elevation data that it looks up, so it's irrelevant what type of sensor collected the original information. If you could convince them to elevate it to a higher level tech that better understands what is happening, you'd likely get a much more nuanced response. With that said, stuff like this is likely statistically tracked and if there are enough complaints about it it will likely be put in front of someone that can do something about it.

When the latitude and longitude are perfect, the corrected data is going to be more accurate as it is captured using professional survey equipment that costs orders of magnitude more than a consumer-grade product like the 910. The downside is that it is susceptible to radical variances such as this when positional errors correlate with steep changes in elevation. There is a tradeoff here that will balance differently depending on a lot of variables; its significance will vary from location to location and small changes can tip the scales one way or the other. Playing the devil's advocate, dealing with the details of those problems on a case by case basis would be a massive amount of work given their inter-related nature (there are probably a handful of people in the company that are equipped to figure out and correct complex problems like this without breaking it for someone else), so they likely deal with them on an aggregate basis (ie many people in an area have to complain before it gets addressed). Fiddling with their algorithms for each and every report would likely just end up creating more problems than it solved. For all we know, the problem you are looking at right now may have been caused by someone else complaining about another problem and them making adjustments to address that :P

Unfortunately, it's difficult to word something like that in a way that doesn't sound like they are just brushing you off ;) As annoying as the 'just use the altimeter data' advice is, it's better than telling you they'll look into it and then not actually doing anything about it. It does address the immediate problem (ie in this case, the altimeter data is more accurate) and as it's a server side issue there isn't much you can do about it other than try and get other locals having the same problem to complain as well. This is unfortunately the big downside to cloud services like this, as there is no way to roll back to the older version when it did the job better than the new one :(

Weirdest thing today - did a same ride (not the run posted, but a 50 mile hilly bike that's also been acting up on elevation correct), and today it worked perfectly. Elevation correction works on todays' ride.

Unfortunately, all my rides/runs for the past 2-3 weeks where it was glitched out are still glitched out. Can't explain it. The ones before that are fine as well.

Oh well, as long as it's fine from here on out, I can live with that.

I'm having the same problem with my 910. Yesterday I ran the Rock 'n Roll DC half and it has my max elevation at 22,614 ft - that's nonsensical - the elevation in DC is just above sea level and it only changes by a few 100 feet. This started happing to me a few weeks ago -- very frustrating.

I'm looking at my splits and it happened at miles 4, 5, and 11 where there's a ~22,000 ft elevation gain then an ~22,000 ft loss. I recall going in tunnels around the times of those splits. Could it be something going on when the satellite signal is disrupted?

Mine did it repeatedly without any loss of signal and no tunnels, on courses that I've never ever had a signal loss on in the past, on many other times. Again, the GPS trace was perfect, as seen above. Hopefully it'll fix itself for you in the future as mine seemed to have done on yesterday's ride. (The old data is still wacky online but the new workout was ok)

My wife also has a 910 and ran the same race as me yesterday. She's running version 2.50 software and her elevation data is fine. I'm running 2.70 and have the problems mentioned above.

I hope I am not duplicating an answer here... I noticed this too when riding in steep mountains. The elevation correct feature takes your GPS position and cross-references it with a database to get altitude. Since we know the GPS position can be off by a few meters, on a really steep hill, especially on mountain switchbacks when you have a virtual cliff going up to your right and down to your left, this can cause it to estimate your elevation to be several meters higher or lower than actual. Notice how jagged it looks? Then it assumes that you climbed and descended between all those points that sometimes were 3 meters to high and 4 seconds later 3 meters too low and says you climbed or descended 6 meters over that time when in reality it was maybe .5 meters. In less dramatic terrain the correct feature works better.

---

-------------
Ed O'Malley
www.VeloVetta.com
Founder of VeloVetta Cycling Shoes
Instagram • Facebook

See your point, but it doesn't apply to my situation - I have MANY traces of the exact same route where the elevation correction still works perfectly. In either case, it shouldn't be 2x the elevation change even if it was a precipitous drop on each side being registered.

When the elev correct works, it works extremely well in my experience. My prior runs/rides are off by less than 1%, whereas the barometric on the 910xt is routinely 5%+ off. Becomes very clear when you do the same exact run/bike repeatedly and you see which number stays rock stable and which fluctuates.