ANT+ heart strap failing to receive some packets in watch app

Isn't it cheaper to buy a new battery? The reported battery level is not very accurate and if you have used (or not used, just stored) this battery for years then it can be depleted.

I'd also add debug log: log everything from the message, not only the payload.

You could also try the same HRM with different device.

I use BLE to talk to the HRM-Pro and haven't seen this.  Could it be ANT specific?  In ANT mode the band also sends Runniing Dynamics - could that induce what you are seeing?  No RD with Ble.

I also thought about the RD, but that wouldn't be sent when you're connected as deviceType 120 IMHO. But that's one reason why I think the whole message should be logged for a few minutes and see exactly what happens before and after the disconnection

I forget where I saw it, but with the HRM-Pro and ANT you never want to have more than one device using it at a time,  

The HRM-Dual and new HRM 200 have both ANT and BLE, and no RD, so it might be worth trying one of them.

With ANT you don't really pair, so an unlimited number of devices can listen to the broadcastsed messages, I don't think the HRM would know how many listeners are there.

Not sure how to interpret this. When you connect in your code you use something like this:

deviceCfg = new Ant.DeviceConfig( {
    :deviceNumber => idSearch,                 //Wildcard our search
    :deviceType => rgDevType,
    :transmissionType => 0,
    :messagePeriod => rgDevPeriod,
    :radioFrequency => 57,              //Ant+ Frequency
    :searchTimeoutLowPriority => iTimeout,    //Timeout in 25s
    :searchThreshold => 0} );           //Pair to all transmitting sensors
GenericChannel.setDeviceConfig(deviceCfg);

but then as a listener you're bound to the device you connected to. So even if you have :deviceNumber set to 0 to connect any ANT device you're supposed to get only 1 device's messages.

Though in theory if you're running in a big marathon and pass many people it's possible you'll pass someone with a heart rate sensor that uses the same short ANT ID, but clearly this is not the case here.

It's even harder to contemplate an issue with 2 devices that have different deviceType.

I never heard about this problem, it never happened to me (which according to some interpretations in this forum mean the problem doesn't exist ;) , but you may be right.

Ask in the HRM-PRO device forum, as that's where I think I read about the conflict.

The Pro also handles 2 ble connects, but one can't be the device connected with ANT. and one is typically paired to the phone.  For FW updates to the pro and for times, the watch is out of play to collect info, like RD and steps.

I think I read the HRM 200 hands 3, including secure Ble.

> Isn't it cheaper to buy a new battery?

That's a good point, I could look into a buying a new battery but my programming fingers are itching for a potential quicker fix...

With heart straps and ant+ protocol being out for a while now, I have a feeling that this must have been an encountered problem somewhere by someone already. I feel like I might be reinventing the wheel. However, searching the web I am not finding much info - maybe I am not aware of the right keywords.

With the strap broadcasting live heart data, there is a natural inclination to see if one can process this data and display it live (my actual motivation behind this post). I found some previous explorations about this:

 - 2016: https://www.thisisant.com/forum/viewthread/6665: "trying to make a ... project that will tell you your heart rate and potentially flash an LED in time with your heart rate. I have a garmin heart rate monitor and an ant+ usb"

- 2014: https://bin.re/blog/track-your-heartrate-on-raspberry-pi-with-ant/#ZgotmplZ

Those two links (I'm sure there are others) deal with streaming the ant+ to computer so I am thinking of getting one of these ant+ dongles and trying to use some library like https://github.com/mvillalba/python-ant to see if on the computer I am still getting the same issue `Ant.MSG_CODE_EVENT_RX_FAIL`. If no issue on computer then it is a watch issue. For me this seems like the most fastest debugging approach because

• https://github.com/mvillalba/python-ant is a popular repository so they must have encountered with this issue so at least their code can handle/parse the data
• I can quickly debug/develop on the computer my motivation behind "With the strap broadcasting live heart data, there is a natural inclination to see if one can process this data and display it live"
  • I can even simulate my watch's packet drop rate on the computer to see if even with `Ant.MSG_CODE_EVENT_RX_FAIL` issues the live heart rate would still be acceptable for my use case.

> log everything from the message, not only the payload

I will look into this. I see from https://developer.garmin.com/connect-iq/api-docs/Toybox/Ant/Message.html that the rssi ( The Received Signal Strength Indication ) might help although in my experiment my watch and strap were always right beside each other. I might also look into what other bytes are encoded in the `Ant.MSG_CODE_EVENT_RX_FAIL` payload although I have no idea how to interpret them - I could at least make sure they are static with each `FAIL`.

> BLE/multiple device concern

My experiment design is just running one watch and one strap, isolated, at home. Strap is disconnected from all devices and just broadcasting.

I am curious about the BLE approach. However, I am not sure if I can connect my watch app to BLE heart strap - at least I am at a point where  I have already implemented a library and want to see if I can resolve the 1% drop rate issue first before implementing a BLE approach and perhaps encountering the exact same error.

BTW, have you seen this?

https://www.dcrainmaker.com/2025/01/the-begining-of-the-end-for-ant-wireless.html