peripheral advertisements not seen by central in NRF SDK 17.1.0

[michael01]

Hi! I'm running into a strange issue.

I have inherited this project and it is poorly commented. 
I have 2 peripherals and 1 central. The 2 peripherals are identical devices. 
The central can pair to one at a time. 

When I swap between devices, such as 

* pair peripheral 1

* turn on peripheral 2

* Put peripheral 2 into pairing mode

* Power off peripheral 1

The central pairs to each successively as intended. I keep repeating this 4-5 times.
Eventually I get into a state where the central will not see the advertisements from a device, yet I can see them in NRF Connect, including custom data. It seems as if nrf_ble_scan_connect_with_target is not being called.

Sometimes, If I am in this state and turn on the other device, it will connect and I will see the advertisements from the device that the central was not seeing before (but NRF connect does). 

I notice I do have NRF_BLE_SCAN_FILTER_ENABLE set to 1 and NRF_BLE_SCAN_NAME_CNT set to 2. 

I would not expect this to fail after working so many times for each device, but I am grasping at straws. 
These filters should behave the same the entire time and not just change after a few pairs/disconnects/new pairs. 

My application is not keeping count and is always scanning. Could this be a known issue with the SDK? 

[Einar Thorsrud]

Hi,

I have some questions in order to understand more:

1. Do you use bonding or only pairing?
2. Do you use whitelisting?
3. Does it always follow the same pattern, where it takes the same number of repeats before it fails?
4. Once it has fails, how do you recover? Is it enough to reset the central device, or do you need to erase and re-program it?
5. You write that nrf_ble_scan_connect_with_target() is not being called. Have you learned more from debugging or logging? I am particularily interested in if nrf_ble_scan_on_adv_report() in components/ble/nrf_ble_scan/nrf_ble_scan.c is called so that the advertising packet is received, or if it is filtered out ealier (by the Bluetooth stack)

[michael01]

One other detail I can think of, when I turn on the previously paired device, it uses Targetted/Directed Advertising.

(BLE_ADV_MODE_DIRECTED_HIGH_DUTY)

[Einar Thorsrud]

Hi,

michael01 said:

Is there something different about targeted advertisements?

The central still has to be scanning correct? 

Yes, the central still has to be scanning. But the SoftDevice will filter out directed advertising packets that is for other devices. Is your device by any chance using a resolvable address, and changes address at this point, so that the peripheral using directed advertising could be using directed advertising to it's old address?

[michael01]

Resolvable address - no

To clarify, the device that is NOT using directed advertising is the one that the central isn't seeing. 
One of the recovery methods is to power up the device that is using directed advertising, which then seems to enable the central to see the other device's undirected advertisements.

[Einar Thorsrud]

Hi,

I see. I have read over this thread again to see if I mave missed something, and noticed a few things:

1. when I asked about whitelisting you stated no, and that filter policy is set to accept all. However, that is two separate features. Whitelisting is performed by the SoftDevice and not the Scan module. So can you double check that witelisting is not used? (For reference, you can se an example of whitelisting in a Central role in examples/ble_central/ble_app_rscs_c/main.c).
2. You confirmed that you see no calls to nrf_ble_scan_on_adv_report() before you start the "other" device. Are there no other devices advertising within range (anything, not related to your test setup, but just as long as not testing in an RF chamber)? If there were, I would expect you to see calls to nrf_ble_scan_on_adv_report() for them as well. If you only see this after powering on the other device, that could also point to whitelisting being active and only allowing this device at that time.
3. Regarding the last point, could it be that the central for some reason is put in a state where whitelisting is enabled, and then after the whitelisted device connects, it from that point scans without whitelisting?

In sum, the behavior you are describing can match the central enabling whitelisting for scanning for some time (why?), and then after the whitelisted device connects, whitelisting is disabled. This is just an hypothesis, but I am not able to find any other based on this information.

[michael01]

Thanks Einar. 

1) I just ran the central in the debugger, is_whitelist_used(p_scan_ctx)) always returns false. I dont see this application calling nrf_ble_scan_params_set manually either. The scan event handler does not have any whitelisting support either. I don't see anything calling pm_whitelist_get either. 

2) I will retest this with the RTT logging I owe you. It does look like we're using the scan filter for adv name, however that happens within nrf_ble_scan_on_adv_report

3) could this change at runtime somehow? is there some peer manager config that magically enables whitelisting? Are there any filtering examples I can look at ? 

[Einar Thorsrud]

Hi,

The whitelist can be enabled and disabled as well as updated runtime. But that would then involve (re)starting scanning with the filter_policy set to BLE_GAP_SCAN_FP_WHITELIST or BLE_GAP_SCAN_FP_WHITELIST_NOT_RESOLVED_DIRECTED. Which do you use? Note that this is different from the filter in the scan module, this is filtering in the SoftDevice (referring to examples/ble_central/ble_app_rscs_c/main.c as an example again, you can see her e it is set in m_scan_param and if you search for "filter_policy" you can see that this sample sometimes use that and sometimes use BLE_GAP_SCAN_FP_ACCEPT_ALL (which means no whitelisting is used). Do you have something similar in your application?

If this is not it, then more logs and debugging will be needed to understand more. It could also be interesting to have a look at your application if you can share it (you can make a private ticket and upload it there, and refer to this thread).