BLE first scan event starts with a delay (nRF 52832)

RE: BLE first scan event starts with a delay (nRF 52832)

Susheel Nuguru — Mon, 23 Jan 2023 14:03:39 GMT

[quote user="hector77"]

On question 3), this will mean that the effective advertising (TX) on a specific channel will start some 1.5 ms after the radio notification + distance ? Would you know if it if possible, by timing the advertising more precisely, to overlap them a little bit (say 1ms) across different devices in order to send a maximum of advertisings in a limited scan time (obviously on another device) ?
And that would bring me to the same timing delay on the scan side: what is the time between end of radio notification + distance to the actual start of RX ?

Thanks a lot for you help.

[/quote]

Sorry for very late reply hector, I was away.
I do not see the exact number for the distance you are seeking but there are some estimates that you can find here. Also these numbers may vary between different softdevice versions.

If you want to the exact numbers then it should be possible to toggle a gpio pin at the entry of radio notification and also set a GPIOTE connection to convert the radio start trigger task to another pin toggle and check the distance in the logic analyzer or oscilloscope.

RE: BLE first scan event starts with a delay (nRF 52832)

hector77 — Tue, 10 Jan 2023 14:46:06 GMT

Dear Susheel,

Thanks a lot for the investigations on the scan delay.

For step 1) and 2), I made no progress yet, and I don't really know where to head next. Any ideas to explore?

Thanks a lot for you help.

Best regards,

RE: BLE first scan event starts with a delay (nRF 52832)

Susheel Nuguru — Thu, 05 Jan 2023 07:44:48 GMT

Hi Hector,

Step 1)

I tried to run the blinky central sample as it is (both debug and release version) using SES project. It looks to run ok for me.

Step 2) no error here as wekk.

Step 3) I am able to replicate this, not sure why we see this but it seems like asking for a scanner timeslot for a longer interval seems to set the anchor point after one interval. Maybe this is a way for the softdevice to make sure that longer slot commitments just after the softdevice initialize might not be promised from the timeslot management module.

I will have to do some more investigation to see if the Radio Notifications are causing this, but it is a hard debugging path to verify the scanning first anchor point distance without notifications enabled.

[quote user="hector77"]question 3 : browsing through the (very nice and useful) Online Power Profiler for Bluetooth LE, we would have a follow-up question about the time reference used in radio events. For instance, a 5.5m distance refers to which point exactely on the chart displayed in the Profiler, for Radio event (active : 1) would that be «Pre-processing» stage, «Start radio» or «Radio Tx» ? Same for active : 0, end of «Radio Rx» or end of «Post-processing» stage ?[/quote]

It is a preprocessing stage for the application to do pre steps needed before starting the radio activity.

Happy New year to you too Hector.

RE: BLE first scan event starts with a delay (nRF 52832)

hector77 — Wed, 04 Jan 2023 14:29:53 GMT

Hi,

No problem for the delay, same here.

To answer your questions : we do not use Thread and started simple by working with SDK example. Below a detailed explanation of the steps taken so far :

One device is advertising with about 200 ms interval.

The other device is scanning, for that we use an example from the SDK as mentioned in the original post. To test further, we went one step backward and run that example code on an nRF DK board (ie, away from our own hardware, just to make sure). With this setup, here is what I do :

Step 1. Run the example blinky as is on nRF DK board:

log :