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
-
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?
-
-
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.
