Channel Sounding with concurrent BLE/radio

RE: Channel Sounding with concurrent BLE/radio

rsaboret — Thu, 09 Jul 2026 08:19:47 GMT

Yes, that's fine by me.

I'll check the changelog in the future to see if you manage to implement a fix.

Have a nice day,
R. Saboret

RE: Channel Sounding with concurrent BLE/radio

Elfving — Thu, 09 Jul 2026 08:14:38 GMT

No problem.

I am not yet sure if there is a go-to strategy to try to avoid this though, like increasing the connection interval for instance, like you mentioned.

Are you fine with just the knowledge of why it happens?

RE: Channel Sounding with concurrent BLE/radio

rsaboret — Wed, 08 Jul 2026 16:07:21 GMT

Hi,

Okay, nice to know the different BLE event have different priorities!

Yes, this is probably the cause, as advertising and connection packets all seem to interrupt CS events.

Although I am using NCS 3.3.1 right now and I have this issue so I may be in a scenario slightly different.

Thanks for your input,

Regards,
R. Saboret

RE: Channel Sounding with concurrent BLE/radio

Elfving — Wed, 08 Jul 2026 14:54:18 GMT

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