Scanning of Extended Advertising

[axel_s]

Hi,

I currently do some advertising tests with Nordic's nRF52840-DK and Zephyr. I have one board doing extended advertisements, one transmission every second. By means of a sniffer I can clearly verify that this board is doing well. And I have a second board with a simple scanner, which simply uses the .recv call-back to print the data and a timestamp. Running this scanning device, I see that there are several (3..5) consecutive advertising events printed correctly, followed by a gap of 3..5 seconds, again 3..5 consecutive events ok, and so on. What could be the reason for such frequent gaps? What could I do to receive all advertisement data correctly?

Two more questions here:

1. Up to now I couldn't find any explanation of what exactly the scan interval and scan window in struct bt_le_scan_param are used for. Which time resp. interval is set by these parameters?

2. Is it possible to limit the scanning functionality to one or two of the advertising channels, somehow complementing the options I can set in the advertiser (BT_LE_ADV_OPT_DISABLE_CHAN_37/38/39)?

Best regards

Axel

[Edvin]

Without having tested this now, I suspect that the 3..5 second gaps that you see are caused by a mismatch in the advertising and scanning parameters. 

You can read a bit about advertising intervals, and scan window and intervals here:
Bluetooth Smart and the Nordic's Softdevices - Part 1 GAP Advertising

2:
While it is possible, I don't really see any benefits restricting the advertising or scanning to only one channel. The scanner will scan on one channel for the entire scan window, and the advertiser will advertise on all 3 channels every advertising interval. I suggest that you first look into your scan parameters.

What you typically want to look out for is that advertisements continuously end up in the "non-scanning" part of the scan interval. Imagine if you have a scan window of 50% of the scan interval, the advertising interval is set to 1 second, and you set the scan interval to 1 second.

In this case, you may end up with a scanner that will not see any advertisements, because the advertisements arrive when the scanner is not scanning. Setting the scan interval to 1.5 seconds will make sure that you don't end up with a lot of advertisements being missed in a row. 

NB: Peripherals will send out an advertisement packet on all 3 channels (in a burst) every connection interval + 0-10ms. This 0-10ms random delay is added according to the Bluetooth specification. The reason for the 0-10ms random delay is to prevent the issues related to this post. To add drift to the advertising interval so that they avoid that some scanners will not see particular advertisers.

Also, if you want to, you can set the scan window equal to the scan interval. If you are not using the radio for anything else (if you are not in a connection already), that should be fine as long as you are aware that it also consumes more power. You can at least test this for debugging purposes.

Best regards,

Edvin

[Yin Hinton]

Slightly unrelated question, What are you using for your scanner? My company is working on a similar application but is hitting a hiccup on finding a viable scanner for extended advertising purposes.

[axel_s]

Hallo,

as I wrote above - I use nRF52840-DK for both the advertiser and the scanner. Edvin pointed exactly to the issues I was looking for. It's running now, and I can tell you that when scanning all the time (i.e. scan_interval = scan_window) the devices are able to follow also fast traffic.

Kind regards

Axel

[Yin Hinton]

Ahh, I see. Thank you for clarifying. If you dont mind my asking, is your set up running windows or some other os like linux?

[axel_s]

I use Linux (Ubuntu 20.04).