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.

[Sigurd]

Hi,

Are you getting any asserts or error messages printed over the UART, on either scanner or advertiser? 

You mentioned that you are using 2 nRF52840-DK, is the nRF52832 also a Nordic DK?

cxz said:

Is there a regulatory limit on how long it is possible to transmit on a specific channel?

No, you should be able to advertise for an unlimited amount of time. (set APP_ADV_DURATION to 0)

cxz said:

And does the nRF sniffer v2 beta 3 support BT5 completely?

I don't think it currently supports extended advertising.

cxz said:

We would also like to know what scanning issues were fixed in SoftDevice 6.1.1?

Looking at the release notes, an issue where the SoftDevice could assert when receiving long packets during extended scanning was fixed in v6.1.1. Could you test with the  v6.1.1 on the nRF52832 also?

[cxz]

Hi Sigurd,

We are not getting asserts or error messages printed over UART since we are using our own protocol. The JLink RTT viewer shows normal NRF_LOG_INFO output (none in the case of no received packets).

The nRF52832 was with our own hardware, but we have verified that it happens on the nRF52832 DK with the RSCS example.

Do you know if there is a planned date when the sniffer will support extended advertising?

Yes we tried SoftDevice v6.1.1 on an earlier prototype of our hardware with the nRF52832 and using a DK with the nRF52832 with our application.

[Hung Bui]

Hi,

Sigurd is on vacation for 3 weeks. I will try to help with your case. 

Could you reproduce the issue with a minimum firmware so we can test here ? 
Do you see the same problem when you test with our central example, for example the ble_app_uart_c ? or ble_app_hrs_c ? 

[cxz]

Hi Hung,

Was nice to see you at the Nordic Tech Tour in Lund.

Another engineer was able to verify with the RSCS examples and I also saw the same behaviour a while ago but ignored the problem at that time and restarted the application.

We have made 2 peripheral and central examples here based off 2 other

GitHub projects:

github.com/.../NRF52840-Beacon_Scanner

https://github.com/czee/MOTAM-Beacons

The SES file will automatically load SoftDevice v6.1.1.

I haven't been able to see the same behaviour in these stripped down examples, but then again I have not run them for a particularly long time. When we see this issue occur, our application does not enter any

breakpoint in the ble_evt_handler for the BLE_GAP_EVT_ADV_REPORT event.

Thanks.

[Hung Bui]

Hi Christopher, 

Glad that we met before :) 

And I'm sorry for the late response it was due to the holiday. I have been running your example here for a few hours (4-5hours) and it still can scan and printout the advertising packets. How often do you see the issue ? Was it reproducible all the times ? 

[cxz]

Hi Hung,

With our application it was reproducible all the time and it varies from minutes to hours. Sometimes when starting 2 scanning nRF52840 DK, 1 would immediately not be receiving. I can test further when back from holidays as well.

Thanks.

[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 .