Concurrent channel sounding procedures

RE: Concurrent channel sounding procedures

Elfving — Fri, 24 Oct 2025 06:19:52 GMT

Hi,

I might be misunderstanding you here but doing it sequentially is what we currently support.

Regards,

Elfving

RE: Concurrent channel sounding procedures

Hareesh123 — Wed, 22 Oct 2025 17:07:34 GMT

I tried the way you told . Its not working to concurrently get the data. Only when I press reset I am switching to the next board any way to resolve this

RE: Concurrent channel sounding procedures

Elfving — Wed, 09 Jul 2025 14:50:30 GMT

[quote user="Triscuit"]Could you ask the team if the issue with concurrent is because of the scheduling conflicts in the sdc please?[/quote]

Yeah, this is the case. Not because that there necessarily is a scheduling conflict, but that there scheduling conflicts might happen. I've also now learned that it can happen between CS and normal connections as well, which would explain why there would still be issues with just one device doing CS at the time and the other connections just waiting. It might be that rebooting does something with the connection priorities, making these conflicts less frequent.

It seems that making a new connection for CS each time is the only way of making sure that you are not running into a scheduling conflict at the moment. I'll ask the team about your specific scenario.

Regards,

Elfving

RE: Concurrent channel sounding procedures

Triscuit — Fri, 04 Jul 2025 22:45:30 GMT

Hi Elfving,

I tried the sequential method where I simply just enable and disable channel sounding as well as connect and disconnect, but they all won't work unless I reboot the reflectors. Perhaps I did not shut down the procedure properly? But even when I disconnect and try to connect again, they fail to connect. I had a reply from another dev and they said to use the recycle callback but even that did not work. I am not sure what rebooting does that disconnecting and connecting don't do.

Could you ask the team if the issue with concurrent is because of the scheduling conflicts in the sdc please? It is my ultimate goal to do it concurrently, but right now I have to settle for sequential where I connect, disconnect, and then reboot each reflector every time I disconnect. Thank you so much for your time.

Sincerely,

Triscuit

RE: Concurrent channel sounding procedures

Elfving — Fri, 04 Jul 2025 13:34:26 GMT

Hi and sorry about the delay on this one,

Please let me if these requests are urgent for you. Any update on this from your side?

[quote user="Triscuit"]Do you know if sequential would work if I enable and disable channel sounding procedure instead of connect and disconnect the devices?[/quote]

Sounds like this would keep the connections and avoid the main issue, which is scheduling conflicts between the different CS procedures- And I agree that keeping the connections alive would be faster. I guess there could also be conflicts between the CS procedures and other normal connections but I haven't heard of that being a problem. I can check with the relevant team.

[quote user="Triscuit"]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.[/quote]

I'll ask with the team about this. Is sequential what you are currently going for?

Regards,

Elfving

RE: Concurrent channel sounding procedures

Triscuit — Wed, 18 Jun 2025 21:17:15 GMT

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

RE: Concurrent channel sounding procedures

Elfving — Fri, 13 Jun 2025 08:08:04 GMT

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.

[quote user="Triscuit"]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? [/quote]

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

Regards,

Elfving

RE: Concurrent channel sounding procedures

Triscuit — Wed, 11 Jun 2025 23:00:39 GMT

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.

RE: Concurrent channel sounding procedures

Triscuit — Wed, 11 Jun 2025 20:59:09 GMT

Hi, did you also succeed in setting them both up and enabling cs? I just tried it again but it still only returned data for one of them. I am starting to really think it's a hardware limitation. Because when I set MAX_CONN to 1 it performs perfectly but when I turn it to 2 or over it performs poorly, but the set up and everything was fine, just the actual get_distance part that is affected.

RE: Concurrent channel sounding procedures

marrycol — Wed, 11 Jun 2025 06:50:03 GMT

I run into that problem too... godly parent quiz

RE: Concurrent channel sounding procedures

Simonr — Fri, 06 Jun 2025 11:25:03 GMT

Yes, I assume this is a SW problem, unfortunately I've not been able to find the reason for what needs to be changed exactly. I'll be gone for the next week, so I'm handing this case over to one of my colleagues. Best of luck!

Best regards,

Simon

RE: Concurrent channel sounding procedures

Triscuit — Thu, 05 Jun 2025 17:10:04 GMT

Hi,

Since you mentioned the sample simply isn't designed to do concurrent sampling, do you think it can still be done? I am assuming this is a software problem? And do you have an idea what I need to change in order to make this happen? Thank you so much in advance.

Sincerely,

Triscuit

RE: Concurrent channel sounding procedures

Simonr — Thu, 05 Jun 2025 06:33:13 GMT

I don't think there should be signal interference, as devices use slightly different frequencies for the ranging AFAIK, nor do I think Channel Sounding uses too much memory to have multiple connections.

I think the main issue is that the sample simply isn't designed to doo concurrent sampling at the moment, and this is not something we have tested as of yet.

Best regards,

Simon

RE: Concurrent channel sounding procedures

Triscuit — Tue, 03 Jun 2025 17:54:15 GMT

Hi,

Yes I am using the NRF54l15 dk for both the initiators and the reflector. I am running the procedure concurrently right now.

static int find_free_slot(void)
{
    for (int i = 0; i < MAX_CONN; i++) {
        if (connections[i] == NULL) {
            return i;
        }
    }
    return -1;
}

static int find_conn_index(struct bt_conn *conn)
{
    for (int i = 0; i < MAX_CONN; i++) {
        if (connections[i] == conn) {
            return i;
        }
    }
    return -1;
}

static void connected_cb(struct bt_conn *conn, uint8_t err)
{
    char addr[BT_ADDR_LE_STR_LEN];
    bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
    LOG_INF("Connected to %s (err 0x%02X)", addr, err);

    if (err) {
        LOG_ERR("Connection failed (err 0x%02X)", err);
        bt_conn_unref(conn);
        return;
    }

    int idx = find_free_slot();  // Find an empty spot
    if (idx == -1) {
        LOG_WRN("No free connection slots");
        bt_conn_disconnect(conn, BT_HCI_ERR_CONN_LIMIT_EXCEEDED);
        bt_conn_unref(conn);
        return;
    }

    connections[idx] = bt_conn_ref(conn);
    cs_settings_applied[idx] = false;
    k_sem_give(&conn_sems[idx]);
    dk_set_led_on(CON_STATUS_LED);

    start_advertising();
}

I am using an array to keep track of pointers to each connection. Each one is differentiated by their index in the array.

The issue I have in mind is that maybe it is because there are multiple Bluetooth connections that the signals might interfere with each other. Either that or maybe channel sounding takes up too much memory for a single reflector. Thank you so much for your help.

RE: Concurrent channel sounding procedures

Simonr — Tue, 03 Jun 2025 13:11:58 GMT

What HW are you using here, nRF54L15 DKs on both end or custom boards? Are you doing the ranging concurrently, not sequentially, in your application, correct? I know sequential measurements should work, but that ranging multiple devices concurrently has not been tested much on our end yet, so the support we can provide there is rather limited.

What kind of HW issues are you having in mind? If you'd like I can forward this to our developers to see if they have any clues to why this could be. Would it be possible to add a snippet to show how you handle the concurrent ranging on the reflector side on your end, as I imagine you have a way of differentiating the initiators you're trying to do ranging from.

Best regards,

Simon