Valid bt_le_cs_create_config_params channel sounding parameter combinations for the nRF54L

[psychogenic]

The channel_sounding_ras_initiator/reflector samples work but trying any other combination of parameters for bt_le_cs_create_config_params or bt_le_cs_set_procedure_parameters_param will often lead to failures like

[00:02:04.067,006] <wrn> bt_hci_core: opcode 0x2090 status 0x12

[00:02:04.073,642] <err> main: Failed to create CS config (err -22)

where the call to bt_le_cs_create_config() will error out with an EINVAL error.  What's invalid?  Because the message is opaque, and because trying things involves a whole cycle of building and burning, it is excruciatingly slow going.  

Using mode 3 by enabling BT_CTLR_SDC_CS_STEP_MODE3=y (as per https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/doc/channel_sounding.html#cs_kconfigs ) setting params.main_mode_type to BT_CONN_LE_CS_MAIN_MODE_3 gives this error.

Playing with main_mode_type and sub_mode_type, even when not using MODE3: same error.  There are in fact lots of ways, I have discovered, to get the same error.

My questions are:

  * is it possible to get a deeper look at what the actual problem is, as in which value is invalid (I tried upping the log level, that made lots of noise but gave no more information)? and

  * where can we see which combinations of parameters for bt_le_cs_create_config_params would be valid with the nRF54L15?

Thanks

[Simonr]

Hi Pat

Can you share some details on what exactly you want to do here. What is available in terms of channel sounding is thus far a bit restricted, but if you share some details on what you want to achieve we can help with that.

The invalid argument I think is easiest to find out what is if you change one and one of the cs_create_config_params() and see what changes triggers this error message.

Unfortunately we don't have documentation on what parameter combos are valid and not as of yet, but if you point to a specific combination, I can follow up with the developers to find out what exactly the invalid part here is. We are still working on documentation and the channel sounding implementation.

Best regards,

Simon

[psychogenic]

What I'm mainly trying is to not have to brute force this, it's incredibly inefficient.

To be more specific, I'm attempting two different things:

  1) I'm trying to characterize performance under various scenarios, to find the best selection from the "knobs" we can turn in bt_le_cs_create_config_params and bt_le_cs_set_procedure_parameters_param.

So far, all I've managed to tweak without getting a bunch of EINVAL are mode_0_steps, main_mode_repetition, min_main_mode_steps (and max), min_subevent_len (and max), and really these have had very little impact on measured performance of distance estimates.  

Here's a sample of the largest (pearson) correlations found for a trial runs iterating over a wide range of the settings above

max_procedure_len - ifft_dev               cor:0.087 p-val=0.178
main_min_steps - elapsed_time              cor:0.061 p-val=0.342
max_subevent_len - elapsed_time            cor:0.045 p-val=0.489
main_max_steps - ifft_dev                  cor:0.032 p-val=0.620

(without any low pass smoothing), so some impact of settings on ifft std dev and elapsed time, but it's really tiny (and bigger values of proc len and max steps are just making std dev a tiny bit bigger, so yeah, not what I'm hoping for).

Anyway: short version is I want to know which of the available knobs I can actually turn and use together without going through the process manually like a beast of burden.

 2) I'd like to get something out of start_simple_cs_test as described here Getting channel sounding start_simple_cs_test working in zephyr bluetooth shell

I've tried over 70 times in the shell with different config settings (not all unique, but I have a full log if you're interested) to get a result other than an abort for BT_HCI_LE_CS_PROCEDURE_ABORT_REASON_TOO_FEW_CHANNELS after a whole 3 steps of mode 0.  Has anyone actually got that working?  If so, how exactly, what's the config for that?

[Elfving]

Hi Pat, and sorry about the wait.

I agree that this does sound inefficient. I would typically note two things here, that we've naturally made it possible to make configurations that aren't yet available on the SDC. We should've documented what is supported here as well as this place which you've already found, and that some changes to procedure parameters might be overlooked. Though if it was as straight forward as that I wouldn't expect you to run into an error when simply enabling BT_CTLR_SDC_CS_STEP_MODE3, as that was supposed to be supported. 

So I agree that this sound cumbersome and confusing. I'll ask the relevant R&D team about this.

Using mode 3 by enabling BT_CTLR_SDC_CS_STEP_MODE3=y (as per https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/doc/channel_sounding.html#cs_kconfigs ) setting params.main_mode_type to BT_CONN_LE_CS_MAIN_MODE_3 gives this error.

Did you get an error when just enabling step mode 3? Otherwise things were as default?

Regards,

Elfving