Reset the channel sounding parameters after a disconnection

[Vinayaka KS]

Hi, I am trying to sound two reflectors from a single initiator, and since the CS works on a one-to-one ACL system, I wanted to know how I can reset the CS-related stuff in the code. I did try this without reboot, the data becomes stagnant after a reconnection or when I connect 2 reflectors (not sound, but just connect)  

The sample provided by Nordic does a soft reboot, so it works flawlessly. I am trying to take a different path of not connecting to both of my nodes at once and do a soft reboot every time I wanna switch the sounding, but I wanted to know if a manual reset was possible for the CS params and buffer, so that I can continue with sounding another device without doing a soft reboot.

[Edvin]

Hello,

This should be possible. You mention that you want one initiator and two reflectors. This will probably work, but if you are planning to have many reflectors, you may want to switch it around. You see, the main CPU usage is in the initiator, and the reflector is not doing any heavy lifting. This means that if you plan to have many stationary devices and one moving device, it may make sense to have the stationary devices being the initiators, all doing channel sounding towards the same reflector. This means that the moving device (reflector) can last longer on a smaller battery.

without reboot, the data becomes stagnant after a reconnection

What does it mean? do you get any channel sounding data from the second connection, or none at all?

Best regards,

Edvin

[Vinayaka KS]

I have found my answer and also a mistake.

bt_le_cs_procedure_enable() was returning an error because the connection would already be stale after the disconnection. Hence, I tried to run it just by resetting the buffers, but I soon faced this issue of 

W: Could not locate mandatory

On-demand ranging data characteristic E: RAS RREQ alloc init failed (err -22)

Then I started looking into my device discovery and found a problem there. I use NUS and RAS as well, so I chained their discoveries. And I was not resetting some states to do this properly.

 

Now I need to work on the multiple connections part. This whole RAS and NUS were running on the multilink_central code, so do you have any suggestions on the multiple connections and the sounding part?

[Edvin]

How many initiators and reflectors do you intend to have? And is the moving device the smaller device?

Vinayaka KS said:

do you have any suggestions on the multiple connections and the sounding part?

Not other than doing the same thing that you were already doing on one connection.

But again, you may want to consider having two initiators that are peripherals, and one central that is the reflector.

BR,

Edvin

[Vinayaka KS]

Hi Edvin,
I am actually doing my master's thesis on the implementation of this, so for the current scenario considered, it's going to be 2 moving devices with 1 stationary device.
So I am using 1 central initiator (stationary) with 2 peripheral reflectors (moving). Does this make sense in terms of power consumption footprint?
I implemented the part where I am currently sounding to 2 devices consecutively. At any given point in time, there is only 1 peripheral reflector connected to the central initiator. The problem arises as the switching (disconnection, connection, and CS parameters exchange) takes around 4-5 seconds. Is there any way I can get a better response time?
I am looking into 2 directions of solutions for this:

1) Find a way to make the CS params exchange faster (maybe store the params in flash)  - This reduces the time for CS param exchange

2) Stay connected to 2 devices, but sound only to one device - This reduces the time taken for connection and disconnection

Can I get some insights about these probable solution methods? I would also be glad to know if you have some other solution in mind.

Thanks,
Vinayaka KS

[Edvin]

I would try to get the second scenario working. There is no point in keeping connecting and disconnecting all the time. Just stay connected to both, and do channel sounding measurements on one at the time. 

When you have multiple devices, it is a good idea to have the central being the initiator (like you do), because it causes less timing issues. 

You have a function:

err = bt_le_cs_set_procedure_parameters(connection, &procedure_params);

where the first parameter, "connection" points to the connection to the reflector. If you have two connections, you need to store two of these connection pointers, and then call bt_le_cs_set_procedure_parameters() on both of them.

Best regards,

Edvin

[Vinayaka KS]

Thanks a lot, I will try implementing this now.

Regards,

Vinayaka KS