Channel Sounding with concurrent BLE/radio

Hello,

I am raising this issue because I am working with multiple devices doing CS procedures between each other and I found a limitation.

I am working with NCS 3.3.1.


When the BLE/radio is used in parallel to channel sounding, procedures can fail. When either the initiator or the reflector is advertising with bt_le_adv_start during the CS, or when either the initiator or the reflector has another active BLE connection, CS procedures are failing.

Here is the log of the initiator with no active connection and no advertising connecting to a reflector that is advertising at 200ms and no additional connection (Note: around 2/3 of these 10 procedures burst have no problems, but 1/3 have some as shown below):
[00:23:03.037,806] <inf> cs_initiator: Start CS as initiator
[00:23:03.038,045] <inf> ble_advertiser: Advertising payload successfully stopped
[00:23:04.678,457] <inf> cs_initiator: CS starting: 1 LE connection(s), adv=IDLE
[00:23:04.878,120] <inf> cs_initiator: CS procedures enabled.
[00:23:05.166,558] <inf> cs_initiator: Distance AP0: ifft=1.46 phase=2.01 rtt=5.22 | AP1: ifft=0.41 phase=2.50 rtt=nan
[00:23:05.366,652] <inf> cs_initiator: Distance AP0: ifft=1.17 phase=2.04 rtt=5.12 | AP1: ifft=0.37 phase=2.44 rtt=nan
[00:23:05.566,587] <inf> cs_initiator: Distance AP0: ifft=1.46 phase=2.01 rtt=3.95 | AP1: ifft=0.42 phase=2.34 rtt=nan
[00:23:05.726,265] <wrn> cs_initiator: Subevent ABORTED (reason 2: NO_CS_SYNC) at step 0, proc 3 [LE conns=1, adv=IDLE]
[00:23:05.798,105] <wrn> cs_initiator: Procedure FAIL: all local subevents aborted (ranging counter 3)
[00:23:05.798,146] <wrn> cs_initiator: Procedure result FAIL (4 done, 6 remaining)
[00:23:05.926,267] <wrn> cs_initiator: Subevent ABORTED (reason 2: NO_CS_SYNC) at step 0, proc 4 [LE conns=1, adv=IDLE]
[00:23:05.958,106] <wrn> cs_initiator: Procedure FAIL: all local subevents aborted (ranging counter 4)
[00:23:05.958,147] <wrn> cs_initiator: Procedure result FAIL (5 done, 5 remaining)
[00:23:06.126,266] <wrn> cs_initiator: Subevent ABORTED (reason 2: NO_CS_SYNC) at step 0, proc 5 [LE conns=1, adv=IDLE]
[00:23:06.158,106] <wrn> cs_initiator: Procedure FAIL: all local subevents aborted (ranging counter 5)
[00:23:06.158,147] <wrn> cs_initiator: Procedure result FAIL (6 done, 4 remaining)
[00:23:06.326,268] <wrn> cs_initiator: Subevent ABORTED (reason 2: NO_CS_SYNC) at step 0, proc 6 [LE conns=1, adv=IDLE]
[00:23:06.358,108] <wrn> cs_initiator: Procedure FAIL: all local subevents aborted (ranging counter 6)
[00:23:06.358,149] <wrn> cs_initiator: Procedure result FAIL (7 done, 3 remaining)
[00:23:06.566,553] <inf> cs_initiator: Distance AP0: ifft=1.17 phase=1.99 rtt=3.91 | AP1: ifft=0.42 phase=1.91 rtt=nan
[00:23:06.766,526] <inf> cs_initiator: Distance AP0: ifft=1.17 phase=2.10 rtt=4.02 | AP1: ifft=0.37 phase=2.32 rtt=nan
[00:23:06.966,556] <inf> cs_initiator: Distance AP0: ifft=1.17 phase=2.11 rtt=4.71 | AP1: ifft=0.40 phase=2.88 rtt=nan
[00:23:06.966,902] <inf> cs_initiator: CS session done: 6/10 procedures succeeded
[00:23:07.238,446] <inf> ble_advertiser: Disconnected (reason 0x16)
[00:23:07.238,978] <inf> ble_advertiser: Advertising successfully started

For active connection, I tried to set the connection interval to 1000ms for example to have maximum one fail during 10 procedures at 100ms per procedure, but weirdly, in this scenario, I sometimes have all 10 procedures failing in a row. I believe if the connection interval happens during the startup, it might break the whole CS connection.

I tried adjusting CONFIG_BT_CTLR_SDC_CS_EVENT_LEN_DEFAULT to match my subevent, have room between connection events and have an interval for advertising, to make the device advertise in between connection events, not during on-going CS subevent but it didn't work.


In my scenario, I just managed to have everything disconnected with no advertising on-going during CS but I am raising this issue if anyone found a solution. 


Regards,
R. Saboret

Parents
  • Hi,

    I believe there can be some timing related problems occuring here, causing some procedures to fail. "Subevents subsequent to the first CS subevent of a CS event." have 2nd priority, the first CS subevent of a CS event still has third priority  "All Bluetooth LE roles in states other than above run with this priority".

    If either device of a single CS subevent has a scheduling conflict it will likely cause the CS procedure to fail, there are no retries for CS procedures, you would just have to wait for the next one. The logs you included here shows that the initiator device have failed CS procedures because it receives no CS_SYNC packets from the reflector, probably because the reflector is busy advertising when the CS subevents are scheduled to happen

    Unless you are running into DRGN-28736, though I think that should be gone in NCS 3.3.1. And that shouldn't make it behave like this.

    Regards,

    Elfving

Reply
  • Hi,

    I believe there can be some timing related problems occuring here, causing some procedures to fail. "Subevents subsequent to the first CS subevent of a CS event." have 2nd priority, the first CS subevent of a CS event still has third priority  "All Bluetooth LE roles in states other than above run with this priority".

    If either device of a single CS subevent has a scheduling conflict it will likely cause the CS procedure to fail, there are no retries for CS procedures, you would just have to wait for the next one. The logs you included here shows that the initiator device have failed CS procedures because it receives no CS_SYNC packets from the reflector, probably because the reflector is busy advertising when the CS subevents are scheduled to happen

    Unless you are running into DRGN-28736, though I think that should be gone in NCS 3.3.1. And that shouldn't make it behave like this.

    Regards,

    Elfving

Children
Related