BLE scanning issues with SoftDevice 6.1.0

[cxz]

Hi,

We are currently in a testing phase of our software where we use an nRF52832 for extended advertising and an nRF52840 for scanning that has a scan interval and scan window of 10ms. The scan duration is infinite and we are connectionless.

After a period of about 1 hour or so, we will see that the nRF52840 will not be receiving any BLE packets or will miss packets entirely. Waking up from SYSTEM ON using button interrupts in our nRF52832 will cause the nRF52840 to start receiving packets again intermittently. We hypothesize that this 'reactivates' the SoftDevice on the nRF52832. Both devices are running SoftDevice 6.1.0, but we have tested with 6.1.1 on the nRF52840 and the problem persists. This is also the case with the RSCS SDK example. See something like this for reference: https://github.com/nicslabdev/NRF52840-Beacon_Scanner

In addition, if we set up 2 nRF52840 DK boards and reset the nRF52832, we may see that one nRF52840 will receive packets and the other nRF52840 will not. Is this a possible bug in the SoftDevice or is this something related to the channels in which BLE is communicated? Is there a regulatory limit on how long it is possible to transmit on a specific channel?

We would also like to know what scanning issues were fixed in SoftDevice 6.1.1? And does the nRF sniffer v2 beta 3 support BT5 completely? We cannot see any of our packets in Wireshark.

Thank you.

[gsegment]

Hi,

Are you sure that scanning process wasn't interrupted or stopped by software? 

[cxz]

Yes, we're sure. It's in continous scanning with the main thread writing to UART.

[Hung Bui]

Hi Christopher, 

I have been running the test (PCA10056 DK for scanning, PCA10040 for advertising ) overnight and they still working fine. I would suggest to test again in a different environment and/or different DK boards for reference. 

[cxz]

Hi Hung,

With a fresh look at the code after the new year I found that I had missed something subtle:

#define SCAN_INTERVAL 0x0010 /**< Determines scan interval in units of 0.625 millisecond. */
#define SCAN_WINDOW 0x0010 /**< Determines scan window in units of 0.625 millisecond. */
#define SCAN_DURATION 0x0000 /**< Duration of the scanning in units of 10 milliseconds. If set to 0x0000, scanning continues until it is explicitly disabled. */

static ble_gap_scan_params_t m_scan_param =
{
.active = 0,
.interval = NRF_BLE_SCAN_SCAN_INTERVAL,
.window = NRF_BLE_SCAN_SCAN_WINDOW,
.filter_policy = BLE_GAP_SCAN_FP_ACCEPT_ALL, 
.timeout = SCAN_DURATION,
.scan_phys = BLE_GAP_PHY_1MBPS,
.extended = 1,
}

I had set the scan interval and window to be 10ms, but it would never use these values. It would use the SDK values: 160 and 80, corresponding to 100ms and 50ms. Our application seems to run fine so far now that I have changed the params to use the defines, however I wonder if you have any insight as to how this could affect the receiver using the old values? Our transmitter was transmitting at 400ms:

#define INTERVAL MSEC_TO_UNITS(400, UNIT_0_625_MS)

ble_advertising_init_t init;
init.config.ble_adv_fast_interval = INTERVAL;

Thanks.

[Hung Bui]

Hi Christopher, 

Could you clarify, you mean after you switched to 50/100ms then it worked fine or keeping it at 10/10ms made it work ? 

In the source code you provided (and that I used to test here) it was 10/10ms was used . 

[cxz]

Hi Hung,

Sorry for the confusion. Yes, when we switched to 10/10ms and it worked fine. Previously we were not using these defines. As you can see it was NRF_BLE_SCAN_SCAN_INTERVAL and NRF_BLE_SCAN_SCAN_WINDOW.

In the source code I provided on GitHub it was an example application that was running as expected. But the code I pasted in the comment yesterday was from our actual application.

[Hung Bui]

My suspicion is that due to the duty cycle of 50% and since your scanning interval is an factor of the advertising interval, when the clock is drifting long enough (can take hours), the advertising will only happen in the non-scanning window and then results in that you can't capture the advertising package. 

When the issue occurs, if you reset the beacon(s) would you see the scanner working again ? 

I would suggest to have another beacon advertising with different interval, for example 30ms just to make sure the duty cycle would not be the problem here.  

[cxz]

Hi Hung,

My thoughts were something along these lines also, but are we saying that scanning with a 100/50ms interval/window and a 400ms advertising interval, this would 'correct' itself over a matter of time? On a related note, doesn't this also mean that with a duty cycle of 100% 10/10ms this would still happen, but on a tiny and unnoticable level such that clock drift becomes in sync?

Yes, when we reset the beacons these would show up on the scanner. Sometimes starting/resetting the scanner would result in no packets received. Would this mean that we started it in a non-advertising window?

[Hung Bui]

Actually BLE protocol has a solution to mitigate this issue as each advertising event would have a random delay (<10ms) to avoid being insync. But this wouldn't help if we have a gap of 50ms of not scanning. 

[cxz]

Ok, thanks! We can mark this as solved then.