ANT Forum

Yes you can open multiple channels on a single device, and they can be a mix of master and slave channels. Please share code and/or the error you are seeing to help determine what your issue is.

There are also bidirectional channels, which support a response message from slave to master. However, it sounds like you want two separate channels for your use case.      

Bidirectional channel: You have to send the message to the radio before the rx for the channel period you want the message to go out. You can send 1 backchannel message per channel period.

Radio Rx A
Radio Tx B
Rx event C
Send backchannel message to radio D

ABCD ABCD ABCD

Note: Spacing between sets is much greater than set duration for normal channel periods and system latencies. You are using a very short channel period beyond what is normal for ANT, so this may not hold for your case. Your system latencies around communication with the radio may be causing the backchannel message to the radio to fall more than a channel period after the radio rx. Typical channel periods are 8192, or 4096 for most ANT+ profiles.

Radios can only operate on a single channel during the tx and rx window. If you have more than one channel, then you should choose the channel periods to match, so that the two channel periods are phase offset. Alternatively you can have them offset significantly, so that the two channel periods sweep across each other rapidly. When you choose two channel periods that are very close to one another, then the two channels can slowly drift across conflicts for the same airtime. The stack tries to resolve this issue, but is not always able to. You will get a channel collision event when the stack is unable to handle one of the channels.

When you are testing the bidirectional channel, do you have another channel established on your device, or another device in the vicinity with ANT (other than the device on the other side of the channel)? Just as two channels on a single device can fight over airtime, so too can multiple devices on the same channel parameters. The stack tries to detect other devices on the same channel parameters and shift the transmit and receive windows, but again is not always able to prevent interference.      

Since you are seeing every second channel period missing, and not sporadic issues, I suspect that you are trying to use a channel period higher than your system latency can support. Are you using an SOC solution, or a radio network processor separate from the processor you are setting up messages with? If the former, then you may need to increase the priority of ANT event handling, or shift unrelated processing to a lower priority. If you are using the latter, then you may need to switch to an SOC solution.      

You will want to send your reverse direction (backchannel) message to the radio in response to EVENT_RX. This is the event that you get every time a message is received by the slave. What I am pointing out is that the backchannel message will not actually get sent as a response to that received message, but as a response to the next received message. By the time you have received the EVENT_RX the radio has either replied with the backchannel message it had pending prior to receiving the message from the master, or has not sent a backchannel message because none was pending.

sd_ant_broadcast_message_tx is used for both the master and bidirectional slave. Acknowledged messages are also possible with sd_ant_acknowledge_message_tx, and burst messages with sd_ant_burst_handler_request.

If you want to send periodic data from what you have as ANT slave to ANT master, and the rate of commands is allowed to be lower than the periodic data rate, then you may want to swap which is master and which is slave. If the command rate is typically much lower than the periodic data rate then this is a much better approach. ANT works most efficiently when sending periodic data from the master to the slave. If the number of masters is small, then the slave can open up a channel for each master. If the number of masters is large, then a scanning slave should be used. The slave can send a command in response to each received message, but some will fail due to RF conditions. A slave that wishes to send a command to multiple masters must send a message to each master independently.

If you would need to implement a scanning slave, but the power consumption of scanning is too high, then a shared channel is an option. What would have been a scanning slave becomes a shared channel master. With shared channels the slaves are polled by the master. The master sends a message to the slave by address, and the slave can respond. This means that commands based on data received from the slave must wait until the next time that slave is polled. The master can send a message to all slaves (address 0), but they cannot respond in this case. See section 5.6 of the ANT Message Protocol and Usage document (https://www.thisisant.com/resources/ant-message-protocol-and-usage/). Note: This shared channels may not be more power efficient than a scanning channel if you have very short channel periods and don't send a new command each time data is polled. With the scanning channel the radio is spending a lot of time receiving. With the shared channel it is spending time sending and receiving. The power spent by the shared master sending is only useful if it is more than a simple polling command, and would have been similarly spent on backchannel messages from the scanning slave.

All that is required for shared channels is to set the channel type using CHANNEL_TYPE_SHARED_SLAVE or CHANNEL_TYPE_SHARED_MASTER from the nRF SDK, and for slaves to send a broadcast message to the radio to set the shared address. https://www.thisisant.com/resources/an07-auto-shared-channel-master-example/ has a PC based example. ANT Message protocol and Usage section 5.6 and 8.2 will be very useful.

Addresses of slaves on the shared channel are out of the scope of ANT. They are usually handled through a one time setup tool, or by discovering devices broadcasting as an ANT master and assigning them shared addresses and commanding them to join the shared channel over the channel they are a master on.