DLE doesn't seem to be working in hci_uart sample

[Matthias Ringwald]

Hi there

I'm using the HCI UART bridge from NCS v3.2.1 in zephyr/samples/bluetooth/hci_uart with the provided overlay-all-bt_ll_sw_split.conf on an nRF54L15Dk and our Bluetooth Host stack: https://github.com/bluekitchen/btstack/)

While doing throughput tests with a 200 bytes MTU over GATT against the PTS / BL654 with PacketCraft Controller,  I've wondered about the lower-than-expected data-rate.

Inspection of the HCI log of the nRF54l15 as Peripheral shows that the DLE is enabled in general as the SoftDevice reports TX Len 251 and TX Time 2704 us for the HCI Read Maximum Data Length.

We then use the LE Write Suggested Default Data Length with these values to set them as default. However, there's no HCI Event Data Length Change event later when the connection gets established.

Following the https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-3-bluetooth-le-connections/topic/blefund-lesson-3-exercise-2/ I was also sending the HCI LE Set Data Length Command although that should not be necessary due to the earlier LE Write Suggested Default Data Length.

As a comparison, I've replaced the nRF54L15 with a second PTS dongle, where DLE gets activated as expected.

I've attached two zips with logs: one with PTS -> PTS and one with PTS -> nRF54L15. In the zips are the HCI trace as .pklg for Wireshark as well as the console log which also shows how to compile and run our examples. I've also include the .config File from the west built. 

Why is DLE not working here? Do you have an HCI trace that shows a working DLE setup for comparison?

Thanks & best regards,

 Matthias

2026-01-26-DLE-PTS-nRF54L15-SoftDevice.zip

2026-01-26-DLE-PTS-PTS.zip

[Hung Bui]

Hi Matthias, 

Could you explain why you use overlay-all-bt_ll_sw_split.conf when you want to use softdevice controller? My understanding is that CONFIG_BT_LL_SW_SPLIT=y will select Zephyr controller, not softdevice controller. 

My suggestion is to test the nRF54L as a stand alone BLE device first and verify that it can do DLE before you move to the hci_uart. 
Have you tried the sample \nrf\samples\bluetooth\throughput ? I believe it should have the DLE covered. 

[Matthias Ringwald]

Thanks for your quick reply.

---

I have tested the Throughput example and made two observations:

1. DLE works as expected (at least according to throughput numbers and the callback)
2.  the le_data_len_updated callback is not called on the peripheral side.

I see this on central

==== Starting throughput test ====
PHY update pending
LE PHY updated: TX PHY LE 1M, RX PHY LE 1M
LE Data length update pending
LE data len updated: TX (len: 27 time: 2120) RX (len: 27 time: 2120)

And this on peripheral

LE PHY updated: TX PHY LE 1M, RX PHY LE 1M

==============...

While this doesn't have an effect on the throughput, it makes debugging the DLE setup harder.
It looks like the missing callback might be an issue in the SoftDevice Controller.

Please check attached log files. Do you agree that the callback should have been called?

2026-01-29-Throughput.zip

---

Back to the HCI UART example. I did use overlay-all-bt_ll_sw_split.conf in the hope to enable all features. Let's ignore this configuration for now.

We use an extended version of the HCI UART example that supports an additional command for time sync between the Host and the Controller. The project is here: https://github.com/bluekitchen/hci_uart_iso_timesync

I've attached new log files as well as the .config file from build/hci_uart_iso_timesync/.config which shows that 

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_DATA_LENGTH=y

2026-01-29-DLE-PTS-nRF54L15-SoftDevice.zip

During stack startup, DLE seems to be supported, but nothing happens. What's wrong / missing?
Any suggestions to get more insight or how to find the difference between your Throughput example and our tests using HCI UART?

Thanks, 
Matthias

  

[Adrian Eggenberger]

Hi Matthias

I followed this issue and now an old ticked of me is referenced...  :-)

For us the two mentioned CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN... kconfig options solved the problems with data length extension. We still use these settings within our solution (uses NCS v3.1.1).

Regards Adrian

[Matthias Ringwald]

Hi Hung.

Thanks for the answer and pointing to the older ticket.

After adding these two KConfig options, the throughput for bi-directional data at 1M-Phy jumped from 50 kB/s to 80 kB/s matching our expectations! 

As I'm not the only one struggling with this, I think it would be helpful to promote a "All batteries included" KConfig setup which enables all features of the SoftDevice for the HCI UART example/use-case as there's no need to conserve memory to save.

I find it much easier to disable a feature I don't need then to figure out what's needed to enable it. 

Anyways thanks again for helping us getting this sorted out. We'll try to keep our HCI UART example up-to-date.

Best,
  Matthias 

[Matthias Ringwald]

Hi Adrian

Well, then thanks for bringing this up last year. I've just verified that it works on NCS v3.2.1.

Best regards,
 Matthias

[Hung Bui]

Hi Matthias, 
I'm glad that you get it working now. 80kB of actual payload is pretty good at 1Mbps PHY . 

I agree that it would be great if there is a list of all the features that can be enabled so that we have an overview of the configuration/feature that can be turned/tuned on/off . I will forward this internally. 

[Matthias Ringwald]

Thanks. The high throughput is due to your SoftDevice Controller, our stack is merely keeping it busy

Such an overview would be great. I'm a bit afraid that it will become complex to document the dependencies fully, but even a partial one is helpful.