Reconnecting in central mode

[GT]

I am developing an application on nRF52 wich simultaneously acts as a central and peripheral and I am using the Peer Manager to manage bonding. The central needs to stay connected with a few already bonded peripherals which can occasionally get out or reach and disconnect. Therefore, if not all peripherals are connected, a scanning will be constantly running. The application parses all received advertising reports and first filter them out based on the Manufacturing specific data and then on the Flags. And here it comes the question - how do I filter out the advertising reports further and distinguish the ones coming from devices which have already got a valid bond with this particular central? Does the Peer Manager or the ID Manager provide this functionality or the application needs to keep track on that based on for instance peer addresses?

[Hung Bui]

Hi GT,

Yes, you can manually check the address of the advertiser when you receive advertising and compare to the list of device connected/paired.

But the esier way is to let the radio filter out advertising packets for you automatically. You can do that by providing a whitelist to the softdevice when doing scanning. The list of paired device can be acquired by calling pm_whitelist_get(). You will have address and IRK of the devices paired, and you can do selective scanning based on this list.

Please have a look at the scan_start() function in main.c in ble_app_hrs_c project in our SDK.

[GT]

Hello Hung, Thanks for the useful information! I managed to implement whitelisting for the central and now the application receives only advertising packages from whitelisted devices. However, another problem just showed up - sd_ble_gap_connect() returns NRF_ERROR_INVALID_PARAM when the whitelist is enabled. If the whitelist is disabled, the central can connect and communicate with a peripheral. Another nNF51 device is used as a peripheral and it uses BLE_GAP_ADDR_TYPE_RANDOM_STATIC which I believe is causing this behavior. However, the peripherals are using the DEVICEADDR[0] and DEVICEADDR[1] to set the address on power up.

Does the whitelisting supports with BLE_GAP_ADDR_TYPE_RANDOM_STATIC or it requires BLE_GAP_ADDR_TYPE_PUBLIC or BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE?

[Hung Bui]

@GT: Are you sure you used the same whitelist param for scanning and connecting ?

Note that if you set the bit in addr_id_peer in p_peer_addr, the address have to be added to the device identity list.

If you simply want to connect to a particular address, you don't have to use whitelist, simply use the address so the device will only connect to that address.

I don't think whitelist has any problem with BLE_GAP_ADDR_TYPE_RANDOM_STATIC

[GT]

Could you be more specific on this: "Note that if you set the bit in addr_id_peer in p_peer_addr, the address have to be added to the device identity list."

The code that I am working with looks exactly like the example given in the ble_app_hrs_c project. The application that I am developing requires maintaining a connection with multiple peripherals, therefore I was trying to avoid keeping track on peripheral's addresses in the application code.

I am not sure if this brings any value to the discussion, but if I disable the whitelist right before I request a connection, the connection goes fine. Like this:

m_scan_params.use_whitelist = 0;
err_code = sd_ble_gap_connect(&addr, &m_scan_params, &m_connection_param);

The values of the parameter passed to the sd_ble_gap_connect() are as expected when checked with a debugger.

[Hung Bui]

I mean in the "addr" argument, do you set .addr_id_peer = 1 ? Do you have an address inside "addr" ?

From what you described, there must be smth wrong with the whitelist you provided. Could you provide the copy of data in side your m_scan_params? You can add a breakpoint and find the value in the watchlist.