BLE scanning issues with SoftDevice 6.1.0

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Wed, 16 Jan 2019 12:55:13 GMT

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

RE: BLE scanning issues with SoftDevice 6.1.0

Hung Bui — Wed, 16 Jan 2019 12:48:57 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Tue, 15 Jan 2019 12:21:53 GMT

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?

RE: BLE scanning issues with SoftDevice 6.1.0

Hung Bui — Tue, 15 Jan 2019 11:58:42 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Tue, 15 Jan 2019 09:54:49 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

Hung Bui — Tue, 15 Jan 2019 09:52:32 GMT

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 .

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Mon, 14 Jan 2019 14:27:45 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

Hung Bui — Tue, 08 Jan 2019 08:47:46 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Sat, 29 Dec 2018 06:32:35 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

Hung Bui — Sat, 29 Dec 2018 03:31:40 GMT

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 ?

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Fri, 21 Dec 2018 21:52:40 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

Hung Bui — Wed, 19 Dec 2018 11:16:56 GMT

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 ?

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Mon, 17 Dec 2018 15:14:24 GMT

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.

RE: BLE scanning issues with SoftDevice 6.1.0

Sigurd — Fri, 14 Dec 2018 16:35:57 GMT

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?

[quote userid="73213" url="~/f/nordic-q-a/41470/ble-scanning-issues-with-softdevice-6-1-0"]Is there a regulatory limit on how long it is possible to transmit on a specific channel?[/quote]

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

[quote userid="73213" url="~/f/nordic-q-a/41470/ble-scanning-issues-with-softdevice-6-1-0"]And does the nRF sniffer v2 beta 3 support BT5 completely?[/quote]

I don't think it currently supports extended advertising.

[quote userid="73213" url="~/f/nordic-q-a/41470/ble-scanning-issues-with-softdevice-6-1-0"]We would also like to know what scanning issues were fixed in SoftDevice 6.1.1?[/quote]

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?

RE: BLE scanning issues with SoftDevice 6.1.0

cxz — Tue, 11 Dec 2018 13:42:50 GMT

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

RE: BLE scanning issues with SoftDevice 6.1.0

gsegment — Tue, 11 Dec 2018 13:39:52 GMT

Hi,

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