RE: Problems implementing a one-to-many positioning system using Bluetooth CS on nRF54L15

Edvin — Fri, 24 Apr 2026 12:18:14 GMT

Hello,

For clarity, how is prj_hci_ipc.conf included in your project? And what is it's location (in your application folder)?

Channel sounding is a techonlogy that doesn't scale incredible well, but it should be possible to handle 4 connections, but perhaps not with the frequency that you imagined.

1: It does require more time, and more CPU processing power. Exactly if this is the reason why you see NaN in your log, I am not sure. You can try to figure it out through debugging. You should be able to detect why it decides to print NaN instead of a number. Perhaps you can share the piece of code that prints it, and I can help you do some digging to see if I can figure out why.

2: We have some recommendations here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/doc/scheduling.html#channel_sounding_timing

3/4: These are not trivial questions. But first, what kind of devices do you plan on making? Let us, for simplicity, call the 4 stationary (I assume you have 4 stationary devices, and one moving device, based on what you write) devices for scanners, and the moving device for the tag.

Where do you want your CS (Channel Sounding) data to end up? Do you want it on the tag, or does it end up in a computer somewhere? And how do you transfer it from the tag to where it is being used? The reason I ask is that if you need the data outside the tag itself, then perhaps you should consider having the scanners do the CS initiator role, and the tag can be the reflector. Another effect of this is that the main number crunching happens at the initiator side of the connection. Because of this, there are two reasons you might want to switch up the roles:

1: The stationary scanners tend to have better battery capacity, and besides they will only do 1/4th of the number crunching, compared to the tag being the initiator and calculating the distance to 4 reflectors.

2: You will spread out the load of calculations, so that instead of one device having to do calculations for 4 distances, you will have 4 devices each doing calculations for 1 distance. It is simply cutting down the processing time by 4.

BUT: You will have to transfer the distance data to a centralized location if you intend to map out where the tag is located.

One thing to keep in mind: If you decide to switch around the roles, it is still recommended to have the tag act as the BLE central in the connections. This is because then it will be in control of the connections, avoiding collissions. So if you want to test this, the first would be to flip around the BLE role in the sample, so that the central will be the reflector, and the peripheral will be the initiator.

Best regards,

Edvin