GATT notification packets per connection interval on nRF Connect SDK

[ebmmy]

Dear Nordic support,

We are experiencing a throughput issue with an nRF52840 dongle operating in the central role, running a custom application developed using nRF Connect SDK 2.9.1. The dongle is connected to an nRF54L15 DK acting as a peripheral using an HCI UART firmware. We are trying to measure maximum throughput by sending GATT notifications. Our goal is to send as many packets as possible within each connection interval. The setup involves a single connection with Data Length Extension (DLE) enabled, using a packet size of 251 bytes and an MTU of 247 bytes.

We are using the vendor-specific Quality of Service (QoS) event to monitor the number of packets sent during each connection event. Before starting the throughput test, we pre-fill all available ACL buffers with notifications using bt_gatt_notify_cb. After this pre-filling, each time the callback is called, we immediately trigger another notification to keep the buffers full.

The problem is that the number of packets transmitted per connection event appears inconsistent and lower than expected. We observe significant variations in the number of packets sent and received (both CRC OK and CRC NOK) across consecutive connection events.

Example logs from the QoS events:

> 00> [00:14:25.649,100] <dbg> Ble: onQosEvent: QoS: counter: 65 - CRC recv ok: 5 - CRC recv nok: 0 - NAK: 0
> 00> [00:14:25.681,900] <dbg> Ble: onQosEvent: QoS: counter: 66 - CRC recv ok: 1 - CRC recv nok: 0 - NAK: 0
> 00> [00:14:25.722,900] <dbg> Ble: onQosEvent: QoS: counter: 67 - CRC recv ok: 0 - CRC recv nok: 0 - NAK: 0
> 00> [00:14:25.769,300] <dbg> Ble: onQosEvent: QoS: counter: 68 - CRC recv ok: 1 - CRC recv nok: 0 - NAK: 0
> 00> [00:14:25.813,000] <dbg> Ble: onQosEvent: QoS: counter: 69 - CRC recv ok: 1 - CRC recv nok: 0 - NAK: 0

Some details on our configuration:

•  CONFIG_BT_BUF_ACL_TX_COUNT and CONFIG_BT_L2CAP_TX_BUF_COUNT set to 20.
• CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT set to 40000.

• Connection interval is 40ms, no latency, 4s supervision timeout

What are your recommendations for achieving a consistently high number of packet transfers within each connection interval? Are there specific settings or techniques you recommend for optimizing buffer filling and transmission speed?

Thanks in advance for your support,
Best regards

[Jakob Ruhe]

Hello,

I have no experience of the QoS event.

But to  achieve high speed you can use 2 Mbit/s data rate. Perhaps you are already doing that. I also guess you have had a look at the is throughput example which can be good to fetch inspiration from, and to perform throughput tests with. 

Within a single Connection Event the nodes can exchange packets as long as either of the Controllers have packets available and there is time left until something else (for example a new Connection Event) should take place.

That motivates a long Connection Event Interval (because we get less interruptions).

However. As soon as a packet is dropped (or is corrupt), no more communication can take place in that Connection Event. Both parties have to wait for the next Connection Event and continue again from the last packet that failed.

That motivates shorter Connection Event Intervals.

So, if you are experiencing that packets get dropped, because of low RSSI or disturbance, you may try to use a lower the Connection Event Interval. Try with 10 ms and 20 ms for example.

[ebmmy]

Hello,

Thanks for your suggestions. I think you've pointed me in the right direction. It appears the peripheral (nRF54) was also scanning and advertising, which likely caused the scheduler on the peripheral side to close the connection event earlier than expected.

Without advertising or scanning on the peripheral side, I'm now able to send up to 15 packets per connection event in a quite stable manner.

This has raised a couple of questions for me:

• What is considered a NAK within the context of the QoS event? Is it triggered by the central receiving a packet requesting retransmission? Is a dropped packet also considered a NAK?

• Is my understanding correct that the SoftDevice controller (on the nRF54 peripheral) could, under certain circumstances, interrupt a connection event with the central to prioritize an advertising or scanning event?

Thank you for your support

Best regards

[Sigurd]

Hi!

ebmmy said:

What is considered a NAK within the context of the QoS event? Is it triggered by the central receiving a packet requesting retransmission? Is a dropped packet also considered a NAK?

https://docs.nordicsemi.com/bundle/nrfxlib-apis-2.9.0/page/structsdc_hci_subevent_vs_qos_conn_event_report_t.html

It's defined as "Number of received Negative Acknowledges from the peer during the connection event."

ebmmy said:

Is my understanding correct that the SoftDevice controller (on the nRF54 peripheral) could, under certain circumstances, interrupt a connection event with the central to prioritize an advertising or scanning event?

Correct, see this link: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/doc/scheduling.html