How is the period for channel sounding results determined?

[witc]

Hi,

I have run the example in ncs 3.1.0 for CS_RAS_Initiator and compared to the older version ncs 3.0.1, there is a new flag called realtime_rd. Thanks to this, I can get new distance measurement data every 250 ms, which is great.

I took this example and put it into my other project, where I have more tasks. CS measurement works there too, but now instead of every 250 ms, I get results only once every 750 ms.
I am interested why my period is 3x slower, even though the CS procedure settings are exactly the same (procedure_params + config_params). I do have a few extra tasks, but they do almost nothing, so I do not think they are slowing down the MCU so much that it cannot keep up.

Do you have any tips what to focus on please? Maybe some conflict with my prj.conf ?

Thank you very much.

[Elfving]

Hello,

I know at least that previous versions of CS (not sure if this has been addressed in 3.1) where a bit vulnerable to scheduling conflicts - so even though you might be doing a lot, if you had some BLE activity at the wrong time it might be enough to block something that SDC would need to do a CS measurement. Though I find it odd that you get regular measurements every 750ms if that was the case. Is the other minimal actions you are doing the nRF semi-regular as well? Are you seeing anything on the logs, or on the thread viewer in VSC? Could be that there is something blocking that is showing up there.

Regards,

Elfving

[witc]

Hello, right now I really do not know what could be causing it - from BLE I only use channel sounding - as it is in the ras initiator example. I will probably have to make the whole project again - start from the ras example and slowly add my code to it.

[Elfving]

That might be an idea, though let's not go to that step yet. Could you check if you do see this in the default samples as well?

And what samples are you referring to here? The ones from the NRF repo, or the zephyr ones?

Regards,

Elfving

[witc]

I am using VSCode - creating app from sample - see the picture. I am using ncs 3.1.0. Or do you suggest using a different example? Did you mean github nrfconnect/sdk-nrf?
https://github.com/nrfconnect/sdk-nrf/tree/main/samples/bluetooth/channel_sounding_ras_initiator

Elfving said:

Could you check if you do see this in the default samples as well?

Default samples: When I edit - replace in the main k_sleep(K_MSEC(5000)) by a semaphor - that signals the new ranging data are ready - I get it (new distance measurement) every 250 ms

[witc]

Hi Elfving  do you have any suggestion for me?

Thank you.

[Elfving]

Sorry about the wait Jan

Unfortunately I have to get back to you on this next week.

Regards,

Elfving

[Elfving]

Hi again,

witc said:

I am using VSCode - creating app from sample - see the picture. I am using ncs 3.1.0. Or do you suggest using a different example? Did you mean github nrfconnect/sdk-nrf?

No those are the right ones, which you can tell by them having nrf in the path names. Those are made directly from nordic, with nRFs in mind. There are other ones under 'zephyr' that might also be made by nordic, and work for nordic devices, but might not be completely supported or tested. 

So as this seemingly works in the default samples it might be an idea to slowly introduce your own code to see where something ends up delaying the measurements. Though I am surprised that anything would make a difference here besides longer BLE related tasks.

Regards,

Elfving

[witc]

Hi, 

The mystery of slower response when getting new CS data in my code compared to the original is solved.
I had different connection parameters for the BLE link – that was the whole reason.

I used:

.conn_param = BT_LE_CONN_PARAM(80, 120, 1, 100), // 50-75 ms interval, slave latency 1, timeout 1 s

The original uses:

.conn_param = BT_LE_CONN_PARAM_DEFAULT