Why is the whitelist set to NULL?

RE: Why is the whitelist set to NULL?

tesc — Thu, 14 Apr 2016 08:53:54 GMT

Sorry for the many updates, I had a deeper look into things.

The example is using the Device Manager function dm_whitelist_create() to generate a whitelist consisting of all the currently bonded devices. If there are no bonded devices it will use the empty whitelist.

RE: Why is the whitelist set to NULL?

Andrew — Wed, 13 Apr 2016 21:02:34 GMT

The more I look at the example, the more it looks like it was at least supposed to be set up to handle whitelisting. Note that the "m_scan_mode" is setup take inputs of type "ble_scan_mode_t" which includes "BLE_WHITELIST_SCAN." Which I would hope would imply that whitelisting is an option. What would it take to make this example able to use whitelisting?

RE: Why is the whitelist set to NULL?

Andrew — Wed, 13 Apr 2016 20:39:33 GMT

So the answer by run_ar, devzone.nordicsemi.com/.../ saying that the heat rate example is an example of whitelisting, is false? Is there an example of whitelisting for the central?

RE: Why is the whitelist set to NULL?

tesc — Wed, 13 Apr 2016 13:01:01 GMT

Hi,

p_whitelist is set to NULL in one of the two possible cases. This is to allow the ble_app_hrs_c example to connect to new devices. In the other case it is set to point to a whitelist.

The reason why there is a non-whitelist case is to allow the device to connect to new peripherals. These peripherals can then be added to the whitelist. In this example the Device Manager is used for building a whitelist of all of the bonded devices, using dm_whitelist_create(). If there are no bonded devices the whitelist will be empty, resulting in using the NULL pointer and not using whitelist, allowing for a new device to bond.

If you do have another way to build the whitelist you can manage with only the case using the whitelist.

Regards, Terje