I am sick and tired of Garmin releasing "improvements" that ruin things that used to work just fine

Note: all of the issues below are fairly new. I haven't had any of these issues prior to the 11.28 update.

1. Wrist HR used to work acceptably well last year. Now if fails to work properly on 100% of runs, for large parts of those runs, producing unreasonably high HR that I can't possibly have. For example, in one of my recent runs it tracked me in the upper part of Z5 for 30 minutes, all while I was running easily downhill breathing mostly through my nose.

2. The abnormally high HR from the wrist sensor makes my watch "autodetect" the new maximum HR, which is absolutely unreachable for me. I am 52 years old. Believe me, I don't have the max HR of 186, especially not the one that was detected on a very easy run.

3. The new max HR results in auto-adjusting my HR zones even though the zones are based on LTHR%. If it is based on LTHR% that means it must not change unless the new LTHR is detected! What's the point of having it LTHR based then?

Here is how I found my LTHR% zones auto-adjusted by the watch:

Based On: %LTHR

Z5: 105%-114%

Z4: 99%-104%

Z3: 93%-98%

Z2: 83%-92%

Z1: 67%-82%

Isn't that ridiculous?

Furthermore, I I clearly remember configuring my watch to not auto-detect the max HR, but it seems that has been ignored in the last update.

According to https://www.garmin.com/en-US/garmin-technology/health-science/heart-rate-monitoring/:

Compatible Garmin devices can automatically update your maximum heart rate using your performance data. If a heart rate higher than your currently set maximum is identified and passes a reliability threshold, your personal maximum heart rate is updated on the device or in the Garmin Connect app.

This feature can be turned on or off in the Physiological Metrics -> Auto Detection menu of the device.

Guess what, there is no longer Physiological Metrics menu in my watch after the last update, and no Auto Detection menu that I can find. It seems Garmin has decided that it should simply be turned on by default for everyone.

And someone please tell Garmin engineers that there shouldn't be a 1% gap between zones. Zones are supposed to be continuous. 

4. Unrealistically high HR results in negatively affecting secondary metrics like Performance Condition, Training Load, Recovery Time, VO2 max. Bad data in - bad data out.

5. Sleep tracking is completely ruined too because my Garmin now thinks that I sleep when I work at computer. And it replaces my night sleep with this short fake daytime sleep. I don't really care about the sleep tracking, but that destroys other training and recovery metrics such as Training Readiness. What's the point in Training Readiness if all the raw data is useless.

Again, all of those things used to work quite well until Garmin has "improved" them. Has Garmin heard about beta testers? Not throwing half baked beta builds at users hoping that users would catch bugs but real dedicated beta testers who deliberately look for bugs. Also even when users report bugs in the beta software, it seems that Garmin just shrugs and releases the half baked updates regardless!

  • This isn't a medical device it is a niche of technology that is still not mature. You think Garmin is the only manufacturer with bugs? Go visit the Apple Watch communities.

    Pay the piper or go back to a regular watch and work out without a Garmin.

    Also, what is arguably more important is changes in your training over time. The imprecision's work themselves out over time through averaging. Also keep in mind TRENDS are TRENDS and they are not dependent on precision. They are dependent upon errors being systematic. As long as errors are systematic and not random error then trends can be argued to be more valuable than precision anyway.

    If I see my HRV rising over time and it has a margin of error...who cares? My HRV trend is what I care about, which guides me on what is working and what is not as far as my lifestyle and daily routines go.

    This isn't a simple strain gauge being slapped onto a piece of material....this is a bag of algorithms working off your body's physiology using an optical sensor.

  • Sorry, but your reply isn't helpful. I understand that there is a lot of complexity. I am a software engineer in a large and well known software company myself, so I am well familiar with the complexity of software development.

    But, as I said, all these things I mentioned are used to work just fine. What happens here is that Garmin doesn't have a good quality control process in place. I've been reading this forum long enough to see that some quite egregious bugs end up being released. Sometime users warn about them in the beta forum, and updates with those issues still get released.

    My HRV trend is what I care about, which guides me on what is working and what is not as far as my lifestyle and daily routines go.

    Good for you, but I use my watch daily for training. I need metrics that I can rely on. I no longer feel that I can rely on Garmin metrics.

    I am under impression more and more that Garmin feeds semi-baked data based on assumptions and statistical data rather than real sensor data. That was clearly demonstrated, for example, in the case of Garmin Index S2 scale which fakes the user body fat%, which changes the body fat% for the same person when that person changes their age in Garmin Connect. With the wrist HR, similarly, it seems that the watch has assumptions of where my HR is supposed to be. As a very fit person who falls into the top 1 percentile of all Garmin users, I probably don't fit in the statistical model. My watch insists that after 30 minutes of running my HR must be in the 150+ range regardless of what my actual HR is, and that it where it ends up on every single run now.

  • “Guess what, there is no longer Physiological Metrics menu in my watch after the last update, and no Auto Detection menu that I can find.”….

    on the watch: settings -User Profile - heart rate and power zones - auto detection.  Also available on the App - Device - user profile - etc. 

    I’m not having any issues so it is not a generic issue across the board (so can’t offer any more help).  I don’t see 186 being a crazy Max HR for your age.  I was around that back at that age. I’m 13 hrs older and have a max Hr of 180 (I see very similar HR results with either the OHR or a strap. 

  • Yes, it seems that Garmin has moved the Auto Detection menu into a different place. But by doing that it has reset HR auto-detection back to be enabled by default.

    Anyway, that doesn't explain why detecting a new max HR, even if that was true, should be adjusting LTHR based zones. It is ridiculous for Zone 4 to be above the LTHR as it ended up in my case. Also it is ridiculous for the Zone 2 to be that high.

  • The issue with LTHR zones being reset by max HR was reported here 4 months ago:

    https://forums.garmin.com/beta-program/fenix-7-series/public-alpha-bug-reports/i/public-alpha-10-xx/10-37-lthr-based-hr-zones-changed-to-incorrect-values---lthr-unchanged

    What's the point of having alpha and beta builds if the user reported issues get ignored?

    How hard it can be to not touch LTHR based zones unless LTHR is updated?

  • The should definitely add stuff that broke or got turned off or moved to the changelogs.

    • like turning off temp recording for all activities
    • fixing something how GNSS is handled that broke GNSS for IQ apps and the users had to inform the IQ devs themselves and point to some info in the beta forum about how to get it working again.
    • bugs that did get through to the betacycle like recently that the rep count in the summary of a strength training is now a ridiculous high number

    Just a few examples that come to mind off the top of my head.

  • The issue with LTHR zones being reset by max HR was reported here 4 months ago:

    Well, the thing is that this post was not "voted" in the beta forum. I don't think anyone at Garmin has ever looked at this post there. Presumably Garmin will look at the top 3 (or so) bugs that are posted there.
    I assume that since the introduction of this new beta forum, much more work has been created for the developers , but they can't manage to solve it.

    I am in favor of continuing to use this beta forum for discussions among users. However, from my point of view it makes more sense if bugs would be reported in the conventional way as before by email.

  • Substantial issues on base function should be fixed regardless of:

    • how many people are noticing the issue, most won't notice and just think "ah that dumb watch acts up again, nothing I can do"
    • how many people are understanding the issue (at a certain level of complexity you just lose a lot of people), if the way to replicate it involves a lot of steps, has a lot of variables to reproduce, again most people thinking "yea sometimes it just does not work, no idea why, guess it's not worth it to buy the next model" = the more complex a problem is, the less attention it will receive = the less attention it receives, the more likely it is never to be fixed (At the same time, a lot of people could be affected by it, they just can't identify it because of the complexity, it appears to be totally random. But they still perceive that it does not work reliably.)
    • how many people spending their own free time to reconstruct a complex issue, create videos and images to add their voice to an already confirmed issue, it's confirmed, just fix it, don't count votes, this isn't a democracy where the user that can rally the most support from the people gets their bugs fixed (ok that's exactly how it is but it shouldn't be).

    The best way to really get a bug fixed would probably be to run paid advertisements so that enough people give Garmin feedback (if you are not a big tech influencer). And some external website where people can trade their votes "I vote for your issue in return you vote for mine".

  • Substantial issues on base function should be fixed regardless off:

    • how many people are noticing the issue

    Correct, I also see it that way. However, Garmin seems to see it differently. Instead of focusing on really important bugs that affect how things work, I get the impression that the developers decide what to work on first based on the number of votes. And if a post "please make the color of the minutes GREEN" is voted up quite often, that's what the developers care about first.
    This approach on the part of Garmin was also explained to me in a chat with support based on a bug I found in OCTOBER 2022 that there is a BUG in the Connect Web Portal that the subsequent editing of a route that contains route points is incorrect. The route "track" is automatically destroyed by Connect.

    I have reported this bug in October 2022, and a solution is still far from being in sight. Although Garmin was able to reproduce this bug last year. The Suppprt employee told me clearly "the priority of processing also depends on the number of reports".

    Take a look and try it out :


    https://forums.garmin.com/apps-software/mobile-apps-web/f/garmin-connect-web/313017/connect-changes-route-track-end-point-independently-after-adding-a-route-point-and-then-trying-to-edit-again 

  • Did you just start vote trading? You get my vote if I get your's for that issue from January 2022 (mine's older). Joy

    forums.garmin.com/.../fenix-7-series---gps-track-recording-is-stopped-during-activity-when-a-widget-is-displayed