How can I enable "DTM over HCI" in the nRF Kconfig GUI?

[dio won]

I am trying to enable the Channel Sounding feature on the nRF54L15 DK by sending HCI commands over a "USB to UART" interface. For this purpose, I created the "hci_uart" sample application from nRF Connect SDK v3.2.4 and enabled the Channel Sounding options in the nRF Kconfig GUI before building.

However, during the build, I see a warning indicating that BT_CTLR_DTM_HCI cannot be enabled because BT_CTLR_DTM_HCI_SUPPORT is set to n.

How can I set BT_CTLR_DTM_HCI_SUPPORT to y so that BT_CTLR_DTM_HCI can be enabled?

In the current setup, after flashing the firmware onto the nRF54L15 DK, the LE CS Test HCI command executes successfully.

[runsiv]

Hi

Just for me to be able to provide better support. Are you after DTM or CS? From what I'm seeing you are trying to enable the DTM features over HCI which is only supported if you are using the main branch which is not recommended as its our upstream development branch. 

Regards

Runar

[dio won]

runsiv said:

Just for me to be able to provide better support. Are you after DTM or CS? From what I'm seeing you are trying to enable the DTM features over HCI which is only supported if you are using the main branch which is not recommended as its our upstream development branch. 

hi, runar

I would like to control the DUT to perform Channel Sounding using raw HCI commands.
To achieve this, I built the hci_uart sample application from nRF Connect SDK 3.2.4 and enabled the Channel Sounding-related options in the nRF Kconfig GUI.

During the build process, I encountered a warning message, which is why I initially raised this question.
However, after flashing the firmware to the board, the DUT operates as expected. The Channel Sounding procedure works correctly when sending the LE_CS_TEST and LE_CS_TEST_END HCI commands.

I have two additional questions regarding the current behavior:

1. LE_CS_TEST_END returns 0x0C (Command Disallowed) 

When running on a single nRF54L15 DK board, executing LE_CS_TEST followed by LE_CS_TEST_END returns 0x00 (Success).

However, when testing with an external DUT (with roles configured as Initiator and Reflector), after performing the Channel Sounding exchange (“ping-pong”), sending LE_CS_TEST_END results in 0x0C (Command Disallowed) on the nRF54L15 DUT.

In contrast, the external DUT responds with 0x00 (Success) under the same conditions.

I would like to understand what could cause this difference in behavior on the nRF54L15 DUT.

According to the Core Specification, after the LE_CS_Test command, the DUT is expected to send LE_CS_Subevent_Result (and/or LE_CS_Subevent_Result_Continue) events.

However, in the case of the nRF54L15, these events do not appear to be reported.
As a result, it seems that when the LE_CS_Test_End command is sent, the DUT responds with 0x0C (Command Disallowed).

Could this behavior be due to the missing CS subevent result events from the DUT?
I would appreciate your thoughts on whether this interpretation is correct.

2. How to enable Channel Sounding Mode-3 in nRF Connect SDK

I understand that additional configuration may be required to enable Channel Sounding Mode-3.
However, I could not find any option in the nRF Kconfig GUI related to enabling Mode-3.

Could you please advise how to enable Channel Sounding Mode-3 in this setup?

Thank you in advance.
regards,
dio

[tesc]

Hi,

dio won said:

When running on a single nRF54L15 DK board, executing LE_CS_TEST followed by LE_CS_TEST_END returns 0x00 (Success).

However, when testing with an external DUT (with roles configured as Initiator and Reflector), after performing the Channel Sounding exchange (“ping-pong”), sending LE_CS_TEST_END results in 0x0C (Command Disallowed) on the nRF54L15 DUT.

I am afraid I don't quite understand the difference there. Is the first device our DK, but the second device a custom board which also holds an nRF54L15 SoC? What is the setup for connecting to that custom board, and what are the differences in terms of voltage, clock sources, etc?

Please note that the current state of DTM over HCI in nRF Connect SDK is experimental, which means features might be incomplete. Please refer Software maturity levels for details on what is meant by experimental status.

dio won said:

Could you please advise how to enable Channel Sounding Mode-3 in this setup?

There should be a kconfig option CONFIG_BT_CTLR_SDC_CS_STEP_MODE3, at least there is one in nRF Connect SDK latest.

Regards,
Terje

[dio won]

Hi,
The second device used in this setup is a Silicon Labs DUT, which also supports raw HCI commands over USB-to-UART.

In this test, the nRF54L15 DK was configured as the reflector, and the Silicon Labs DUT was configured as the initiator. The two devices were connected via an RF cable. Based on the RFPHY.TS "CS Step Main Mode, Frequency Verification" test case, the corresponding parameters were set and the LE_CS_Test HCI command was issued to enable CS signal exchanges between the devices.

After completing the CS signal exchange, the LE_CS_Test_End HCI command was sent according to the Core Specification. At this point, the responses from the two DUTs differed:

- The Silicon Labs DUT responded with 0x00 (Success)
- The nRF54L15 DK responded with 0x0C (Command Disallowed)

This behavior was consistent even when the roles of the two DUTs were swapped.

<siliconlabs DUT>

red :HCI_Command_Complete event
green :HCI_LE_CS_Subevent_Result 

<nrf54l15 DK>

red :HCI_Command_Complete event

One notable difference between the two DUTs is their behavior after the LE_CS_Test command:

- The Silicon Labs DUT returns both HCI_Command_Complete and HCI_LE_CS_Subevent_Result events
- The nRF54L15 DK only returns HCI_Command_Complete and does not report any HCI_LE_CS_Subevent_Result events

According to the Core Specification (Channel Sounding Test MSC: IUT in Reflector Role), after completing the CS subevent exchanges, the DUT is expected to report either HCI_LE_CS_Subevent_Result or HCI_LE_CS_Subevent_Result_Continue events.

However, in this case, the nRF54L15 DK does not appear to send any CS subevent result events. Therefore, I suspect that this might be the reason why the subsequent LE_CS_Test_End command results in a Command Disallowed (0x0C) error.

Could you please review whether there might be any issues in my HCI_UART application configuration (prj.conf)?

Currently, I have configured the following Kconfig options. However, some options do not seem to be enabled due to dependency constraints:

• CONFIG_BT_CTLR_CHANNEL_SOUNDING
• CONFIG_BT_CTLR_SDC_CS_STEP_MODE3

To enable these, it appears that BT_LL_SOFTDEVICE must be enabled. However, since DT_HAS_NORDIC_BT_HCI_SDC_ENABLED cannot be enabled, these options are forced to n during the build.

I would appreciate it if you could provide guidance on whether this configuration could be related to the issue.

Best regards
dio