Unable to scan advertising device after it gets bonded.

[Swapnil Karkare]

Hi,

We are working on project, In which we need to support secure LE connection and Bonding with third party BLE device.  We have achieved both of our requirernments, But after disconnection we were not able scan bonded BLE deice. For comparison we used Windows 11 Bluetooth LE explorer application for scaninng, in which can see BLE device advertising. Screen shots are below. BLE device Address type is public.

We are using nRF52833 and s140_nrf52_7.0.1_softdevice.

Advertising flag type before bonding is GeneralDiscoverableMode and Classic not supported(0x06). And after Bonding It changes to Classic not supported(0x04). As we can see after bonding device became Non_discoverable. We haven't used whitelist scanning.

So my questions is, How can nordic see those non discoverable advertising like Windows Bluetooth LE Explorer? (I know non discoverable means it doesn't want to be discovered) and how do we connect this non discoverable tag?

[Hung Bui]

Hi Swapnil, 
From what I can see both of the screenshot showed that the advertising type was "Connectable Undirected" 
So I'm not so sure if one of them was doing directed advertising. 

As far as I know the Softdevice can scan regardless if the device has the discoverable flag or not. 

Could you show how you do scanning ? 

Could you try capture a sniffer trace when the device does advertising in discoverable and non-discoverable ? 

[Swapnil Karkare]

Hi Hung,

I have attached my scan init implementation. Also using BLE_GAP_SCAN_FP_ACCEPT_ALL as filter policy. I have also tried to check BLE_GAP_EVT_ADV_REPORT event. Where i can compare desire MAC address with all adv report. I Didn't found any match there as well.

Unfortunately, The Testing going on at diff location so they don't have nrf dongle or dk.

Also we are using NAME filter for scanning.

[Hung Bui]

Hi, 

Please clarify what I pointed to earlier. I don't see the device doing Directed advertising, it's more likely also Undirected advertising, just with different flag. 

You can do a test by setting up a device doing similar advertising with the same flag and check if the scanner can actually scan. 

Please be aware that BLE_GAP_SCAN_FP_ACCEPT_ALL  will scan all advertising packet, but it will not show the directed advertising with the wrong address. So there can be a chance that the directed advertising was using a wrong address. 

It's important that you can verify that the device actually does directed advertising, not the normal one. And that the directed advertising packet has the correct target address. 

Don't use NAME filter. The directed advertising packet doesn't have any name included in the packet, only address. 

[Swapnil Karkare]

Hi, 

There is misunderstanding from my side. The advertising is unidirected one.To verify the packets I am using Name filter comparison. But actual advertising packet doesn't have Name in adv data. I can see the adv when I compare respective MAC address. That resolved my issue.

Also found out that using nrf_ble_scan. library we can see those adv packet in event  NRF_BLE_SCAN_EVT_NOT_FOUND. So no need to use BLE_GAP_EVT_ADV_REPORT BLE event handler.

Thanks.

[Hung Bui]

Hi Swapnil,

I'm glad that you found the issue. You can use NRF_BLE_SCAN_EVT_NOT_FOUND, but if the filter is not needed you can just remove the filter. I don't see much point of using the filter if the name is not included in the advertising packet. 
Of course if you have a reason to use it (if before bonding it advertiser with name) then it's fine.