Help with the nrf52 dev board, tag scan and channel frequency

[kaplacat]

Hi everyone,

I have some questions / problems about the advertising report in the nrf52832 dev board. I'm using the example code from here : https://github.com/NordicSemiconductor/pc-ble-driver/blob/master/examples/heart_rate_collector/main.c. I check the data in the on_adv_report function.

I want to test that the data send by my own tag are correctly received and understand by the board. To do this stuff, I connect the antenna of my tag directly to the nrf antenna pin and I isolate the nrf board and tag to all the potentials tags around the test.

My tag send 1 data each second on each BLE channel (3 channels). With the code above, I just check if the datapackets are correctly received and descreen. I also measure the time between each reception. 

My problem is here : During 10-15 seconds I got the data send by the tag each seconds (so it's okay), and after during 10-15 seconds I don't receive the tag. This pattern repeats itself.

I tried to do some others test. I change the firm of the tag in order to send a data each second but on just 1 channel. And the result is that the board receive a data each 3 seconds (with the same "radio break" duration -> 10-15s). Is it normal? The nrf switch the channel each second ? 

I also did an other test : I say to my tag to send data each 0.5s and the result is the same for 1s of emission but the duration of the previous pattern is divide par 2. So all it's okay during 5-7 seconds and after I received anything during 5-7 seconds.

The purpose is to be sure that the tag send correct data. But I want to be sure that the nrf can receive all the data correctly. 

So the problem is on the dev board or on my tag? To answer it I need to know if this "radio break" is caused by the dev board or by my tag.

Thanks

[tesc]

Hi,

The "radio break" happens because scan windows and advertising events are almost synchronized but slightly drifting relative to each other. Let me explain.

The default scan parameters in that example, is SCAN_INTERVAL of 0xA0 and SCAN_WINDOW of 0x50, which means scan interval of 100 ms and scan window of 50 ms. That means the scan will happen like this:

50 ms scanning on channel 37 (one scan window)
50 ms no scanning (waiting for next scan event, new scan event each scan interval)
50 ms scanning on channel 38
50 ms no scanning
50 ms scanning on channel 39
50 ms no scanning
repeat from top

For advertising, in addition to the advertising interval, there is a random extra delay of 0 to 10 ms between advertising events. That means, on average, with advertising interval of 1 s, you get 1005 ms from one advertisement to the next. Each advertising event sends the advertising packet on all three advertising channels in rapid succession.

The scan interval (100 ms) perfectly divides the advertising interval (1000 s), but then the 5 - 10 ms random delay comes on top of that. This means, relative to the scan window, an advertisement is sent 5 ms later each time, on average. After a few advertising intervals, it has drifted out of the scan window (and now advertisements are sent during the pauses between scan windows.) After having drifted 50 ms more, i.e. around ten advertisements (ten seconds) later, you should expect it to have drifted into a scan window again, and will receive advertisements until drifting out of the scan window.

If you use half the advertising interval, you still get 5 ms average random addition to each interval, which means the drifting relative to the scan windows happens at double the speed.

In order to detect most advertisements, you can change the scan window to equal the scan interval. Then you will scan at 100 % duty cycle (instead of 50 % duty cycle as you do now).

Regards,
Terje

[kaplacat]

Thanks for the explanation, I understand how it works. 
I change the scan window (as you said) to equal the scan interval and it works perfectly. I can continue my tests thanks to you.

Regards