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, I already turned BT_CTLR_SDC_CS_COUNT up to accommodate the procedure but it still did not work. I have turned to sequential. During the sequential process I tried to connect, get data, and disconnect each reflector as a cycle, however, I realized that after I disconnected the reflector it can no longer connect back with the initiator, it can only be done through a reboot on the initiator side. I called bt_conn_unref on both sides and set connection to NULL, but nothing worked. In the disconnected_cb for reflector I just made it advertise again and for the initiator it starts scanning but it's not able to connect. Do you have any idea why? Thanks in advance.