peripheral advertisements not seen by central in NRF SDK 17.1.0

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

Einar Thorsrud — Thu, 19 Feb 2026 13:13:14 GMT

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).

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

michael01 — Wed, 18 Feb 2026 15:18:19 GMT

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 ?

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

Einar Thorsrud — Wed, 18 Feb 2026 14:00:53 GMT

Hi,

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

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).
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.
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.

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

michael01 — Fri, 13 Feb 2026 16:26:18 GMT

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.

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

Einar Thorsrud — Fri, 13 Feb 2026 13:47:12 GMT

Hi,

[quote user="michael01"]

Is there something different about targeted advertisements?

The central still has to be scanning correct?

[/quote]

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?

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

michael01 — Thu, 12 Feb 2026 15:37:54 GMT

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.

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

Einar Thorsrud — Thu, 12 Feb 2026 12:46:53 GMT

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).

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

michael01 — Wed, 11 Feb 2026 16:49:15 GMT

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)

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

michael01 — Wed, 11 Feb 2026 16:01:13 GMT

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.

RE: peripheral advertisements not seen by central in NRF SDK 17.1.0

Einar Thorsrud — Wed, 11 Feb 2026 13:44:25 GMT

Hi,

I have some questions in order to understand more:

Do you use bonding or only pairing?
Do you use whitelisting?
Does it always follow the same pattern, where it takes the same number of repeats before it fails?
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?
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)