235 Sensor Hub software (WHR) version 2.50

Am I missing something, or do we seem to have two different issues that people think are the same software bug? Group #1 seems to be the ones who have the original HR 66 bug that locks at that rate and does not change without a reboot. This could be a software, maybe hardware issue that it still occurring for some. Then we have Group #2, who see HR locks on random numbers for a hour or two at a time, but then will change HR value and stay at that number for another long stretch of time. This group would fall with most of us who are upset with the reduced sampling of HR. Reading some peoples comments, it looks like people from group #2 are confusing the crap sample rates with a complete lock like group #1 is seeing. That would lead me to believe more people are upset with reduced sampling like me and not seeing the HR lock like some others. Or maybe I'm wrong and need to go back to wishing for user controlled sample rates.

Am I missing something, or do we seem to have two different issues that people think are the same software bug? Group #1 seems to be the ones who have the original HR 66 bug that locks at that rate and does not change without a reboot. This could be a software, maybe hardware issue that it still occurring for some. Then we have Group #2, who see HR locks on random numbers for a hour or two at a time, but then will change HR value and stay at that number for another long stretch of time. This group would fall with most of us who are upset with the reduced sampling of HR. Reading some peoples comments, it looks like people from group #2 are confusing the crap sample rates with a complete lock like group #1 is seeing. That would lead me to believe more people are upset with reduced sampling like me and not seeing the HR lock like some others. Or maybe I'm wrong and need to go back to wishing for user controlled sample rates.

No, I think you're correct when you say people are talking about two issues here. I've been fortunate enough that I've never had my HR stuck at 66, or any number for that matter. I installed 2.41, then later 2.50, in the hopes I would have HR sampling like I did with WHR v. 2.20 and a fix for my HR stopping at 72 and gradually going to the correct reading. Neither version corrected this. I know people say that Garmin doesn't follow these forums, but I have a hard time believing someone at Garmin isn't looking. Even if it's out of a little pride to see what consumer's think of their product. What amazes me is even after the overwhelming amount of post about people wanting some kind of configurable HR sampling, nothing has been done. We all know the importance of a correct RHR. People are now turning on HR broadcasting at night just to achieve this. This is not a fix. It's an unnecessary workaround. This just proves people are willing to sacrifice some battery life to get correct readings. I think it would be naïve for Garmin to think prospective buyers of the upcoming Fenix 3 HR won't be following the VSHR and FR235 forums to see how the OHRM works before making their decision to buy. If they don't fix it here first, I believe the launch of the Fenix 3 HR is going to crash and burn.

No, I think you're correct when you say people are talking about two issues here. I've been fortunate enough that I've never had my HR stuck at 66, or any number for that matter. I installed 2.41, then later 2.50, in the hopes I would have HR sampling like I did with WHR v. 2.20 and a fix for my HR stopping at 72 and gradually going to the correct reading. Neither version corrected this. I know people say that Garmin doesn't follow these forums, but I have a hard time believing someone at Garmin isn't looking. Even if it's out of a little pride to see what consumer's think of their product. What amazes me is even after the overwhelming amount of post about people wanting some kind of configurable HR sampling, nothing has been done. We all know the importance of a correct RHR. People are now turning on HR broadcasting at night just to achieve this. This is not a fix. It's an unnecessary workaround. This just proves people are willing to sacrifice some battery life to get correct readings. I think it would be naïve for Garmin to think prospective buyers of the upcoming Fenix 3 HR won't be following the VSHR and FR235 forums to see how the OHRM works before making their decision to buy. If they don't fix it here first, I believe the launch of the Fenix 3 HR is going to crash and burn.

Part of the problem has been timing. Very little development is done for 1-3 weeks around Christmas (I don't know Garmin specifically, just the development in general). I'd expect to see more fixes/updates soon, though.

Same for me. I fall into #2 group. Never had the "66" issue, but I used to have the #2 issue when it locks at a random number. The #2 issue can be fixed by clearing android cache out. So the issue #2 is more likely an issue of the sync process, it's likely the app issue...

Same for me. I fall into #2 group. Never had the "66" issue, but I used to have the #2 issue when it locks at a random number. The #2 issue can be fixed by clearing android cache out. So the issue #2 is more likely an issue of the sync process, it's likely the app issue...

Are you referring to the android cache on your phone, or is there one placed on the watch when they're paired together?

Am I missing something, or do we seem to have two different issues that people think are the same software bug? Group #1 seems to be the ones who have the original HR 66 bug that locks at that rate and does not change without a reboot. This could be a software, maybe hardware issue that it still occurring for some. Then we have Group #2, who see HR locks on random numbers for a hour or two at a time, but then will change HR value and stay at that number for another long stretch of time. This group would fall with most of us who are upset with the reduced sampling of HR. Reading some peoples comments, it looks like people from group #2 are confusing the crap sample rates with a complete lock like group #1 is seeing. That would lead me to believe more people are upset with reduced sampling like me and not seeing the HR lock like some others. Or maybe I'm wrong and need to go back to wishing for user controlled sample rates.

Sorry, that may be partly my fault.

I've had 66 lock, and I guess what I was trying to say was that it's not exclusive to 66.

The FW upgrade doesn't specify 66, but says a fixed value so was thinking it may be a wider issue, and that this fix may solve some of the HRM sampling issues which aggrieve me no end.

Perhaps it was just wishful thinking on my part :o

Update

My 235 showed an update this AM as I started my swim. It updated. Since then, my time was off by like 30 minutes. Then later I noticed my HR sticking at 66. The lights are on, but nothing changes. I have version 3.30. I am reading about this version 2.50 for the HR hub? How do I check that? Garmin Express shows I am up to date. Any help appreciated..

My 235 showed an update this AM as I started my swim. It updated. Since then, my time was off by like 30 minutes. Then later I noticed my HR sticking at 66. The lights are on, but nothing changes. I have version 3.30. I am reading about this version 2.50 for the HR hub? How do I check that? Garmin Express shows I am up to date. Any help appreciated..

Open an activity, go to menu, settings, system, then about. Scroll through that and it will show you what WHR you currently are on. If you are on 2.50, maybe you just need to reset your watch to bring everything back to normal.

Just updated to 2.50. I was previously on 2.41. This is the first time since I had this watch that the heart rate didn't go up to 71 or 72 then back down again when I accessed the HR widget. I'll be interested to see how it performs during runs. Is this update different to 2.41? Because even on 2.41 my watch would show HR as 71 or 72 when I accessed the widget and the slowly drift back down to my real HR. Have we turned a corner? Anyway, I know its early days yet, but I just thought the change the immediate change was interesting.