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

[hector77]

Hi, 

I am running the following example from the SDK for Thread v4.1.0: ble_central/ble_app_blinky_c, with a some minor changes (pins definition for a custom board based on nRF52832, and radio notifications enabled)

When testing the scanning window and interval, I notice that the first scan event (ie, radio notification turning active) occurs after a delay, rather than immediately after nrf_ble_scan_start(). This delay corresponds the the scanning interval.

I am aware of this note about the nRF52840: https://devzone.nordicsemi.com/f/nordic-q-a/63150/nrf52840---scan-start-delay. But the example we use in our test has no advertising, so it seems scanning should no be prevented to run because of this.

Could you please let me know if and how it would be possible to start the scanning without any delay ?

The target application I am testing will need to scan and advertise, but with advertisement data modified on the fly. For that we plan to rely on radio notification, but as it is not possible to distinguish between scan or adv in these notifications, the idea would be to use a timer to: 1 start scanning with timeout, 2. on timeout, start adv and catch the radio notification to update the data, stop after a number of adv sets. 3. cycle back to 1.

Many thanks for your help.

H

[Susheel Nuguru]

Sorry for the delayed response. We were away for year end holidays and thanks a lot for your patience.

I am assuming that you are not using any Thread related features. If there are no any other radio activity scheduled before your first scan request, then it should not have taken one scan interval delay to start the scanner. That feels strange. How are you measuring this delay? I am assuming that you are toggling some gpios in your timer handlers and radio events? 

Can you give me a minimalistic project to replicate this along with your gpio setup to toggle pins to measure the delay?

[hector77]

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 :

<info> app_timer: RTC: initialized.

<error> app: Fatal error

Step 2. Run the example blinky with a delay, just before ble_stack_init() :

log :

<info> app_timer: RTC: initialized.

<error> app: Fatal error

<warning> app: System reset

<info> app_timer: RTC: initialized.

<info> app: Blinky CENTRAL example started.

(See related question 1 below)

Step 3. Run the example blinky and add the following line just before scan_start()

radio_notification_init(); (the associated handler will just output «Radio event», as shown below)

log :

<info> app_timer: RTC: initialized.

<error> app: Fatal error

<warning> app: System reset

<info> app_timer: RTC: initialized.

<info> app: Blinky CENTRAL example started.

<info> app: Radio event (active: 1) <----Time to reach this point, from the line above (scan start command)

<info> app: Radio event (active: 0)

(See related question 2, 3 below)

The way we determine the scan start delay is just by changing the following parameter in sdk_config.h : NRF_BLE_SCAN_SCAN_INTERVAL.

With a short interval, Radio event active occurs almost immediately, but with an interval of, say, 5 seconds (1600 *5), the radio event occurs after 5 seconds.

This experiment also raised more questions, maybe they are related :

question 1 : what could be the reason we see this fatal error using the example from the SDK and a DK board ?

question 2 : is it possible that the delayed scan start is caused by the radio notification request? With regards to that, may I ask what is the expected behavior if we configure a radio even with a distance of 5.5ms, but start the scan right after ? In this case the radio event cannot occur 5.5 ms before scan (there not enough time), is this the reason why this first scan event is missed ?

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 ?

Many thanks for you kind help indeed.

Best regards, and best wishes for the new starting year !

H

[Susheel Nuguru]

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.

hector77 said:

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 ?

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.

[hector77]

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?

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.

Best regards, 

H

[Susheel Nuguru]

hector77 said:

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.

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.