ANT Forum

I understand that an Ant module will generate a EVENT_RX_FAIL_GO_TO_SEARCH message if too many messages are missed. My questions are:
1. How many is "too many"?
2. Is there a way to change this value?

Thanks.      

Hi,

You can find the answer to your question in the AN11 ANT Channel Search and Background Scanning Channel application note:

After multiple, consecutive missed messages the slave device will drop back into search mode. If the message rate is slower than 2 Hz, the slave will go to search mode after four missed messages; for message rates faster than 2Hz, the slave will drop back into search after two seconds worth of missed messages.

There is no way to change this value, but a search should not take long depending on the channel period and if the slave part(s) support high duty search or if using a continuous scan mode where slave timing is asynchronous.

Cheers      

Thank you Harrison - this is very helpful.      

Your welcome, is there a particular problem you are attempting to solve which may require this type of functionality? Just in case we can offer a solution if you need one.      

Currently I am baselining the RF reliability of a prototype. I wrote both the firmware and software ends of the system. I think I tracked down most of the little "bombs" I left in my code and the reliability has improved. Right now I can see from the RF log on the master side that when a data download fails, most often the slave has stopped responding to the master's data request (the master makes numerous requests during a single communication session and the master repeats a particular request a certain number of times if there has been no response from the slave). This behavior made me wonder if the slave had got a "RX FAILED GO TO SEARCH" message from its ANT module and just stopped listening. (The firmware is configured to shut down RF when this message is received from the ANT module.)

If there was a way to configure the number of missed messages before getting the "RX FAILED GO TO SEARCH" message I would try to change it to see if that had an effect.

I am using 0.25 s message rate. Based on the AN, I am assuming that I would have to miss 4 messages in a row and not 4 messages total before getting the "RX FAILED GO TO SEARCH" message.      

Hi,

Drops to search are a normal part of ANT operation due to RF interference, crystal drift, component tolerance, etc and should be expected with a certain amount of frequency.

At 0.25s or 4 Hz, you would have to miss 8 messages (2 seconds) in a row before it automatically drops to search.

Cheers      

Thanks Harrison. I mixed up my message frequency and period. Yes, 2 s makes sense I have verified that on my system.

I guess this goes to a more general question about range and reliability. I am using an ANT USB2 dongle on the master side of my system and a CC257x on my slave side. I am using broadcast messages to send data requests from my master to the slave and burst messages from the slave back to the master. The time to complete a burst is much less than my message period.

My bigger question is this: what is the best way to validate the range and reliability of my system? Right now I am setting the master and slave 3 - 5 m apart (line of sight) and sending 3 - 4 dozen burst messages from the slave to the master over the course of about 30 s. I have max tx power set on both ends. I know the reliability will depend on a lot of factors, but in a generally ideal case, is it realistic to expect 100% success? Right now I am getting about 90% success. (I am doing these downloads back to back: download a set of data, shut down RF for a few seconds, download a set of data, shutdown RF for a few seconds, etc.)

From what I have seen the USB2 dongles are spec'd at 5 - 10 m (but I also saw one datasheet that said just 5 m) so it does not seem as though distance is a limiting factor. I have seen some users state that they get 30 m but I am not sure if they are transferring real data or just using the broadcast "pings" from one ANT dongle to another.

Thanks.      

Hi,

A 100% success rate should never be expected over a wireless link due to the aforementioned issues regarding drops to search. I would consider 90% to be quite good for a connection doing a large number of bursts and not maintaining the broadcast channel timing by shutting off the RF. As noted in the Burst Transfers application note, bursts can cause channels to lose their normal timing, as burst messages override the typical coexistence scheme which channels only using broadcast/acknowledged messages use.

You must test your range/reliability under the same circumstances your use case will use the connection. The amount of range/reliability required by your system is dependent on your use case and the final design of the devices on both ends of the link.

For a broadcast only case I would expect somewhere in-between 95-99.9% in a virtually perfect wireless environment. Most ANT+ device profiles only use broadcast messages to transmit data, and use data format techniques such as accumulated fields to help address unseen/lost packets at the slave ends of the link. ANT-FS has techniques defined to recover from partial bursts, as bursts not finishing 100% of the time is to be expected.

Certain devices such as USBm sticks have a high duty search feature which could greatly minimize the time it takes an ANT channel to be found again.

Best regards      

Harrison,

This is very helpful for understanding what is happening in my system. I knew that the normal timing gets corrupted by burst transfers but I hoped that since the transfers I was doing were taking much less than the message period that I was not introducing too much distortion.

Early on in my testing I could see in my RF log on the master side that I was "stomping" on some of my messages so I inserted a delay between the non-ping broadcast messages that I sent from the master. Do you think I can correct for some of the timing distortion by allowing a longer period of time in between bursts in which I allow the master to simply "ping" the slave?

Thanks.

Harrison - 22 July 2013 04:57 PM

Hi,

A 100% success rate should never be expected over a wireless link due to the aforementioned issues regarding drops to search. I would consider 90% to be quite good for a connection doing a large number of bursts and not maintaining the broadcast channel timing by shutting off the RF. As noted in the Burst Transfers application note, bursts can cause channels to lose their normal timing, as burst messages override the typical coexistence scheme which channels only using broadcast/acknowledged messages use.

You must test your range/reliability under the same circumstances your use case will use the connection. The amount of range/reliability required by your system is dependent on your use case and the final design of the devices on both ends of the link.

For a broadcast only case I would expect somewhere in-between 95-99.9% in a virtually perfect wireless environment. Most ANT+ device profiles only use broadcast messages to transmit data, and use data format techniques such as accumulated fields to help address unseen/lost packets at the slave ends of the link. ANT-FS has techniques defined to recover from partial bursts, as bursts not finishing 100% of the time is to be expected.

Certain devices such as USBm sticks have a high duty search feature which could greatly minimize the time it takes an ANT channel to be found again.

Best regards

     

The ideal case to minimize timing issues (but can affect overall transfer bandwidth) while bursting is to issue bursts on each broadcast message, and with the burst being shorter than the channel period, you can check this by enabling extended messages with timestamps enabled.

If you do require a significant level of burst control, speed, and/or functionality, I would consider looking at any ANT devices such as USBm which feature advanced bursting. Advanced bursting allows you to burst at up to 60kbps using 24 byte packets (up from 20 kbps on earlier parts), allows you to adjust the retry behavior on burst packets, and enable per packet frequency hopping (to minimize potential single channel RF interference).