ANT Forum

Just started playing with the demo today and had a few newbie questions:

- Seems like the dChannelResponseHandler handler always happens on one thread, so if a handler takes too long to execute you'll lose ant+ pages as the next message to be received is the one that gets received after the handler is done executing, As these are always done on the same thread then we never need to worry about receiving the data in the wrong order or making sure we finish processing one set of data before the next comes in. Correct?

- The demo doesn't seem to demo shutting down but going by my understanding of the wrapper there is no way to shutdown just a channel. For example you are done with that data so keep it from notifying of data being sent and clear up the channel for something else. Seems like you can only do a shutdown at the device level which will turn off all channels too. Correct?

- pairing doesn't seem to be part of the demo. My assumption is you set USER_ANT_CHANNEL and USER_DEVICENUM to 0 so it will pair to the first device it finds at that frequency and of the device type you have set. Then you do whatever logic you want to make sure that the device is the one you really want, maybe wait for the page with the device serial number if you want to prompt the user. (is there a set protocol for this?) Then you do the stuff after the comment "Request channel ID" to save the settings for that device to use later? Why is Transmission Type part of that as I thought you would know that from the device profile of the device you are trying to connect to.

- What is the USER_NETWORK_NUM used for?

Thanks for putting up with my newbie questions.      

I think I understand the threading part as it appears like a thread is created in the Ant_managed_library that polls the unmanaged code so everything will happen on that thread. I'm guessing ANT_GetMessage will just get the last message received so any message that that method hasn't been called on will get dropped, correct?

Why does the managed wrapper poll like that when it seems like there is a function callback in the unmanaged code so polling isn't required when waiting for the next message? (I'm not sure I understand the c++ side of the code that well but seems to be ANT_AssignChannelEventFunction)

Thanks      

Seems you have figured out how the threading works - that is correct, there is a background thread polling for messages from ANT, so if you subscribe to the device/channel events, the event handlers will run in the background thread. Internally, when reading from the serial port, messages are queued, not dropped. The callback (ANT_AssignChannelEventFunction) is only used in the ANT DLL code, not in the managed library (ANT_NET), which uses a slightly different code base that allows for example connecting to multiple sticks on the same application.

On your other questions

- To "shutdown" activity on a channel, you need to close it.

- Your understanding on how to implement pairing is correct. You do need to save the transmission type as well. The upper portion of the transmission type may be used to extend the device number. Please refer to the ANT Message Protocol and Usage document (Document tab in the Downloads area) for more details.
http://www.thisisant.com/developer/resources/downloads/
http://www.thisisant.com/developer/resources/tech-faq/category/pairing/

- USER_NETWORK_NUM is used for the network number. More details on the network number/key are available in the ANT Message Protocol and Usage document, as well as the FAQ
http://www.thisisant.com/developer/resources/tech-faq/category/network-keys/
     

Thanks. A followup to the threading part. In the demo_net project if I do a thread.sleep in the ChannelResponse method (i.e. fake doing something more massive in the event handler for new channel messages) it appears as though packets do get lost as the next time the event fires it seems to skip some packets. So just need to make sure the event handler for channelResponse is fast.

Does the callback function not work with multiple sticks? Seems like a callback that dumps the data into a thread safe queue internal to the .net wrapper would be more useful as that way no data would be lost. I have a blocking thread safe queue object I could donate if interested, by blocking I mean if the queue is empty and a thread tries to get the next object off it it will block the request until another thread adds something to the queue. (requesting thread goes to sleep and will wake when there is something to get)      

The base C++ library that implements most of the ANT functionality does not have a message thread or callbacks directly usable by applications, this is implemented directly in the DLL, along with the callback functions; and in the managed library, along with device/channel events. The functionality of the callback functions and the managed library events is pretty much equivalent.      

Sort of separate issue but based on the Ant_demo code:

The demo code calls device0.enableRxExtendedMessages(true); after the channel is opened, but AN16 for RSSI under section 4.1 seems to imply you need to set that before opening a channel so I'm a bit confused.

Thanks      

Extended messages can be enabled at any time. However, doing it before opening the channel ensures that all received messages contain this information. The reason it is done after opening the channel in the demo is because the demo is intended to run with any ANT module, including parts that do not support extended messaging (i.e., if the command to enable extended messages fails, it will not break the flow of the program).

A good way of trying the effects of different commands and the sequence is to use ANTware to try out the commands.

     

I just assumed there was a reason AN16 said extended messaging must be enabled prior to opening the channel that playing with the sample code and the simulator may not expose.

As to the command to enable extended messages breaking the flow of the app I thought the only thing that happens if you enable it when it isn't supported is the DeviceResponse handler method writes out "Extended messages not supported in this ANT product" so it would seem like code could easily handle that situation. So enabling it when you don't need it doesn't really do any harm at least on a full computer (guessing this could cause more power draw or cpu use which on a lower power device could be significant but on a full computer would be trivial)

Thanks for all the help.      

The reason it breaks the flow of the program is that it relies on a RESPONSE_NO_ERROR from each configured command to move on to the next, and you would not get a RESPONSE_NO_ERROR if configuring extended messages in a part that does not support them. Of course, there are ways to deal with this more cleanly, but our goal was to keep the demo code as simple as possible.      

dChannelResponseHandler Thread: You're correct that the dChannelResponseHandler handler is executed on the same thread for each channel. This can lead to potential issues if a handler takes too long to execute and causes delays in processing subsequent messages. While the messages are typically received in the correct order, it's important to process them efficiently to avoid blocking the thread and potentially missing messages. The order of processing is maintained within each channel, but across different channels, messages might be processed concurrently.

Shutting Down Channels: In the ANT+ API, you're right that there isn't a direct way to shut down an individual channel without shutting down the entire device. The device-level shutdown will affect all channels. To manage channels more granularly, you might need to implement logic to ignore or handle data from specific channels if they're no longer needed, rather than shutting them down completely.
Dave The Diver