Massive Altimeter problem during fast descents since 16.70 (incl. all following betas up to SW 25.10) / Fenix 6x Pro Solar --> possible fix found?!

This is what I’ve just sent to the Garmin team:

Dear Garmin team,

the altimeter under 16.70 has a (massive) problem on fast descents.
I did 8 skydives with the release candidate of 16.70.

Barometer set on auto for 2 of them, on altimeter for the other 6.
During the climb to altitude in an unpressurized Cessna Caravan the altimeter worked flawless (used one analog and one digital altimeter for comparison) on all jumps.

However during freefall, there was a massive lack in accuracy. During the skydive the reduction in altitude was way to slow. At opening once the parachute was fully open (always around 720-780m according to the other devices) the watch showed still values between 1800 and 2500 m !!!

Upon landing it slowly came back to 0 on one jump. The other jumps it ended with values between 500m and 1841m.

The watch worked flawless when jumping back in September (sorry - no jumps in between).

My experience in regards to skydiving:
2500+ jumps  (both military and civil)
Jumping with digital altimeters 2200+
Jumps with this particular watch 150+

Feel free to contact me via mail or cell-phone.

UPDATE:
Garmin has picked up on this and opened internal tickets.
Fit files of 13 test jumps submitted. Now updated to 17.72 beta to jump with this as well.

UPDATE 2021-07-25:
Still does NOT work with beta 17.75

UPDATE 2021-08-12:
Still does NOT work with beta 18.77 

UPDATE 2021-08-23:
Still does NOT work with beta 18.80

UPDATE 2021-08-23:
Still does NOT work with 19.20. 
It seems that the processing done by Garmin does cause the problem. 
Using the raw data from the barometric sensor (which some activities do) allows you do have accurate values.

UPDATE 2021-10-03
Still does NOT work with beta 19.21
However, it seems that the processing has been altered. The drift away from the real values appears to not be as massive as it has been with previous versions.

UPDATE 2022-05-01:
Still does NOT work with 20.87. 
Apparently the processing done by Garmin does still cause the problem. Upon landing, the altimeter still showed the exit altitude of 4100m :-(
Using the raw data from the barometric sensor (which some activities do offer) allows you do have accurate values - during the complete Freefall until landing. 

UPDATE 2022-05-28:
Still does NOT work with 21.71. 
Upon landing, the altimeter still showed the exit altitude of 4080m :-( 
(EPIX 2 with 8.31 worked like a charm)

UPDATE 2022-06-17:
Still does NOT work with 22.10. 
Upon landing, the altimeter still showed the exit altitude. 6 jumps all with the same result :-( 
(EPIX 2 with 8.37 still  workes like a charm)

UPDATE 2022-08-21
Still does NOT work with 23.00. 
Upon landing, the altimeter still showed the exit altitude. 18 jumps last week all with the same result :-( 
(EPIX 2 with 9.32 starts with “funny” behavior - still have to investigate)

UPDATE 2022-10-14
Still does NOT work with 23.73. 
Upon landing, the altimeter still showed the exit altitude or some random altitude that was way above ground. 12 jumps last week all with the same result :-(

(EPIX 2 now overides manual calibration immediately with correct altitude if calibrated to values below 50m. 50m or above values are "accepted" and kept.)

UPDATE 2023-05-19
Still does NOT work with 25.10.
Updating to the latest Beta (25.86) today and will jump again in about 10 days. 

UPDATE 2023-05-28
I had two succesful altimeter operations with 13.22 Beta
However also used the tip of described by rinserepeat in one of the latest comments.
Further investigations (jumps) will follow in two weeks. 

  • Received now „altifast“. Thanks Thumbsup

  • I think I get it now, you were using a disposable e-mail account, did the first one time out or something?

  • Yes, exactly. That's right. But now it has worked.

  • I have installed the app. Thank you! If you feel like refining it a bit, I would suggest that it refers to a "zero point". The altimeter in skydiving always shows 0 on the ground. If it could be made so that when you start the app you get the value "0", and the changes in altitude change with respect to that zero point, that would be optimal.

  • that's already controllable by an input from the user.  When you're on the ground, go into the regular Garmin altimeter app and calibrate the altitude to zero.  That will change both displays to zero.  I forgot to mention it in the e-mail, but any time you need to adjust the altitude displayed that's the method to use.

    I suspect the Garmin calibration operation most likely does what you're suggesting, as you adjust the calibration value it subtracts some altitude offset from what it expects the actual altitude to be at a given pressure.

    But, the change you suggest is simple, I can add that as a third option in the setup menu.  Rather than have the app start up and automatically zeroize, you'd go into the menu and select the zeroize option, which will provide a one button press calibration back to zero.  That way the ability to calibrate to any altitude you choose would be retained if you ever need it.

  • the change you suggest is simple, I can add that as a third option in the setup menu.

    Yes, if you could program it that way, that would be nice :)

  • Hi 5693709/hi bluefish, 

    thanks for your efforts and. post-exchange.
    In regards to the altimeter reading - the Fenix 6 altimeter always changed every 1 second - which is fast enough also for skydiving. Pre SW 16.70 this worked fine. The is why I assume that your app might still fail as well as I assume the output of the barometer is just flawed. But let's see.

    In regards to zeroing - it would be great if you could add an option to set it to negative values on the ground as well. This is needed, when your landing zone is higher than the takeoff altitude. Garmin doesn't let you set negative values.

  • I had a long reply typed out, then edited it and got what looked like a double post, so I deleted one, but that deleted both of them, so its lost.

    So here goes again:

    Yes, the display updates once per second, but the altitude display is filtered, so if you change altitude rapidly the final elevation value doesn't show up immediately after one second, it lags about 5-8 seconds before the display finally settles on the new elevation.  This is evident while driving, if you crest a steep hill the watch will continue showing increasing elevation for a few seconds after you start back downhill.  The app I've written shows the difference between how quickly the sensor responds vs. how slowly the Garmin altitude app responds.

    I'm using a very old f/w version on my watch, so I've never experienced what you have with the 16.70 release because I don't have it installed.  It sounds like the altitude response is a lot slower than before that update, is that right?  Also, I can't explain why you got the crazy final altitude values on a couple of jumps, did you have auto-calibration enabled by chance?  I'd keep any auto-calibration options turned off, at least then you can rule out that variable.

    @bluefish

    what version of f/w are you running, something 16.70 or later?  If so, then I'm curious what you're seeing as the lag time with the app running on your watch.  If you let it stabilize on the floor for 10 seconds, then pick it up as fast as possible to the top of your reach, how many seconds elapse before the two displays match?  On mine its in the 5-8 second range, and I'm reading in feet, not meters.

  • I've added the ability to zeroize to any altitude, the user inputs the value numerically.  This will allow you to set the zero point to something either below or above your takeoff altitude.  There is one limitation though, it currently will not take negative elevation values, so if your landing location is below sea level I'll need to update the code to be able to accept negative elevation values for the zeroization offset, it currently accepts values from 0 to 6000m or 0 to 20,000ft.