several initiators and reflectors can't work simultaneously

[RTT EUROPE DOO]

Hello! Some time ago we bought your NRF54L15 dev kit 0.9.1. ( for channel sounding BLE6) with an aim to make a product for staff positioning at underground mines. For this purpose we use an NRF connect SDK 3.1.1 and we made tests which showed that the initiator is working just with one reflector. What we need is to have at the first stage one initiator and several reflectors and in in the future would like to use several initiators and several reflectors working simultaneously. So our question is how soon we can get an SDK from you which can allow us doing this functionality. Thanks

[Edvin]

Hello,

In your multi reflector -> one initiator setup, do you have any thoughts on how often you need positioning data, and how to transfer the positioning data from the different nodes to a central location (I guess you want to keep track of all workers in a central location).

The reason I ask is that I imagine that you will have multiple reflectors placed around in the area, and one tag that you want to track. Is this tag battery operated? Is battery life a concern? 

One alternative method to do this is to have all the stationary devices (which are possibly non-battery powered) act as the initiators, and the tag that you want to track can act as the reflector. This means that the stationary devices will end up with the distance measurements, but it is also a lot less CPU-intensive for the moving tag, which would use less power. However, in this case, it is recommended to switch over the roles, so that the tag is now a reflector in channel sounding, and the central in the BLE connection. This way, it uses less time per Channel Sounding (CS) sample (because it is the reflector, and doesn't do the heavy calculations), and it has less packet loss, because it handles all of the timings in the connections (because it is the BLE central). 

I think this also scales ok when you introduce multiple tags (reflectors). But it all depends on how often you need the updated position.

And as I briefly mentioned, how do you plan to gather up the information and send it to a central location? From the stationary devices or from the moving devices?

So our question is how soon we can get an SDK from you which can allow us doing this functionality.

This should all be possible in the current SDK (v3.1.1), but we don't have any samples for multi-connection channel sounding. At least not at this point in time. It may be that we will have it at some point in the future, but I don't know when/if this is planned. If this is a request, that is something we need to take through our Sales Department. Let me know if you want the contact information to our Sales Representative in your area. In that case, send me a direct message here on DevZone, let me know what country you are located, and include a link to this ticket.

Alternatively, let me know what you think about the roles of the stationary and the moving devices, and how you plan to move the data out of the mines. Also, which devices are battery powered, and which ones are mains powered?

Best regards,

Edvin

[RTT EUROPE DOO]

Hello Edvin!

Thank you for answer. Our plan is to use stationary (non-battery) device as Initiator, and tags (battery devices) as Reflector. I am afraid, that we can't consider an option, with using initiator on tags, because we need to store calculations on stationary devices. Moreover these measurements can affect on battery life.

Globally, multireflector system works, but we need to reconnect to device each time and it takes a lot of time (Firstly, by intiator we connect via bluetooth to reflector, then do CS procedure, after that do distance calculations, then disconnect from reflector, then initiator repeat all steps for next reflectors).

Our goal task, to achieve fastest measurements between one initiator and multireflectors.

[PaKa]

Note that what Edvin said is you use the movable devices as reflector to save power BUT you make them the central, this as the central controls the timing so you will have a lot less collisions compared to using the movable as a peripheral. In the latter each of the static devices will set it's own scheduling and the then it is more or less guaranteed you will get scheduling conflicts. Note that if you have more than one moving device then you will also have to deal with scheduling conflicts.