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.

[PaKa]

Make the reflector the central and the initiators the peripherals. This allows the reflector to handle the scheduling of all the links so less likely to have overlaps and lost packets due to this.

[Thanos Vasiloglou]

Do you have any updates on my problem ? 

[Edvin]

Hello,

Just to be clear,

You want to measure the distance between one moving device and 3 stationary devices, right?

In that case I suggest what PaKa  says. Make the moving device the central in the BLE connection, and also the reflector. The reason for it being the central is so that it controls the timing of the BLE connections (which would not be the case if it was the peripheral in the connection). The reason it is the reflector is because it is a simpler task, not requiring so much CPU time. This way it would spread out the workload on the stationary devices, which only needs to keep track of one distance each. It will also save power on the moving device,  as this is most likely battery powered (where the stationary devices could be mains powered?)

Best regards,

Edvin