Multi-initiator Channel Sounding – best practice for fast distance updates (indoor tracking)

[Thanos Vasiloglou]

I’m working on an indoor tracking system based on the Bluetooth LE Channel Sounding (CS) API. My target is to support multiple initiators connected to a single reflector, all of them receiving frequent distance updates.

What I have so far

• Hardware: Custom pcb with me54bs01 by MinewSemi that runs with nrf54l15

• CS reflector application: extended advertising + GATT service with sensor data, reflector role enabled for CS.

• CS initiator application: one-shot ranging mode with bt_ras_rreq_cp_get_ranging_data, collecting and averaging distance estimates.

Current results

• With 2 initiators: works quite well. Both get regular, good-quality distance estimates, with only rare step parse errors.

• With 3 initiators: all can connect, but distance updates become slow and I see many failures in the initiator logs:

  • Get ranging data failed (err -16)

  • Tried to parse empty step data

  • Report quality not OK

• The net effect is that distances arrive only sporadically, and initiators often reuse stale data.

My questions

1. What is the recommended architecture for multi-initiator deployments if the goal is fast updates (low latency)?

   • Should the reflector always time-share (round robin) like I, or is there a better built-in mechanism for handling multiple concurrent initiators?

2. Are there controller scheduling limits that make 3+ initiators impractical at present?

   • Is there a safe minimum slot / guard time you recommend between enabling/disabling procedures?

Summary

I’ve successfully demonstrated 3 simultaneous initiators, but with poor update rate and lots of step failures. With 2 initiators it’s stable. I’d like to know if there are best-practice guidelines or reference designs for scaling this up to support more initiators while still getting frequent, reliable distance updates.

[Fhar]

Hello Thanos,

I just wanted to ask you about the changes you made to the Nordic sample to connect two initiators. I’m trying to do the same, but I can’t seem to get data from both initiators — only from one at a time, after resetting one of them.

Thank you very much for your help!

[Andygb40]

I’m also looking into the possibility of connecting multiple initiators to one reflector. I haven’t made a lot of progress as yet, so was wondering if anyone here would be able to share some insight or code they have on how to manage the connections. 

[Edvin]

Hello,

This very much depends on how you set up your devices. What devices that are battery powered vs. mains powered. How often do you plan on updating the measurements, and so on.

Perhaps you can give a brief explanation on what sort of use case you imagine. One-to-many? Many-to-many? Which devices has the smallest battery? And how often do you plan on taking new channel sounding measurements?

Best regards,

Edvin

[Andygb40]

Hi Edvin, the devices would be in a one to many configuration where the one is the reflector. The maximum number of initiators planned is five, I’m not concerned about battery life at present as I already get a week and we only want one day of use between charges. The update frequency can be quite slow, maybe each device updating every two to three seconds. 
Thanks

Andrew

[Edvin]

I can't guarantee that you can manage every 3 seconds for each initiator.

It is a good idea, in this case, that you have many initiators and only one reflector. This distributes the CPU payload among the 5 initiators, instead of having the tracked device handle it all.

One recommendation that we have is that you consider making the reflector the BLE central in the connections. This way, the reflector/central will have control of all the connection timings, and you are much less prone to BLE timing issues. The initiators/peripherals can still initiate the channel sounding measurements. 

So the first task would be to flip around on the default peripheral/central behavior. 

Please see the application that I uploaded in this reply from the 11th of September, which does pretty much that. Then the next task would be to add more peripherals and have them connect to the same central.

Best regards,

Edvin