Optical HRM still totally wrong with 21.19 - In fact, worse than ever

Hi 

unfortunately I have bad news. You closed OHR related topics like this
https://forums.garmin.com/sports-fitness/running-multisport/f/forerunner-955-series/384760/heart-rate-values-from-optical-hrm-still-totally-wrong-with-20-26

and this
https://forums.garmin.com/sports-fitness/running-multisport/f/forerunner-955-series/362273/heart-rate-values-totally-wrong-after-update-18-22

But you were asking to give you feedback, if we encountered that bug again.
This is the case - in fact, in my opinion the optical HRM is worse than ever now.

With 20.26 I was quite ok with the measurements of the OHR while walking/hiking and for higher intensity workouts I usually use a HRM strap (beside bike commuting).
With 21.19, the OHR cannot be trusted AT ALL, even for low intensity stuff like walking/hiking.

See this heart rate values, that I recorded during an hours walk today:

The average is a HR of 70!!!
While walking one hour with a pace below 10 minutes/kilometer.

My resting HR is 48, still, this is just random. It is nowhere near the real pulse I had during that walk.
And regarding blood flow: Yes, it is cold now in Germany (4 degrees Celsius), but I was wearing a thick fleece pullover and Polartech gloves and the watch was below it all.

Yes, you may contact me and have a look at my activities and I live in Germany.

  • The HR function for these devices is useless for following anything that elevates the HR. The behavior is widespread and not isolated to a few defective devices. An activity shouldn't be required. If the HR goes up the watch should follow. It is pretty good for sleep and chair sitting. Anything that elevates your HR that you want to reliably track requires a chest strap. Garmin has endless well documented examples and is apparently not capable of offering a solution or admitting a poor hardware design.

  • Somewhat related question: How can you get data from both? Whenever I connect an external chest HRM, the internal one shuts off and I have no data from it for that run.

  • not very nice but in my case just about acceptable.

    Hmm, yeah, at least it is in the same region and gets up to higher values - something it did not always do for me.

    Here some more examples and I think you will see the general problems again - even though the pulse measurement does not stay that low as it did in my original posting. All walking:

    Walking on 01.01.2025
    Overall the average HR of 90 is kind of ok, maybe, but as I included the pace and the heigh, you can see the typical problems here: Several non plausible jumps and drops in HR which do not correllate.

    Walking on 03.01.2025
    Same here - lot of non plausible jumps and drops, also in the first 8 minutes the HR drops, which is absolutely not plausible.

    Walking on 04.01.2025
    This is the worst, in my opinion - more and higher jumps and drops than the two before. Also it does not match my pace or the high profile.

    This was recorded as hiking, so different activity type. Overall the HR is maybe plausible, but see the drops and jumps again... for example shortly after 25 minutes

  • Anything that elevates your HR that you want to reliably track requires a chest strap.

    Sure, I do that for every sport (running, biking, indoor rowing) - but really, I don't want to wear external HRM for walking or hiking. Will not do that and still I expect, that the watch captures this ok.

    Garmin has endless well documented examples and is apparently not capable of offering a solution or admitting a poor hardware design.

    Well, I hope there will be a solution. At least I will continue giving input and ask for a solution.

  • I learned that both sources are logged in the fit file you can download and plot with an online fit file viewer.

    There you can also see when automatic switching is enabled which source the watch takes as most reliable (which is in most cases the HRM).

  • updates, new examples - the issue persists.

    OK, this is walking down the hill - it is very strange, that in the end the HR jumps up like crazy

    I wanted to also show the walk hill up - but the forum won't let me upload the picture for it :/

    It also has unplausible jumps and also again - even though I walk the hill up, the average HR is not higher, but a bit lower than walking down.

  • This one is a very new example from today - with latest firmware 21.22
    For me, the issue continues - please let the developers know

    Ok, what we see here is the typical problem with the walking activity: I walk down a hill quite fast and the OHR locks at a certain range - which is too low probably.
    Then I have to stop at traffic lights for maybe half a minute. The moment I start again, the OHR algorithm starts to evaluate data "freshly" and is now in a completely different range - which is probably more realistic as I was walking quite fast.

    I started the activity a bit early as you suggested (but to be honest, I don't have the time to warm up for minutes for everyday walking).
    It was cold with -4 degrees Celsius (little below freezing point), but I was wearing a Polartech fleece, an isolated Jacket and Polartech gloves - so the blood flow should have been ok (I was not feeling cold at the arm).

  • I have a silly question - WHR was fully OK on SW 16.xx - why did the developer not implement a working Version in a new FW?

  • So I do not think that the software development team of a company employing nearly 20000 people is stuffed with idiots Wink.

    Either they have things to do with higher priority (developing new features for the next generation of products) or - what I think and already said pretty often - software can never fix completly what the hardware is not able to...

    Maybe they just do not get the whole thing tuned that it works for anybody under each circumstances.

    Or maybe the sensor degrades to fast and they are trying to fix what is possible by refining the algorithms but the led is not that bright anymore after 2 years service or the photodiode not that sensitive - typical effects.

    If you choose your safety margin in hardware development (too) low then this might be a result.

    And honestly - it's better to have the users think it's the software than a problem of the whole hardware series.

    There were some people who downgraded the software or at least tried it because AFAIK the did not get the firmware of the subsystems downgraded. Maybe they can do some comparisons it the performance of OHR is back to their full satisfaction (which might be biased since you never have the same measurement setup again)

    So as long that there is no offical statement of the company you will never know.

  • In addition to what  already wrote: Since some time Garmin is unifying the firmware for all of the current devices. And as far as we can see from changelogs, this also is the case for the subsystems.

    So, if it IS a software problem, maybe it started back then. And maybe some of the low level stuff in the algorithms was unified, but does not fit all models and all usecases.
    Who knows.

    As someone who works in software projects himself (but I am no developer) I can only say: Changing base libraries SHOULD not be a problem theoretically, but you often see strange effects in reality.