ACK/NACK in NUS sample code

RE: ACK/NACK in NUS sample code

Hieu — Wed, 30 Apr 2025 22:19:13 GMT

Hi pal_722,

[quote user="pal_722"]Where can we find this in the code?[/quote]

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.

[quote user="pal_722"]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?[/quote]

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

RE: ACK/NACK in NUS sample code

pal_722 — Tue, 29 Apr 2025 09:17:49 GMT

Hi Simonr
Thank you for the reply. I have understood the concept.

Where can we find this in the code?

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?

Regards
Thank you

RE: ACK/NACK in NUS sample code

Simonr — Tue, 29 Apr 2025 08:48:28 GMT

The UART itself doesn't do ACK/NACK, and this happens in the Bluetooth LE Link Layer. The link layer uses 2 bits for acknowledgement: transmitSeqNum and nextExpectedSeqNum called SN and NESN bits from the packet

When receiving a packet, the device compares the packet's NESN with its own sn
If they match, it's considered a NACK (negative acknowledgment)
If they don't match, it's considered an ACK (acknowledgment)

Best regards,

Simon