Advertise event lost

[suke]

Hello.
We scan the surrounding Advertiser (nRF52832) with the prototype Central device (nRF52832). SCAN_WINDOW = SCAN_INTERVAL = 120ms.
There is one problem. The Central device is not receiving enough Advertise signals.

Advertiser has a button implemented, and when this button is pressed, the Advertiser signal is sent 10 times at intervals of 100ms. TXpower is + 4dbm.
The distance between the Central device and the Advertiser is 1m.

In the receive event of the Central device, I check the BD address of the Advertiser and then debug print with rssi.

Even though the Advertiser sends the Advertise signal 10 times, the Central device may receive 10 times or only once.
The cause of this is under investigation. (If there were many Advertisers in the vicinity, I thought that the received event occurred frequently and was lost. Even if there were no Advertisers in the vicinity, I did not get very good results. .)

We expect to receive at least 5 out of 10 times, but is it difficult to achieve due to the characteristics of BLE?
Does anyone have any good ideas for scanning Central devices?

Thank you in advance.

[tesc]

Hi,

There might be a small potential for unlucky timings when scan window and advertising interval is close to each other, but 20 ms difference should be OK in theory. It could be an issue if one was close to a multiple of the other, or if the difference was 10 ms or less.

There are three advertising channels. All three channels are used in rapid succession for each advertising event. For the scanner, one scan window uses one channel, the next scan window uses another channel, and so on. This means if only one of the advertising channels are good, then you should expect to receive advertisements only from one out of three scan windows.

One way to investigate might be to use the nRF Sniffer. It lets you use a DK or Dongle as a BLE sniffer. Then you can see if the issue of receiving advertisements is specific to your scanner or if it is also seen by the sniffer.

Regarding the handling of the scanned advertisements, it may depend on the stack and SDK used, but if you use a lot of time handling them e.g. in an interrupt or eventhandler, if scanning needs to be restarted afterwards, you may miss a lot of time during the interrupt or event handling. What SDK are you using, and what example (if any) have you built your scanner on?

Regards,
Terje

[suke]

tesc-san
SDK is 15.3.0 / softdevice is s132 v6.1.1.
I used Flont line's Bluetooth Low Energy Protocol Analyzer to verify that the Advertise signal is okay. Analyzer was able to receive Advertises almost 10 times out of 10.
Scanner also works with Central and Peripheral multirole.
This Scanner also advertises at 100ms intervals.
Does multirole have a big impact on the Scan function?
(We plan to remove the peripheral function and check it.)

In the Advertise reception event, the minimum processing (BD address confirmation and print ()) is performed.
However, I understand that if there are a lot of Advertisers around the Scanner, a lot of receive events can cause the desired Advertise to be lost. For example, is it possible to raise an event only when an Advertise with a specific BD address is received?

Thank you.

[tesc]

Hi,

If you use both central and peripheral roles, then the SoftDevice scheduler will not be able to schedule a 100 % duty cycle scanning. It will also have to schedule peripheral activity such as advertising and connection events. If you act as central in a connection in addition to the scanning, then central connection events will also be scheduled. Only one type of radio event can be scheduled for any single point in time. When multiple roles are used concurrently, only one role gets the radio at a given time, and the different roles alternates on who gets the radio.

The SoftDevice schedules events by checking if they overlap with already scheduled events. If they overlap, there is a priority system for which event to schedule and which event to drop. Events will always either fully run, or they will be fully dropped. If the same device have 120 ms scan windows with 120 ms scan interval AND 100 ms interval advertising, then all scan events and all advertising events will collide with at least one event of the other type. I would therefore expect around half of the events to be dropped, both for advertisements and for scans.

You can read more about the SoftDevice scheduling in general, and SoftDevice timing-activities and priorities in particular, in the SoftDevice Specification.

Regarding event filtering, the usual method in the SDK is to filter on e.g. address after receiving the event. This should usually work fine. There is an option of using a whitelist in order for the BLE stack (SoftDevice) to do the filtering, but it does add some complexity and there should not be much overhead in doing the filtering in the application (if any overhead at all.) Printing could take some more time, but that should also have very little impact. What you see is most likely that the SoftDevice is told to schedule more than 100 % of radio time for various roles, and therefore a high number of radio events dropped as it is impossible to schedule them.

Regards,
Terje

[suke]

tesc-san

Thank you !