Tech FAQ

The node receiving the burst transfer does not need to keep track of the sequence numbers of the burst packets, as these are verified by ANT.  Note that this assumes that there are no missed data messages on the serial port.  Since the host controller has no ability to flow control data received from the ANT device when using asynchronous serial communication, care must be taken to ensure that serial packets are not missed.

This is normal. Burst packets are synchronized off each other. If bursting for a prolonged period of time, clock errors may cause the regular channel periods to drift off, losing synchronization. Hence, once the burst is finished the channels may no longer be synchronized and the slave will fall into search.

Even though the sequence number has been correctly generated by the host processor it is still possible to receive a TRANSFER_SEQUENCE_NUMBER_ERROR event in some scenarios.

One possible cause is latency to handle the EVENT_TRANSFER_TX_FAILED event.  When a burst transfer fails, an EVENT_TRANSFER_TX_FAILED is sent to the Host MCU. At this point, ANT expects the host MCU to stop sending any further burst packets corresponding to the current transfer, and instead, begin a new burst transfer. If the host MCU experiences delays processing this event and continues with the burst, a TRANSFER_SEQUENCE_NUMBER_ERROR will be generated by ANT for each burst packet sent where the sequence number does not correspond to the beginning of a new burst, as shown in the figure below.  This scenario is not unusual on PC or mobile applications, as the operating system does not offer any timeliness guarantees; it is safe to ignore the TRANSFER_SEQUENCE_NUMBER_ERROR in this case.

Another possible cause is overrun of the burst buffer due to problems with the flow control implementation. Due to limited resources on the ANT baseband processor, there is buffer space for only 2 or 9 packets of data, depending on the ANT solution used. Once its buffer space is full, ANT will assert its flow control signal indicating that no more messages should be sent. Any burst packets sent while the flow control line is asserted will be ignored by ANT, causing a mismatch in subsequent sequent numbers, and the eventual failure of the burst, as shown in the figure below.  To avoid this situation, ensure that the host processor observes flow control properly on the serial port.  Adding 0-pad bytes at the end of each message can help in the case the host has some latency to act upon the flow control signal.

In any case, a more precise diagnostic of the cause of this error requires looking at serial messaging between ANT and the host MCU, as well as the flow control signals.

Bursting uses the entire resources of the radio. A burst will pre-empt any other channel causing that channel to miss packets.

20kbps is the maximum achievable data rate. This number assumes that the serial port is fast enough to keep up with the burst and that no messages are lost or retried during the burst.

There is no limit as to how long a burst can last. However, as a burst uses the entire resources of the radio and preempts any other channels, care should be taken that other channels are not starved for too long. Also, prolonged bursting can affect other 2.4GHz devices in the area, including other ANT devices. Prolonged bursting can also deplete the battery rapidly.

Every independent ANT node can only handle a single burst at a time; therefore it is not possible to do a simultaneous burst from multiple channels and devices, to a single ANT node. Simultaneous bursting between two pairs of independent devices is possible; however, it is recommended that the devices burst at different RF frequencies, to ensure they do not interfere with each other.

Due to limited resources on the ANT baseband processor, there is buffer space for only 2 packets of data on AP1 and AT3, and 9 packets of data on AP2 and CC257x. The buffer space is not emptied until the messages are actually sent over the air, which does not happen until the next channel period (see figure below). Hence, if more than two (or 9) packets are sent before space in the buffer has been freed, the extra packets will be lost and the burst will fail.

It is important to note that once its buffer space is full, ANT will assert its flow control signal (RTS/SEN), indicating that no more messages should be sent. The host processor must properly interpret and handle this signal and only send burst packets when the flow control indicates it is safe to do so. The figure shows an example of this: the ANT flow control signal will be set high after the maximum number of packets that ANT can buffer has been sent. The host must not send any data to ANT while this signal is high. The flow control signal is deasserted once the burst packets start to be sent over the air.

Once a burst transfer begins to be transmitted over the air, ANT will send the buffered burst packets.  If the buffer is emptied before the burst transfer has completed, and no new data is provided in a timely manner, the burst transfer will fail. This may happen either due to a slow serial port (i.e. baud rate < 19200bps) or because of other operations in the host controller taking precedence and disrupting the burst timing.

Bursting uses all of the resources of the ANT radio. The burst will preempt any other channels on the radio, possibly resulting in packet loss. This will happen if the burst is long enough to overlap the time slot of another channel.

No, bursting may only happen on one channel at a time. Once a burst is complete, bursting on another channel can commence.

When resuming a burst it is important to consider the ambiguity of what burst packets were actually received on the other end of the link. To do this, it is recommended that a sequence number be implemented as part of the data payload of each burst packet. The sequence number can be used by the receiving side to decide whether it should accept or ignore data after a burst is resumed. Consider the following situation:

After the packet with Seq 3 fails, the transmitting side re-tries the burst at packet Seq 3. Since the receiving side has already received this packet, it will discard it, ensuring that any state driven behavior is correctly handled. Please note that the sequence number discussed in this answer is not identical to the sequence number required by the ANT protocol for each burst packet.

An alternative solution, used by ANT-FS, is to introduce handshaking so that the end point receiving the burst can indicate how much of the data it actually received.  ANT-FS, a wireless transport mechanism that can be implemented on top of the ANT protocol, provides a robust framework for transferring files between two devices. For more details on ANT-FS, refer to the “ANT File Share (ANT-FS) Technical Specification”.

Single packet bursts are handled identically to Acknowledged messages and are not retried. Multi-packet bursts are retried up to 5 times before failing.

Each burst packet is sent as an acknowledged message and is automatically retried up to five times.  When transmission of a packet (including retries) fails, the burst transfer will fail.  No packets are skipped.

On the device that is sending the burst, after a burst has finished, an event message will be sent to the host MCU. If the event message is EVENT_TRANSFER_TX_COMPLETED, then the burst was successful. If the event is EVENT_TRANSFER_TX_FAILED, then the burst was not successful. The host MCU should wait until it receives one of these event messages before trying to communicate further.

On the device that receives the burst, successful completion of a burst transfer is indicated by receiving the last packet of the burst (a burst packet with a sequence number with the most significant bit set). If the burst was not successful, an event message EVENT_TRANSFER_RX_FAILED will be sent to the host MCU.

Burst packets are retried 5 times before the burst fails. This number is fixed and cannot be changed.

Yes, bursting is supported in both directions. The effective data throughput from the slave to the master is identical to that of the master to the slave.