Reduce time to start channel sounding

RE: Reduce time to start channel sounding

Simonr — Thu, 16 Apr 2026 10:23:07 GMT

Okay, so we would need to know what the controller is doing at this time. Can you capture a sniffer trace of the process so we can see what's going on over the air here? Please set CONFIG_BT_USE_DEBUG_KEYS=y on both sides to get into the application correctly.

We also had a jab at reducing the time from the connected_cb to the CS procedure_enable_cb in the initiator/reflector samples with a sequence of quick improvements. We were able to get down from 977ms to 219ms, and managed to use the cached remote capabilities here. Maybe the PR here might serve as inspiration for you: https://github.com/nrfconnect/sdk-nrf/pull/28197/commits

Best regards,

Simon

RE: Reduce time to start channel sounding

nikeub — Tue, 14 Apr 2026 11:00:01 GMT

Hi,

This happened on the initiator if that's what you are asking. bt_le_cs_security_enable is not called on the reflector side.

RE: Reduce time to start channel sounding

Simonr — Mon, 13 Apr 2026 13:52:02 GMT

Just to understand what's going on with the bt_le_cs_security_enable() taking extra time, is this on the BLE host side or server side? I don't have any obvious suggestions, so I have to ask the devs about what this could be due to.

Best regards,

Simon

RE: Reduce time to start channel sounding

nikeub — Tue, 07 Apr 2026 15:39:59 GMT

The timing is critical since this is used for an access control use case. We need to determine quickly if a person is close. From scan to connect we are aiming for something closer to 300 ms.

I tried compile-time hardcoding the capabilities struct and calling HCI_LE_CS_Write_Cached_Remote_Supported_Capabilities on both sides, but then bt_le_cs_procedure_enable fails with status 0x1E. Should this be possible, or does at least one capabilities exchange need to happen after reboot before calling write cached?

I also noticed that even if I optimize everything before the CS functions, I eventually get capped by bt_le_cs_security_enable. It seems like it’s blocked on something underlying that the SDC is doing.

As a test, I stripped the path down to bare minimum to rule stuff out (no capabilities exchange, config, subscribe, discovery, etc.) and just called bt_le_cs_security_enable, but it took ~82 ms. If I add delay ~100 ms sleep before calling it, the time to execute it drops to ~27 ms. Any idea what could be causing that?

RE: Reduce time to start channel sounding

Simonr — Fri, 20 Mar 2026 06:59:38 GMT

It does not seem to be possible to cache the MTU exchange and CS security within the BLE specification at least, but some more information on the CS capabilities. It should be possible to use the LE CS Write Cached Remote Supported Capabilities command if the peer's capabilities are known. It's also possible to use the LE CS Create Config command with Create_Context=0 if both devices create a pre-defined identical configuration.

Any further changes I think might be breaking with the BLE specification. What's the target time you're looking at for getting a Channel Sounding session started? And is this just one to one pairing, or are you planning on having multiple devices being tracked regularly which is why the timing is critical?

Best regards,

Simon

RE: Reduce time to start channel sounding

Simonr — Wed, 18 Mar 2026 14:35:32 GMT

Channel Sounding config/cap exchange: I'm not sure how much this would reduce the timing, but from ...\nrfxlib\softdevice_controller\include\sdc_hci_cmd_le.h The host may store a copy of the remote device's capabilities and write the remote capabilities in the local controller when it reconnects to the same remote device by using the HCI_LE_CS_Write_Cached_Remote_Supported_Capabilities command.
As far as I know, I think this is per BLE specification, and the MTU exchange must be done. I'll have to double check that and get back to you though.
I will also need to find out and get back to you whether this is a must or not, my initial guess is that it is required.

Best regards,

Simon