This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF8001, ACK missing with indicate property

When sending data on a pipe with ACK (indicate), the acknowledgement seems to get lost if the device gets disconnected right after having sent that data. Is that a normal behaviour? How can I know if the data has been transmitted successfully?

The goal is to have a reliable data transmission where every packet is resent as long it is not acknowledged by the receiver. If there is an unintended disconnection (connection timeout) after having sent a data packet, no acknowledgement is received and the data will be resent after reconnection. This sometimes leads to a second reception of the same message...

How can a server (nRF8001) know that a data has been received if there is no ACK? What do I need to get a transmission where every message is reliably transmitted exactly once?

  • The BLE link ensures that every packet that is transmitted is acknowledged at the radio level. This is true only when the BLE link is present. i.e connected. If the link is disconnected you cannot get acknowledgements. This is provided by the BLE link without any application intervention. The BLE link level ack or radio level ack is provided by the ACI Data Credit Event.

    When using a Pipe with Ack, you get an additional acknowledgement for the Indicate, however the BLE link needs to be up, so if the link disconnects after sending the data but before receving the application level ack, you application will not get the ack for the Pipe. However you do get the radio level ack for the data that you sent on the Pipe with Ack as the ACI Data credit event. This can be used to ensure that you do not re-transmit the packet on the next connection.

    As an alternative you may choose to discard the duplicate packet that you received on the peer, when your application on the device re-transmits the packet.

    = Please accept the answer if this has helped.

  • Thank you for this answer. The idea looks good, but unfortunately I can not confirm what you are suggesting :-/

    When sending data on a pipe with ACK, I always get the DataACKEvent right after the DataCreditEvent at the next connection interval following the data transmission. Even when using a pipe without ACK, the DataCreditEvent occurs at the next connection interval. This is easy to see, you only need to set the connection interval to 2 seconds.

    Is there some other configuration that could influence this behaviour? I would really like to use the radio level acknowledgement as you suggested, but for now there is no difference. Even when using the DataCreditEvent as a confirmation for successful transmission, I still get duplicate packets...

    I cannot discard the duplicate packets on the peer side, because there is a possibility to send several identical packets which are all valid. I have no time-code or other counter which would allow me to tell that the received data is a re-transmission and not a new data packet.

  • Can't comment your answer (too many characters). See my answer below...

Related