ANT Forum

I'm a bit confused with the way you should call unassignChannel. My understanding for the documentation is closeChannel will close the channel but leave all of its settings intact, while unassignChannel will remove all the settings from the channel allowing you to use the channel again with new settings.

To me this means unassignChannel should always happen after you close the channel, correct? (well not that you have to but that you should never unassign first as the channel is still being used) So if I'm done with a channel should I close it, unassign it and then call dispose on it?

My other question is based on the code in the ant_net demo. The device response method seems to use CHANNEL_IN_WRONG_STATE_0x15 as an indicator that it should unassign the channel. Is this just an error check in that if I know I'm fully closing a channel I can unassign it right after closing and don't need to wait for the response to be able to unassign it?.

Thanks      

Your understanding is correct - you can unassign the channel after receiving a successful response to closing the channel (i.e., channel closed event). Since the ANT USB stick could be used by another application after the demo is done, it is recommended to make sure the channel is closed and unassigned, ready to be configured for something else. Also, since in a PC application you cannot be sure that the previous application that used the stick properly shut down all channels, it is a good idea to always start with a reset.

The channel in wrong state part in the demo code is for error handling. The implementation on the demo code is very simple, as the demo does not implement any complex channel management. A more robust way of doing it would be to request the ANT state after this, and take appropriate actions depending on this.      

Thanks for the response. Does this mean I should wait for the response to closing the channel before unassigning it? (i.e. can't call close and then unassign in a row without waiting for feedback from the device)

By start with a reset do you mean ResetSystem or ResetUSB on ANT_Device? Message protocol docs only mention ResetSystem so not sure how ResetUSB is different as it seems like the configuration is on the chipset in the USB device.

Does this mean that if you don't do a reset two .net apps could potentially run at the same time sharing the same USB stick? If so could a channel be shared between apps too? Say you have app 1 getting heart rate from a strap, then you launch app 2, could app 2 create an ANT_device object and an ANT_channel object based on the channel used in app 1 so both apps will get the same payloads from the ant strap. (I'm assuming no but thought I'd ask)
Thanks      

enki - 18 March 2013 10:47 AM

Thanks for the response. Does this mean I should wait for the response to closing the channel before unassigning it? (i.e. can't call close and then unassign in a row without waiting for feedback from the device)

Correct

enki - 18 March 2013 10:47 AM

By start with a reset do you mean ResetSystem or ResetUSB on ANT_Device? Message protocol docs only mention ResetSystem so not sure how ResetUSB is different as it seems like the configuration is on the chipset in the USB device.

ResetSystem, as what you care about is making sure that ANT returns to its default configuration, with all channels unassigned.

enki - 18 March 2013 10:47 AM

Does this mean that if you don't do a reset two .net apps could potentially run at the same time sharing the same USB stick? If so could a channel be shared between apps too? Say you have app 1 getting heart rate from a strap, then you launch app 2, could app 2 create an ANT_device object and an ANT_channel object based on the channel used in app 1 so both apps will get the same payloads from the ant strap. (I'm assuming no but thought I'd ask)
Thanks

No. It is not possible to have to applications sharing the USB Stick at the same time. What I was referring to is that there is the possibility that an application disconnects from the stick without closing the channel, leaving it in the wrong state to be used by another application that connects later on.