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]

Thanks Einar. 

1 - Using the peer manager to save bond info
2 - No, filter policy is set to accept all
3 - Good question, feels like it is usually around 5, but I just did 7 without failure before the debugger crashed. Maybe I will try with RTT viewer instead of full debugger. 
4 - Resetting the central device is one way to recover. Sometimes, If I turn on the last successfully paired peripheral, the central also starts seeing the advertisements again. 
5 - During the failure, nrf_ble_scan_on_adv_report is not being called. I just replicated it, didn't see the log I added in RTT, then when I fired up the previously paired controller, nrf_ble_scan_on_adv_report is called, and I can see my other device advertise. 

[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,

I see. Did you enable RTT logging, can you share the log? Also, can you make sure to log when scanning is (re)started? I wonder if it could be that for some reason under some conditions scanning is not started? (As nrf_ble_scan_on_adv_report() is not being called, no advertising packets are received even before filtering, which is a bit suspicious as you do not use whitelisting).

[michael01]

Thanks Einar. 

The scanner stays on, even after connection. 
Is there something different about targeted advertisements?

The central still has to be scanning correct? 

According to NRF connect, the peripheral that the central cannot see is advertising properly. 

I will collect logs, but I will have to manually point to where the advertisements are not being received by the central. Will follow up. 

[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?