An ANT burst transfer will only automatically retry individual failed packets.
To use your example, if you have successfully transferred burst packets 1 to 3, and burst packet 4 fails, then ANT will retry to send that packet. If the retry is successful, then ANT will continue to send the remaining packets (5 through 8).
If the retry was unsuccessful - ANT will retry to send that packet (i.e. 4th packet) up to a preset number of times. Once this preset number of retries (per packet) is exceeded, ANT will issue the EVENT_TRANSFER_TX_FAILED on the transmitter side, and an EVENT_TRANSFER_RX_FAILED on the receiver side.
At this point, it is up to the application to decide whether to resend the entire burst (i.e. packets 1 through 8), or to just send the remaining packets. Either way, the sequence numbers must be reset back to 0 for the first packet of the next burst transfer. A burst transfer must always start at sequence number zero.
If you are only bursting 8 packets at a time, i would recommend you resend the entire burst transfer as this is a much simpler implementation. On receiving an EVENT_TRANSFER_RX_FAILED, the receiver can just discard the data it received, and process the data from scratch on the next timeslot.
If you were wanting to just resend the remaining packets - there are a few things you must be careful to address correctly. Again, using your example... lets say the first 3 packets were received correctly and the transmitter then tries to send the 4th packet, which fails... there are two possible reasons for a failure:
1. the receiver did not receive packet 4.
2. the receiver DID get packet 4, however, the transmitter did not receive the acknowledgment.
There is no way for the transmitter to know which of the two happened. It will try to resend the message either way. If packet 4 retries exceed the maximum number of retries, then an EVENT_TRANSFER_TX_FAILED is issued and the transfer is aborted. Similarly on the receiver side, an EVENT_TRANSFER_RX_FAILED is issued and transfer aborted.
If only the remaining data is to be sent, the transmitter will start the next burst transfer at message packet 4, with the sequence numbers reset (this is important, a burst transfer must always start at sequence number zero). On the receiver side, the application must be able to handle both scenarios 1 and 2 listed above). If the receiver didn't actually receive packet 4 (i.e. situation 1) in the original burst, then it will be receiving data in order. IF, however, situation 2 occurred and the receiver previously received packet 4, then the application must be able to recognize the repeated packet, discard it, and then go on to receive packets 5 through 8.
So resending the remaining data is not as simple as it first sounds, mostly as there is no way for the transmitter to know if the 'failed' packet was actually received or not. This is why we recommend, especially for relatively small transfers, to simply discard a failed transfer and resend on the next message period.
For sending large amounts of data, we have a more sophisticated file transfer system (available to ANT+ members) that handles resending of partial burst transfers of bulk data.
