Tigge / openant

ANT and ANT-FS Python Library
MIT License
174 stars 80 forks source link

Exception removing channel #0: Responded with error 21: CHANNEL_IN_WRONG_STATE #81

Closed hishizuka closed 1 year ago

hishizuka commented 1 year ago

Hi, thanks for developing such a good project.

Many of the repositories are updated and running the program, but I noticed one error.

I ran program examples/heart_rate.py and received several heartbeats and got the following error.

Traceback (most recent call last): File "/Users/abc/code/tmp/openant/examples/heart_rate.py", line 35, in main() File "/Users/abc/code/tmp/openant/examples/heart_rate.py", line 26, in main node.start() File "/usr/local/lib/python3.11/site-packages/openant/easy/node.py", line 217, in start self._main() File "/usr/local/lib/python3.11/site-packages/openant/easy/node.py", line 204, in _main self.channels[channel].on_broadcast_data(data) File "/usr/local/lib/python3.11/site-packages/openant/devices/common.py", line 334, in _on_data self.channel.open() File "/usr/local/lib/python3.11/site-packages/openant/easy/channel.py", line 88, in open return self.wait_for_response(Message.ID.OPEN_CHANNEL) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openant/easy/channel.py", line 69, in wait_for_response return wait_for_response( ^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openant/easy/filter.py", line 95, in wait_for_response return wait_for_message(match, process, queue, condition) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openant/easy/filter.py", line 49, in wait_for_message return process(message) ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openant/easy/filter.py", line 91, in process raise Exception( Exception: Responded with error 21: CHANNEL_IN_WRONG_STATE

In debug mode, extended mode is specified when assigning channels, Background Scanning is enabled, and Extended Messages is enabled.

DEBUG:openant.base.ant:Write data: [a4 04 42 00 00 00 01 e3] #Assign ch with extended(Background Scanning Enable) DEBUG:openant.base.ant:Write data: [a4 02 66 00 01 c1] #Enable Extended Messages

Aren't these unnecessary when connecting specific devices?

examples/raw_device_data.py, which does not contain these, operates normally. Maybe devices/common.py needs the following modifications.

def open_channel(self, extended=True, channel_type=None, ext_assign: Optional[int]=0x01): -> def open_channel(self, extended=False, channel_type=None, ext_assign=None):

tuna-f1sh commented 1 year ago

This looks like the channel didn't close during the assigning of the device_id once found: https://github.com/Tigge/openant/blob/master/openant/devices/common.py#L331 . I would have expected the exception waiting for that message however.

Having extended enabled by default isn't a problem if the device doesn't use extended, but does allow broadcast of this extra data for those that support it: https://github.com/Tigge/openant/blob/master/openant/devices/common.py#L320

I don't have time to look into this at the moment but thought just capture that.

hishizuka commented 1 year ago

Hi, thanks for your response.

I found the old version dongle causes this error. I use an AP2USB1.05 dongle.

The other hand, the GARMIN dongle AJK2.07RAF doesn't cause this error.

It is probably caused by differences in hardware capacities, but some people think that the old heart_rate_monitor.py, which has been replaced by heart_rate.py, no longer works, so I think that something needs to be done about it.

tuna-f1sh commented 1 year ago

It sounds like the non-Garmin/Dynastream one isn't confirming to the ANT specification. It might also be that it doesn't advertise support for extended but I would expect it to fail somewhere else in this case. You could check after initialising a Node with node.advanced_options_two.

The old example is still present (with a fix check for the correct BPM page), but as a raw usage example: https://github.com/Tigge/openant/blob/master/examples/raw_device_data.py

da4089 commented 2 months ago

FWIW, I'm seeing an identical exception.

On macos-11.7.10, with python-3.12, using pyusb-1.2.1.

I have a "Cycplus" ANT+ dongle, for which System Information.app reports:

ProdID 0x1008 VendorID 0x0fcf (Dynastream Innovations Inc.) Version 1.00 Serial Number 123

da4089 commented 2 months ago

And after some further investigation, it appears as if the key difference might be the USB ProdID: the "ANT USB2" dongles, distinctive because they can handle 3 network keys has a ProdID of 0x1008.

The "ANTUSB-m" dongles, which can handle 8 network keys, have a USB ProdID of 0x1009. This is the smaller-sized (newer) Garmin model, and (I guess) some clones. Note that both report their vendor as Dynastream (the company that developed ANT, and Garmin acquired).