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.

[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

[Edvin]

Please note that DevZone will be short staffed for the next two weeks. Please expect some delayed response. I am sorry for the inconvenience.

Best regards,

Edvin