ANT Forum

Hi,

My app needs to transfer significant amount of data over ANT Burst mode from one Android phone to another. I have 1000 bytes to transfer every second. Important requirement is to ensure data integrity.

Transmitter phone A: Samsung S3 with Garmin USB stick.
Receiver phone B: Samsung S4 with Garmin USB stick.
Receiver phone C: Sony Xperia S with embedded ANT support.


So far I've tried to organize data in two ways:
1. 60 bytes pages; assumed to be sent 17 times a second
2. 600 bytes pages; assumed to be sent roughly twice in three seconds.

Channel configuration: mAntChannel.assign(ChannelType.BIDIRECTIONAL_SLAVE);
mAntChannel.setPeriod(1927); // 17Hz needed for 30bytes pages -> 32768/17= 1927
mAntChannel.setRfFrequency(77);
mChannelId = new ChannelId(111, 0x08, 1); //111 and 0x08 are temp values
mAntChannel.setChannelId(mChannelId);
mAntChannel.setSearchTimeout(LowPrioritySearchTimeout.TWENTY_FIVE_SECONDS);

Transmitting routine:
I. Obtain channel with AntChannelProvider.acquireChannel
II. Transmit page with mAntChannel.burstTransfer(byte [] page)
III. Wait for TRANSFER_TX_COMPLETED before sending another page

Not very happy with results.
Observation 1:
1. Periodically TRANSFER_TX_COMPLETED is not coming back for 20-40-60seconds so a lot of unsent pages accumulated
2. Later on, channel “wakes up” and “eats” a lots of data but then sleep again.
3. With phone C, channel seems behaving much slower and never catches up to speed.

Questions:
- How to prevent channel from sleeping or in other words reach needed performance?
- Any other burst modes I can use or switch to?
- Is there a way to ensure integrity of data? Is ANT channel designed to transfer 1000 bytes a second in a long-running sessions up to 20 hours?
- Am I missing anything in implementation? Please advise









     

Can you please advise what is corresponding API for
ANT_ConfigAdvancedBurst(
ANT_SendAdvancedBurstDataPacket(
in Android SDK?      

Hi,

I just have some additional questions:

Are you using the latest ANT SDK? (version 4.2 at the time writing).

Are you bursting simultaneously to 2 phones or just 1?
ANT bursts should only be done to from 1 device to another at a time.

What is the behavior you're seeing when the channel "sleeps"? Does it take a few seconds before suddenly a number of messages arrive?

Are you seeing TRANSFER_TX_FAILED channel events or AntCommandFailedException's?
These indicate burst transfers should be retried.

Also, rather than queuing off of TRANSFER_TX_COMPLETED, you could also queue off of EVENT_TX, which indicates a new transmission "window" is open for you to send on as well.

Are Bluetooth/WiFi enabled and/or heavily active during your attempts to send burst data?
ANT, particularly on the Xperia phone, must coexist with BT and WiFi so some interruptions can occur.

Is the system utilization staying low when you send/receive bursts?
Bursts are handled asynchronously at the chip level and will always succeed or fail. But they can outpace the host Android system's ability to handle the messages which will cause them to be buffered before they are received by the app.

1000 bytes/s is not an aggressive target for an ANT non-advanced burst and should frequently achieve 20kbps in a favorable RF environment, even under long durations of usage. This can be seen on a PC using ANTware II or an embedded platform.

Unfortunately at this time advanced burst mode is not exposed by the Android ANT SDK but will be added in a future release.

Best regards      

Hi Harrison,

Thanks for information.

Let me answer questions first:
ANT SDK version is 4.2. We bursting to 1 phone, not 2.
System Utilisation is running low; however we understand we will need to test with high utilisation to ensure its still stable.

In regards to Bluetooth and WiFi we're following FrequencyAgility document and setting mAntChannel.configureFrequencyAgility(3, 39, 75). As I understand its to avoid WiFi interactions only; any additional recommendations to avoid Bluetooth?

Yes we've added TRANSFER_TX_FAILED and TRANSFER_RX_FAILED handling which we missed previously - thanks for an advise. Problem we're seeing now is TX_FAILURE happening on transmitter unit but RX_FAILED not _always_ happening on receiver unit. Is it normal situation? I presume only possible solution is to assign ID /timestamp to portions of data being transmitted? Any other good practices?

Thanks again for your support,
Alexey.      

Hi Alexey,

Your example code shows you are trying to send as a slave, so the burst will only start when a packet is received from the master. If there is any reason a packet is not received (interference, out of range, channel collision etc.), the burst start will be delayed until a packet is received.

You should only wait for TRANSFER_TX_COMPLETED/TRANSFER_TX_FAILED after receiving a TRANSFER_TX_START, as there could be a reason the burst never began (ie. TRANSFER_IN_PROGRESS). To simplify things in Android, you can use the onBurstStateChanged() event and check the status of the BurstState object you are provided. This will also include bursts in progress on channels in use by other apps (only one channel can burst at a time). You should also be checking the max burst size value in BurstState. Currently this is much higher than your case requires, but it may change with future versions of the ANT Radio Service and how other channels on the ANT adapter are configured. The Creating ANT Android Applications document in the ANT Android SDK explains this.

When you ask about the channel “sleeping”, are you not seeing RF events for the data that is being received from the master (eg. Rx data messages, Rx fail events, etc) at the expected message period?

It is tricky to say what throughput your implementation should expect. A standard (non-advanced) burst can perform at 20kbps (interference could impact this), but your implementation has a built-in “dead time” between bursts. Your maximum throughput is dependent on the channel period of your master, and the size of each burst, but is greatly impacted by any interference to the packets from the master and the burst buffer being “primed” with data before that packet is received. A 17Hz connection, with 60 byte bursts is a maximum of 1020 byes/second you will only see in an ideal RF environment. A burst transfer does include built-in retries, so once it has started external factors will have less of an impact (while your total throughput will stay about the same).

Advanced burst should not be needed for your case (with low throughput requirements), allowing you to support all current phones/USB sticks. This feature is not currently supported by the ANT Android API.

Frequency agility will help with external interference, but not with internal sharing of the radio. On the phone with built-in ANT there is only one radio being used for all wireless, so you may see some contention when trying to burst large amounts of data and do high-priority voice streaming over Bluetooth at the same time.

The master will transmit something on every message period, which will be broadcast data if no Ack or Burst data has been requested. The slave will use this to synchronise it’s channel to. So, you should be checking if (old) data is arriving as broadcast. The slave unit will get a RX_FAILED (not TRANSFER_RX_FAILED) if nothing is received. I would suggest logging all received ANT packets to see what is going on. The toString() method of each message class will output the data in a more human readable format than the raw message.

Cheers,
-Rohan      

Thanks Rohan, we've progressed further with advises given. So far we're able to reliably transfer 600 bytes a sec (and it seems we can reliably transfer much more but 600 is enough for now) for 8+hours runs and working to handle channel dying situations. Appreciate if you can help with few another questions.

1. Does it seems okay if AntSupportChecker.hasAntFeature(.....) returns true but AntService.bindService(.....) returns false? I am 99% sure it's particular device problem as all others works fine - but is there any way to programmatically check for reason? All quiet in Logcat.

2. On a long running scenarios:
- two devices paired and bursting from Tx to Rx
- then Tx disappears
- Rx waits for Tx and eventually gets RX_FAIL_GO_TO_SEARCH
- if Tx wakes up at this moment - it supposed to be fine but all bursts failed.
Question is: how Search mode after RX_FAIL_GO_TO_SEARCH different from Search lets say when Channel just opened? Should we just reopen channel after RX_FAIL_GO_TO_SEARCH?

3. in some cases after channel dead and attempt to reopen we see
mAntChannelProvider.getNumChannelsAvailable() returns 0;
and mAntChannel.open() throws NO_ADAPTER_EXIST
After some period of time ChannelProviderStateChangedReceiver is called and amount of channels seems be normal - which seems as whole adapter reboots. Can you advise possible reasons or things-to-avoid?

Thanks,
Alexey.      

Great news.

1. The hasAntFeature() check is for "hardware" support; is there a built-in chip or a service which supports external chips installed. It is unrelated to if the ANT Radio Service is installed or not, and an attempt at AntService.bindService() can be used for this purpose.

2. After a channel has dropped to search from repeated Rx Fail, it will search in the same way as when the channel was just opened. If there is a search timeout, the channel will close and you will need to reopen the channel to continue searching.
Note that if you were waiting for an Acknowledged message to send and GO_TO_SEARCH occurs, you will get a Channel Death and need to acquire another channel. This is how we forcibly unassign the channel, to ensure you do not see a known issue on some ANT hardware where you would get stuck in "Transfer In Progress" state forever.

3. This is due to the current (incorrect) behavior of the ANT Radio Service. When the last channel on an ANT adapter is released, the ANT Radio Service will Reset the adapter, and you must wait for it to re-initialise before any channels are available. I assume when you say "open" (AntChannel.open()), you mean "acquire" (AntChannelProvider.acquireChannel()).
When you say "after channel dead", do you mean you have seen a Channel Death event (most likely due to the case described in 2. above)? If you have not, you can continue to re-use the AntChannel you have (open it again), without releasing and acquiring a new AntChannel.