ACK/NACK in NUS sample code

Hi, 

Does Central or Peripheral UART enable ACK/NACK in the code for BLE communication? 
How does Peripheral recognize if Central has received all the data ? Is there any ACK for the same ?


Regards
Thank you 
Pallavi 

Parents Reply Children
  • Hi pal_722,

    pal_722 said:
    Where can we find this in the code?

    The Link Layer is implemented in the Bluetooth Controller. The default controller in the nRF Connect SDK (NCS) is the SoftDevice Controller, which is only released as a binary, and you don't have access to the source code.

    However, this acknowledging mechanism is specified in the Bluetooth Core Specification. Therefore, the fact that the SoftDevice Controller is qualified by the Bluetooth SIG is a guarantee that the Link Layer works to spec, including the acknowledging mechanism.

    pal_722 said:
    I have read that Notify characteristic doesn't give ACK/NACK, is it TRUE?
    If so, what should I do to reduce data loss? 
    Should I change to Notify to Indications?

    As Simon said, there are multiple layers in the Bluetooth LE protocol.

    When we talk about Notification and Indication, we are talking about the GATT layer. In this layer, it is true that Notifications don't have acknowledge, while Indications do.

    However, all traffic in the GATT layer will eventually go through the Link Layer, where every packet does have acknowledgement.

    Adding the fact that the BLE stack is guaranteed to pass every event to the application, notifications can be used without data losses. The application simply needs to have enough buffer to store the data and process the data fast enough.

    Indication is useful in scenarios where processing can't be quick enough. The acknowledgement can be used as a form of flow control. You can refer to this DevZone case for a discussion on the topic:  Use cases of indications - When is it better to use indications over notifications? .

    Regards,

    Hieu

Related