Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Limitations on channel period and number of channels

Rank

Total Posts: 4

Joined 2018-01-03

PM

I'm a new developer with ANT, and I'm evaluating the capability of the protocol for a control application. I'm using the D52 starter kit (nRF52832) and soft device S212 V14.2.0.

For my application, I need 13 channels with a message rate of 60 hz each (channel period of 546/32768 [s]).

I read through the protocol manual and understand that this message rate is aggressive, since 4 hz is recommended, but I would like to understand the limitations so that I can adjust my control algorithm.

Experimenting with the multi-channel example, I was able to achieve these results, at a single RF frequency:

Message Rate (hz): 4 - 8 - 60 - 120
Max # of Channels: 15 - 10 - 2 - 1

Also, I found in the FAQ, that 300 channels are achievable at 1 hz message rate. (https://www.thisisant.com/developer/resources/tech-faq/how-many-ant-nodes-can-exist-in-proximity-to-each-other-1/). All else equal, I would infer that 300 standard packets can fit in a second. That would translate to 5 channels at 60 Hz message rate. I would also think that I could use 3 carrier frequencies to achieve 15 channels at 60 Hz.

However, the results I have show only 2 channels at 60 Hz rather than 5. Furthermore, when I try to open channels spread across different RF frequencies, my results are the same!

Because of these two results (1- carrier frequency not helping, 2- not achieving 300 packets/second), I'm wondering if I am running into the limits of the microprocessor rather than the limits of the protocol.

Are there any other explanations as to why the use of different carrier frequencies for each channel does not increase my success rate, other than running into the limits of the microprocessor?

Thanks and please forgive me if I have used incorrect terminology.
     
Rank

Total Posts: 4

Joined 2018-01-03

PM

Update:

I think the reason that I am not getting better performance by adding additional carrier frequencies is due to the use of a single radio (transmitter/receiver) on the microcontroller. As far as I understand, the radio cannot transmit/receive multiple packets at once, so there is no benefit of different carrier frequencies, as long as a single radio is used. In fact, I’m getting slightly worse performance using multiple frequencies. Maybe there is a delay in the radio when tuning to different carrier frequencies.

However, I was able to increase from 2 channels up to 8 channels (though it’s not always stable) at 60 Hz by removing a bottleneck that I’ve found. It seems that it takes longer for a device to transmit than to receive.

I’ve found that a device is able to transmit at 60 Hz for up to 3 channels. With the three nodes that I have, I have set each to transmit at 3 channels and receive at the other 6 channels. I’ve been able to get 8 of the 9 channels working at once, although I can’t always repeat it. I'm wondering if others have found any similar results.      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Correct, as the device only has a single radio, it does not matter if you use additional carrier frequencies. In fact with multiple carrier frequencies, the SoftDevice has more work to do to coordinate radio time access between the channels.

If you don't require bi-directional communication or the time-adaptive coexistence of ANT (cooperation between multiple nodes broadcasting on the same carrier frequency to reduce interference) then you could configure the channels as transmit-only. Most of the limitations on radio-time are due to receive windows rather than transmit time.      
Rank

Total Posts: 4

Joined 2018-01-03

PM

Thanks for the reply. Taking your suggestion of trying transmit-only channels, I was able to get about double the number of successful transmissions/second.

My application requires time synchronization, and I have a couple questions on the built in time sync function regarding speed and payload.

As I understand, the time sync data packet is 8 bytes where 1 byte is for data validation, 2 are for the counter, and 5 are for the data payload. Additionally, the time sync channel is a bidirectional channel. My question is whether I can alter any of these parameters of the time sync function.

Ideally, I would like to modify the function to be transmit-only in order to achieve a higher message rate. I'm a little confused as to why the function is configured as bidirectional in the first place, since space is not allocated in the packet for an address so a slave is unable to reply. Does the time sync function support only individual and not shared channels as well?

In addition, I would like to increase the data payload to 7 bytes by eliminating the page validation and by using a single byte counter - since my events are close enough in time that I don't need a 2 byte counter.

The time sync documentation was very helpful in understanding the basics of the function, but I'm hoping to gain some understanding on whether there is any flexibility. Hopefully there are options without modifying the function, but I would also like to know if it is possible to modify the function myself.

Thanks!      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

The time sync function only modifies the payload format of the packet, everything else remains the same as standard ANT channel behaviour. The time-sync packet format is fixed at this time, so you'll need to work around the payload. What kind of use case are you looking for?

Regarding bi-directional communication, even if you won't be receiving packets in the reverse direction, the adaptive coexistence behavior of ANT channels is tied to the channel type, so transmit-only channels will not enable ANT's coexistence mechanism (which allows many broadcast channels to coexist on the same RF frequency + network).