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.