Garmin Mucks Up Altimetry

Garmin Altimeters – “Way Off” Across The Board


Old Adage: “If it ain’t broke don’t fix it

Garmin Exec: “Let’s fix it

Thank you: Reader @Mike

A History of Altimetry

GPS gives you your 2D position on a map but it also can give you your 3D position and hence that third dimension is your elevation. That’s only as accurate as your GPS with the added complication of a longer time to get an initial 3D-fix than a 2D-fix.

Next, we have barometers that can accurately sense the number of times you climb the stairs each day from changes in air pressure over a few flights of steps. Similarly, they can be accurate when measuring your progress up the nearest mountain. Although that also relies on constant weather because changes in air pressure accompany changes in weather.

Anyway, if you put the two together (sensor fusion) you can get a pretty nifty level of accuracy which can be great when you are on that mountain or can simply be handy as bragging rights to confidently say how much you climbed each ride.

Satellite systems and other tech soon further improved matters as databases were created that assign an elevation to every GPS point on the globe with a Digital Elevation Model (DEM). Soon the likes of Garmin and Strava were post-processing your rides and giving you the option to get a super accurate post-ride elevation track.

More recently still, Garmin put the same elevation+GPS information into their watches and bike computers so that further data fusing of your position/altitude could be established.

And, you know what? It generally worked very well and so it has been for most of the last few years. There’s always some trickiness on steep mountain slopes and in cities but…generally…great.

Today’s Problems

But now it’s broken. Grrr.

Or at least a lot of people are finding it to be broken across generations of different devices. Grrr

Does Garmin Recognise This?

As an example, let’s take the firmware updates for the Fenix 6X (here).

I’ll just show the relevant bits to today’s discussion 🙂

Changes made from version 20.41 to 20.42 (Edit 5 Feb !!!!!!!!!!!!!) :

  • Improved robustness to nightly altitude calibration.
  • Fixed altitude calibration bug.

Changes made from version 20.30 to 20.41:

  • Improved altitude calibration.

Changes made from version 20.20 to 20.30:

  • Improved altitude calibration.

Changes made from version 19.20 to 20.30:

  • Improved altitude calibration.

Changes made from version 20.03 to 20.04:

  • Improved altitude calibration.

Changes made from version 20.01 to 20.03:

  • Improved altitude calibration

Changes made from version 20.00 to 20.01:

  • Improvements to altimeter algorithm

Changes made from version 19.78 to 20.00:

  • Update the altimeter’s auto-calibration to be either be “On” or “Nightly”. Setting to “On” will calibrate at night, activity start, and continuously during activities. Setting to “Nightly” will set the device to only calibrate altitude at night.

Changes made from version 19.77 to 19.78:

  • Improved altitude calibration.

Changes made from version 19.75 to 19.77:

  • Fixed altitude calibration prompt before starting an activity. Prompts now only display on activities that use GPS.

I sense a pattern emerging!

So, as you can see, that’s a LOT of improvement to altitude calibration that’s going on. Or, perhaps more correctly, something got broken and Garmin is not quite sure how to fix it.


I don’t seem to be having these problems as this ride from yesterday shows with the Garmin Fenix 6 Pro, I’ll add some Fenix 7 / Epix Gen 2 data later on my experiences but they don’t negate what’s happening out there in the wild.

Interesting Afterthought

@Zoltan, in the comments below, found this gem of information about how Garmin’s algorithm establishes your starting elevation by relying on a fix from these prioritised sources:

  1. Manual calibration immediately prior to starting the activity
  2. Prior manual calibration point at the same location
  3. Recent manual calibration, if the quality of the calibration is determined to be good enough
  4. Map data (DEM), if available
  5. Prior Connected DEM point at the same location:
    • Connected DEM refers to elevation data from the Garmin Connect app on a paired smartphone
  6. Connected DEM, if currently connected to a phone
  7. Prior GPS point at the same location
  8. GPS, if a good fix has been acquired:
    • After acquiring a GPS fix the timer ring will turn yellow. At that point, it can take up to 30 seconds for the GPS elevation to settle. If vertical speed settles to less than .1 m/s the GPS elevation data will be considered good enough use for altimeter calibration.
    • Before starting the timer, the elevation data field on the watch will preview the calibrated elevation”


So it seems to be good practice to get a GPS fix outside your front door and then make a manual elevation calibration. Obviously, there is a handily named site for just that one purpose:



Your thoughts on how this has impacted you are welcomed below. I suppose the solace some of us can draw is that Garmin MUST be aware of this as they are continuously fixing it.

Hopefully, this doesn’t mark a return to the bad old days of releasing stuff that just hasn’t been tested by more than one person and their dog.

Reader-Powered Content

This content is not sponsored. It’s mostly me behind the labour of love which is this site and I appreciate everyone who follows, subscribes or Buys Me A Coffee ❤️ Alternatively please buy the reviewed product from my partners. Thank you! FTC: Affiliate Disclosure: Links pay commission. As an Amazon Associate, I earn from qualifying purchases.

27 thoughts on “Garmin Mucks Up Altimetry

      1. Wow, you’re the first person that I find that is still using ST3.1 !!

        Check out MyTourbook(, it is IMHO the closest equivalent to ST and is actively maintained/supported, it imports Fitlog/fitlogex files and given that you seem to have a lot of experience, I’m sure your feedback could help improve it.

        Note: I am biased since I am one of the contributors though.

      2. It’s still working, so I’ll keep using it!
        ST3 is not perfect but I know how to use it and am short on time to learn something else that might not quite do what I want

      3. Most interesting is how the long since removed published “hack” really improved ST3. It freed a huge amount of memory and greatly increased response speed. I find ST3 very useful as a preprocessor to MyTourBook when I need to do bulk edits. ST3’s Overlay plugin combined with the Elevation plugin does allow very nice comparison analysis. ST3 could have been EoL’ed properly for its users.

      4. i seem to only use overlay plugin now.
        i have memory problems. i had to entirely disable the training load plugin and sometimes also get out of system resources errors when trying to load a fairly full logbook, decent spec i7 PC with loads of ram

      5. For sure, I have used ST myself recently for various needs, but I have migrated off completely all my data.
        When/if you have some time, check out MyTourbook, I’d be interested to have your feedback.

      6. There are more warriors than one, Frederick.

        I gave a chsmce to MTB 2 or 3 years sgo, but since my laptop is a Dell 6510 from 2012 or 2013 running on Win 7 32 bit, I had no other chance than keeping my beloved ST 3.1. I mean MTB 32 bit version was abandoned years ago. No bad feelings from my side, it just helped me to stick to Sporttracks. I also minimized the number of plugins, but Backup, CalculatedFields, CustomData, AfterImport, TrainingLoad, PowerRunner and 1-2 more are still there.

        And I agree with Tex, removing the thingamy speeded up ST3.1.

        I even played a very bit with the algorithm of PrefillLocation and PrefillCategory to improve it.

        So no need for a change now. But my son uses MTB….

      7. Warrior is a funny way to put it 🙂

        I totally get your perspective. I decided to migrate even before it was decommissioned mainly because my logbook was SO big that it was taking a long time to load (I told the ST guys that loading/storing data from a text file was just not the standard way to do it these days but it seems that they didn’t agree) and i didn’t want to split it to avoid the OOM error. At the end of the day, I was tired to go through “hoops” to make it work, but that’s just me.

        To be fair, I use MTB on an old PC from 2011-2012 with an AMD FX 4100 and an old ATI radeon and it works great as far as performance. But indeed, I use 64 bits.

  1. Yup, when I had 240m of elevation for a track run you know something’s messed up! Fenix 6s.

    1. I climbed over 2000 flights of stairs on a run recently with my Vivoactive 3.

      No wonder I was tired!

  2. I don’t have a problem either. I haven’t seen the weird problems people report in forums in real life. The changes are very subtle for me. I suspect the wild issues people see indicate a faulty barometric altimeter unit.

    Note a related change is the altimeter in the f6 is now disabled during pool swim which also disables the temperature sensor that uses to tell you the water temperature. An official Garmin representative said this was because pool swimming was causing premature failure of the barometric altimeter module, if I recall correctly.

    1. This can’t be right. It would mean just taking a shower or jumping to swimming pool/sea would cause the same issues because barometer works 24/7 and you cannot disable it during normal use.

    2. While I can well imagine water breaking the barometric altimeter module, how can that be something you can protect against by disabling it software-wise? It surely must be more along the lines of water, and salt-water in particular, damaging the membrane.

      1. I’ve discussed this recently elsewhere when first hearing of this “disable while swimming” issue. Pure conjecture but I studied the design (and compared to others also) and the Garmins on several units (in particular the ones they announced to disable it) all use a metal-shell barometric altimeter. Assuming that the shell is “ground” as common with most metal shell electrical devices, what can then happen is a galvanic reaction (in particular with something like chlorine in a pool, although seawater certainly has enough electrolytic compounds to cause reactions also)…
        Anyhow, long story short, it’s not the sensor membrane, but the shell likely reacting, and corroding as a result of the reactions, thus leading to failures.
        Many other brands (I looked at them open) are using simpler rubber-sealed plastic barometric sensors, thus will not suffer from this problem. It’s an “easy” fix for Garmin and anyone else using a metal-shelled barometric unit, simply swap to a plastic shelled unit… BUT of course, dimensions and specs all may be hard to match with such a change, hence “easy” in quotes.
        Again, this is educated conjecture, but it makes sense, in particular because some Garmin’s have non-metallic sensor units, and those are not reporting these problems, so the fact that it almost universally (from other discussions I was in) seem to be the models with metal-shells on the barometric unit, it’s a logical inference at that point that the shells don’t like chlorine…

  3. My Fenix 6 Pro Solar is four months old and the altimeter worked fine with 19.20, okayish with 20.30 and not at all with the newest Beta. It’s not hardware related.

    1. I have a fenix 6X sapphire. I’ve had 2 actually. The altimeter calibration has been fine — more repeatable than the 5X — the whole 2+ years. We have 3 commenters in this thread with 3 related but different pieces of kit really.

      I wonder if the SKU affects the reliability.

  4. Hi! Many thanks for looking into this.

    My thoughts:

    a) This isn’t a hardware problem. I am on the Instinct Solar. 16.50 messed altimeter and barometer up, 16.00 once again restored functionality, after having to completely set up the watch again, that is.

    b) While Garmin has reacted to the Instinct Solar postings and seems to have realised there is a problem, there seems to be no reaction so far in the Fenix and Epix forums. Garmin really has to up their game when it comes to listening to people. They don’t, and it’s been like that for a long time. In fact, I seriously don’t understand why developers or at least their team leaders don’t read and react to the forums for themselves. The number of new daily postings is not really that high. My experience is that very seldom people post a incorrect error analysis on the forum. What, however, quite often happens is that people without the problem and Garmin fanboys chime in to pretend there is no problem.

    c) The altimeter / barometer algorithm didn’t need ‘improvement’ and wasn’t broken, as you point out. It seems Garmin now introduced some kind of nightly calibration via the Connect app on the phone, which may sound clever, but probably means that the phone makes a positional fix either via GPS or phone mast and people do not realise this. It’s one more intrusion into privacy, and was pointed out nowhere. (I always think it’s strange that people never ask how something works. I remember when Whatsapp came out, and nobody seemed to realise that the only way it could connect people would be by uploading all the mobile numbers in your phonebook into the cloud. Admittedly, these days Signal does it with hashes.) Also, some people don’t want to have their watch connect to Garmin’s servers all the time.

    d) As a general rule, I don’t think one should automatically update with Garmin. Not updating is not like a computer or phone security risk like with an internet connected computer. The only exception would theoretically be keeping the stacks for Bluetooth and Wifi up-to-date.

    1. The approximate smartphone positional fix could be via Wifi, in that the postal address of many people’s Wifi is roughly ‘known’. I seem to remember that iPhone piggybacks WiFi for positioning

      1. If there is a geolocation from the phone, it will just be the geolocation API from the phone OS.

        That could be “interesting”. iOS and macOS use aGPS (assisted GPS) where there is a database of the position of wifi access points that assist in GPS acquisition or can be the only source of geoposition. Apple learns the position of the mac addresses of access points by correlating iPhone position data over time. Geoposition can also be deliberately blocked or the precision reduced by the user, among other things.

        It’s possible there are multiple problems interacting: hardware, algorithm, and data. For example if there is an underlying DEM model problem, it could easily be regionalized. If the algorithm to “improve” calibration accuracy relies more on DEM and DEM data in the map has a problem that would yield localized anomalies that people are reporting while other people don’t see any issue.

      2. yes the geolocation API, IDK if Connect links to that. that might not be great for use during a workout but would be good to get correct starting elevation.
        simple overnight calibration to a home address points would/should get a sensible starting elevation in most cases.
        yes there are also apparently problems with the DEM models themselves in less usual geographic scenarios plus scenarios like the classic “bridge over the gorge”

  5. Not sure when it supposedly stopped working, but all my ski data through last Thursday seems accurate! Not only does it seem accurate, matching previous outings, but it also isbrelatively closeto what my epic mix is reporting as well. That is Vails Epic Pass vodoo where they use rfid to track which loft you rode and the can calculate the vertical. However, its fixed and static and doesn’t account for skiing past the lif andbto another lower on the mountain. So, while my garmin never reports the same numbers as the Epic travks, they’re relatively close and I trust the Garmin numbers more.

  6. I have no problem at all with my 6X, because I am stubbornly insisting on the fw 19.20. I did not try betas, nor official 20.30.

    The reason of my carefulness were twofolded:
    1. People testing betas were compaining about altitude
    2. Garmin was not willing to explain how their altitude calibration logics were changed, I needed at least at the level Garmin had published as support article.

    Finally they updated the support article, but this update did not answer all the questions that the changes after 19.20 opened up.

    For more info see:


    Zoltan, aka Tisztul_A_Visztula

Comments are closed.