[nRF54L15DK] hci_uart as external HCI controller for Channel Sounding — configuration validation and session drop issue

Summary :

We are using the nRF54L15DK as an external HCI controller (running the hci_uart sample from NCS v3.3.0) connected to a custom BLE host on a
separate MCU via HCI H4 UART. The host implements the Channel Sounding Reflector role. When a Pixel 10 (running Android native ranging via nRF
Toolbox) connects, pairing succeeds and CS procedures start, but the Android session eventually terminates with "Session disappeared. Try
reconnecting" (REASON_UNKNOWN). The same Pixel 10 paired against a standalone nRF54L15DK running the ras_reflector sample works correctly and
displays distance.

We want to:
1. Confirm our hci_uart configuration is correct for this use case.
2. Understand whether there are known limitations or additional settings required when the controller is driven by an external host over
HCI-UART for Channel Sounding.

---
Hardware

- nRF54L15DK (PCA10156) as the BLE controller
- Separate MCU as the BLE host, connected via HCI H4 UART
- Pixel 10 as the Channel Sounding initiator (via Android native ranging)

---
NCS Version

NCS v3.3.0

---
Build command

source ~/ncs/tmp/ncs_v33_activate.sh
cd ~/ncs/v3.3.0/zephyr/samples/bluetooth/hci_uart
west build -p -b nrf54l15dk/nrf54l15/cpuapp -- -DEXTRA_CONF_FILE="cs.conf"
west flash

---
Files used

1. Base config — samples/bluetooth/hci_uart/prj.conf (unmodified from the sample)
2. Extra CS overlay — samples/bluetooth/hci_uart/cs.conf (custom file placed in sample root):

CONFIG_BT_CTLR_CHANNEL_SOUNDING=y
CONFIG_BT_CTLR_SDC_CS_ROLE_BOTH=y
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_CTLR_SDC_CS_MAX_ANTENNA_PATHS=2
CONFIG_BT_CTLR_SDC_CS_NUM_ANTENNAS=1
CONFIG_BT_CTLR_SDC_CS_STEP_MODE3=n
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_TRANSMIT_POWER_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_EVT_RX_COUNT=16
CONFIG_BT_BUF_EVT_RX_SIZE=255
CONFIG_BT_BUF_ACL_RX_SIZE=255
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_CMD_TX_SIZE=255

3. Board overlay — samples/bluetooth/hci_uart/boards/nrf54l15dk_nrf54l15_cpuapp.overlay (default from sample, unmodified):

&uart20 {
compatible = "nordic,nrf-uarte";
current-speed = <115200>;
status = "okay";
};

&uart20_default {
group1 {
psels = <NRF_PSEL(UART_TX, 1, 11)>,
<NRF_PSEL(UART_RTS, 1, 14)>;
};
group2 {
psels = <NRF_PSEL(UART_RX, 1, 10)>,
<NRF_PSEL(UART_CTS, 1, 12)>;
bias-pull-up;
};
};

The external host is configured to match: UART baud 115200, hardware flow control enabled (RTS/CTS), H4 framing.

---
Observed behaviour

- nRF54L15DK (as HCI controller) enumerates correctly over HCI-UART; the host receives valid HCI events.
- Extended advertising works; the Pixel 10 connects and completes LE Secure Connections pairing.
- CS security (LE_CS_Security_Enable) completes successfully.
- CS configuration (LE_CS_Set_Default_Settings, LE_CS_Create_Config) is accepted by the controller.
- Reconnecting does not recover the session.
- Erasing flash and re-flashing the controller does not help.
- The identical Pixel 10 against the standalone ras_reflector sample on nRF54L15DK works flawlessly.

---
Questions

1. Is the above cs.conf configuration correct and sufficient to enable Channel Sounding support in hci_uart mode when driven by an external
host? Specifically:
- Are CONFIG_BT_CTLR_SDC_CS_MAX_ANTENNA_PATHS=2 and CONFIG_BT_CTLR_SDC_CS_NUM_ANTENNAS=1 the right values to match the nRF54L15DK hardware
(single antenna, 2 paths) so that a Pixel 10 with 2 antennas can negotiate antenna config index 1?
- Is CONFIG_BT_CTLR_SDC_CS_ROLE_BOTH=y required, or is _ROLE_REFLECTOR sufficient?
2. Are there HCI buffer sizes (BT_BUF_EVT_RX_SIZE, BT_BUF_EVT_RX_COUNT, etc.) or other SDC Kconfig knobs specific to CS over hci_uart that
differ from the standalone ras_reflector build?
3. Are there any known issues with the SoftDevice Controller's CS subevent result HCI events being dropped or truncated when relayed over
HCI-UART to an external host, particularly for large step-result payloads?
4. Does the SoftDevice Controller require the external host to acknowledge RAS data (via GATT RAS characteristics) within a specific timeout,
failing which it terminates the CS session? If so, what is that timeout?

---
What we have already ruled out

- UART wiring: physical connection and hardware flow control are verified working (HCI commands and events exchange correctly).
- Controller capability: the standalone ras_reflector with the same board and Pixel 10 works, confirming the hardware supports CS with this
phone.
- Baud rate mismatch: both sides are at 115200 with flow control.

---
Reference

- Standalone reflector build that works: ncs/v3.3.0/nrf/samples/bluetooth/ras_reflector built with android_ranging.conf for
nrf54l15dk/nrf54l15/cpuapp.
- hci_uart sample location: ncs/v3.3.0/zephyr/samples/bluetooth/hci_uart.

Parents
  • Hi

    Thank you for explaining, and my bad for the misunderstanding. The connection and Controller seems to be set up correctly from what I can see. AFAIK there haven't been much testing with channel sounding over HCI UART from our side yet, so I don't have much more than assumptions as of now. We're understaffed during the summer period, so I have not had time to do any testing on my end either, and I'm still awaiting some feedback from the developers on the GATT RAS timeout question. But the HCI UART baud rate theory sounds reasonable, so if you can I'd recommend trying to increase the baud rate and test with some increased baud rates on your end. 

    For the events, I think this depends on the buffer for the HCI UART. It should be queued for as long as there is room in the buffer at least.

    Best regards,

    Simon

Reply
  • Hi

    Thank you for explaining, and my bad for the misunderstanding. The connection and Controller seems to be set up correctly from what I can see. AFAIK there haven't been much testing with channel sounding over HCI UART from our side yet, so I don't have much more than assumptions as of now. We're understaffed during the summer period, so I have not had time to do any testing on my end either, and I'm still awaiting some feedback from the developers on the GATT RAS timeout question. But the HCI UART baud rate theory sounds reasonable, so if you can I'd recommend trying to increase the baud rate and test with some increased baud rates on your end. 

    For the events, I think this depends on the buffer for the HCI UART. It should be queued for as long as there is room in the buffer at least.

    Best regards,

    Simon

Children
No Data
Related