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

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.

Stefan said:

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.

Garmin-Sierra

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

bbrannon said:

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.

bbrannon said:

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).

Garmin-Sierra

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 .

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 Stefan 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.