BLE Scanning Implementation Inquiry

RE: BLE Scanning Implementation Inquiry

Einar Thorsrud — Thu, 18 Jan 2024 15:17:37 GMT

Hi,

The code you refer to is from the SDK scan module, and that always use the same scan buffer. So it will be overwritten by the SoftDevice. That should not be a problem in practice tough as the way it is implemented in the scan module the event handler (callback) is called before restarting scanning.

If you want to restart scanning immediately before any filtering you can do that, but then you have to skip the SDK scan module and use the SoftDevice API's directly. In that case, you can cycle through several scan buffers that you handle, and provide the buffer when you call sd_ble_gap_scan_start().

RE: BLE Scanning Implementation Inquiry

Parker Lloyd — Tue, 16 Jan 2024 19:07:53 GMT

In other words, what happens to the scan buffer when a new advertising report starts getting received but is not yet fully received?

RE: BLE Scanning Implementation Inquiry

Parker Lloyd — Tue, 16 Jan 2024 19:00:30 GMT

Hi Einar,

Thanks for your response.

For the older nRF5 SDK, there is only one buffer for storing advertising reports. The length of this buffer is defined in the the sdk_config.h (NRF_BLE_SCAN_BUFFER) and is referenced in nrf_ble_scan.c (line 1094) :

// Assign a buffer where the advertising reports are to be stored by the SoftDevice.

p_scan_ctx->scan_buffer.p_data = p_scan_ctx->scan_buffer_data;

p_scan_ctx->scan_buffer.len = NRF_BLE_SCAN_BUFFER;

Do the contents of this buffer get copied out during processing by the scanning module? I am mainly interested in whether this scan buffer can asynchronously receive a new advertisement if scanning is enabled while the previous advertising report is still being processed.

In simpler terms, does the nRF5 SDK scanning module store 2 advertising reports at once if scanning is enabled while an earlier report is still being processed?

Your help is greatly appreciated.

Parker

RE: BLE Scanning Implementation Inquiry

Einar Thorsrud — Fri, 12 Jan 2024 08:15:56 GMT

Hi Parker,

Yes, that parameter is for the nRF Connect SDK only. For the nRF5 SDK with SoftDevice it is different and there is no similar functionality. There scanning is stopped by the SoftDevice when an advertising packet is received, and it is up to the application (either directly or via the SDK scan module) to resume scanning.

RE: BLE Scanning Implementation Inquiry

Parker Lloyd — Thu, 11 Jan 2024 18:20:44 GMT

Our firmware project was developed using the nRF5 SDK (v17.1.0).

The sdk_config.h does not appear to include a parameter analogous to BT_CTLR_SDC_SCAN_BUFFER_COUNT. After looking deeper into components/ble/nrf_ble_scan/ the implementation appears to only use one buffer.

Is this functionality only supported by the newer nRF Connect SDK?

Parker

RE: BLE Scanning Implementation Inquiry

Parker Lloyd — Thu, 11 Jan 2024 17:28:30 GMT

Perfect thanks. That's exactly what I needed.

RE: BLE Scanning Implementation Inquiry

Einar Thorsrud — Thu, 11 Jan 2024 11:30:50 GMT

Hi Parker,

The SoftDevice controller (which is the link layer) can buffer multiple packets. The nuber of buffers is configurable with BT_CTLR_SDC_SCAN_BUFFER_COUNT.

Einar

RE: BLE Scanning Implementation Inquiry

Parker Lloyd — Tue, 09 Jan 2024 17:41:13 GMT

Hi Einar,

Thanks for your response.

Just to clarify, are you saying that the scanning backend can only store the contents of one advertisement at a time? Or is it able to buffer new advertisements (to be processed later) if it is currently processing another ad?

That is mainly what I am interested in figuring out: whether the backend can store (any) new incoming ads while it is busy processing another ad.

Parker

RE: BLE Scanning Implementation Inquiry

Einar Thorsrud — Tue, 09 Jan 2024 13:01:35 GMT

Hi Parker,

You will not receive all advertising packets in a busy environment. That is because of several reasons, where these are the most important:

If advertising packets is received faster than the application can process them, the stack will need to drop som advertising packets.
Packet colissions leading to packet loss.
Re-starting scanning on a new advertising channel at the beginning of a new scan window
Not scanning at all (if the scan duty cycle is not 100%).

This means that you will always loose some (and often a high number) of advertising packets, and your system must be designed to handle that.

Einar