Concurrent channel sounding procedures

[Triscuit]

Hi,

I am trying to create a trilateration system with 3 initiators and 1 reflector (Hopefully multiple reflectors in the future) on the nrf54l15. The channel sounding with range requestor sample code demonstrates a one to one connection, but I modified the reflector logic so it keeps up to 4 connections in an array. When I run channel sounding with just one to one connection everything works perfectly. When I try to connect two initiators they both connect but usually only one initiator is able to receive the distance data, the other one just keeps displaying "tried to parse empty data", but once in a while they would both receive data, and sometimes they both don't get data. I am not sure what the issue really is. I thought about the reflector not having enough buffer but I turned it up already in the config file. Could this be a hardware issue? Is it just interference or maybe the sample code just cannot handle concurrent connections? I only saw one other post about concurrent connections and they only got it in sequential order. Any advice is appreciated as I cannot really progress at this point, thanks!

[Triscuit]

I tried a new method with 3 reflectors and 1 initiator instead, however, I am still running into the same issue. I have done a lot of testing and nothing worked. I am starting to believe that this is due to hardware limitation. I asked chatGPT and it mentioned that the nrf54l15dk has only one radio. In order to perform concurrent connections the singular radio needs to switch between two different connections. Channel sounding needs very precise timing and the switch between them causes them to receive poor data and sometimes no data. This aligns with my tests, where if I just run one procedure it works fine, however, when I run multiple they start encountering issues. It also mentioned that in the SoftDevice Controller it only allows one channel sounding procedure to be carried out at a time, which we cannot change unless we request a custom kit from Nordic, is this true? Knowing this, could an engineer maybe provide advice on how to make this work on the software side? Or could someone confirm my suspicion of this hardware limitation and let me know if this is possible. Thanks so much.

[Elfving]

Hi guys,

It is true that the NRF54L, as well as all of our devices, have only one radio. So with multiple connections, ie. from one BLE central to multiple peripherals, or with device doing both BLE and Zigbee at the same time, or anything like that, things do happen sequentially in the radio. This is typically handled by MPSL in the stack, and still typically thought of as concurrent - much like a multi-threaded program "does things at the same time". How this is handled on the back-end needs to be optimized for it to work well though.

And that is the current issue with multiple channel sounding connections. It's possible to run CS on multiple connections at the same time, but we currently don't make much effort to avoid scheduling conflicts, so parameters and kconfigs have to be selected carefully for it to work well. This however, isn't as much of an issue if the connections are handled sequentially in the application. 

One common pitfall though, is to forget to increase BT_CTLR_SDC_CS_COUNT when you doing multiple CS connections. Make sure that you are atleast doing that. We have a few more notes in the docs, which might help you get the concurrent way to work, though the sequential way is what we're certain of should work.

Triscuit said:

It also mentioned that in the SoftDevice Controller it only allows one channel sounding procedure to be carried out at a time, which we cannot change unless we request a custom kit from Nordic, is this true?

SDC can handle it, though currently isn't optimized for it. There is no custom kit for this.

Regards,

Elfving

[Triscuit]

Hi,

Do you know if sequential would work if I enable and disable channel sounding procedure instead of connect and disconnect the devices? I tried connecting and disconnecting and it works, but I thought turning on and off the channel sounding itself while keeping the connections alive may be faster. With just one device it works great, and took about half the time of reestablishing the connection every time, however, when I move on to 2 or more devices, the ones after the first were never able to receive any data, it also said "Tried to parse empty step data". I made sure to wait for connections to establish, wait for cs to enable, wait until ranging_data_get_complete_cb is called. I also gave each iteration a few seconds before proceeding to the next, but nothing worked. I set BT_CTLR_SDC_CS_COUNT to the proper number as well as CONFIG_BT_MAX_CONN. I have no more ideas for the software side to make this work. My only idea is that it might be due to the sdc not being optimized to keep multiple connections alive as well as perform channel sounding procedure. Is this also because the sdc isn't optimized for it? Are there any more steps I can take to fix this issue? Thanks in advance.

Sincerely,

Triscuit