Reconnecting in central mode

RE: Reconnecting in central mode

Hung Bui — Wed, 14 Dec 2016 14:36:45 GMT

Hi GT,

You only use whitelist when doing sd_ble_gap_connect() if you don't plan to connect to a particular device but to connect to any of the device inside the whitelist. So who ever advertising first (or get the adv packet be received first) will be connected.

In your case, maybe you don't need to use whitelist in this case ?

If you want I can try to create an example with whitelist and sd_ble_gap_connect(). Pretty short on time now to create the example.

RE: Reconnecting in central mode

GT — Wed, 14 Dec 2016 12:04:22 GMT

In the main() I have a call to whitelist_load() beofre start_scan(). In this function, there is a call to pm_whitelist_set(). The two functions whitelist_load() and peer_list_get() are copied from the ble_app_hrs_c example project. I do not call sd_ble_gap_whitelist_set() before calling sd_ble_gap_connect(). Should I do that considering the pm_whitelist_set()? The project that I am working on is an nRF52 with S132 V3 acting as a central which keeps a connection to up to 8 peripherals, and in parallel acts as a peripheral to a smartphone. Therefore, I thought that using a white list to handle all 9 connections would be "the smart" way to go.

RE: Reconnecting in central mode

Hung Bui — Wed, 14 Dec 2016 11:38:20 GMT

Hi GT,

Have you made sure you called sd_ble_gap_whitelist_set() prior to that call to connect ? ( I assume you called that for the scanning prior) , what do you have in that call ?

Btw, if you aiming at connection to a specific address, then I don't really see the point of using whitelist here.

RE: Reconnecting in central mode

GT — Wed, 14 Dec 2016 08:35:34 GMT

The values are:

addr.addr_id_peer = 0
addr.addr_type = 1
addr -> conatins the expected address of the device

The scan_params:

m_scan_params.active = 0
m_scan_params.use_white_list = 1
m_scan_params.adv_dir_report = 0

m_scan_params intervals and window have the expected value. The same goes to the m_connection_param.

RE: Reconnecting in central mode

Hung Bui — Tue, 13 Dec 2016 08:45:21 GMT

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.

RE: Reconnecting in central mode

GT — Mon, 12 Dec 2016 15:31:48 GMT

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.

RE: Reconnecting in central mode

Hung Bui — Mon, 12 Dec 2016 14:25:16 GMT

@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

RE: Reconnecting in central mode

GT — Mon, 12 Dec 2016 13:18:39 GMT

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?

RE: Reconnecting in central mode

Hung Bui — Mon, 05 Dec 2016 09:51:12 GMT

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.