Whitelist scanning limitations on max number of devices

[pressure_sensor_nonconn_adv]

Hi,

I am using my nRF52832 with SDK v16 and Softdevice S132 v7.0.1.

My device has the Central role (and Peripheral) and connects to several devices which are added to the list of peers by the Peer Manager.

Now I would like to also read/receive packets from a device that is non-connectable (packet type ADV_NONCONN_IND). I managed to manually modify the whitelist created with the functions of the Peer Manager to also add the MAC addresses of the device that is non-connectable.

The problem is that if I understood correctly form the datasheet only 8 addresses can be whitelisted. Section 23.12 in https://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.4.pdf it is stated that: 

"The RADIO is able to listen for eight different device addresses at the same time"

 

QUESTION:

Is this limitation also true for my setup? And if yes are there other options to scan for more devices apart from the following propositions?

• Change the whitelist every second or less -> but then we might miss many packets from the Peripherals?
• As stated here we could also scan for 8 IRKs at the same time, so a total of 16 addresses. But somehow I cannot find the corresponding addresses in the S132, does it not feature IRK whitelisting? (the processor does as stated in the datasheet: section 30.6.5 NIRK describes the register “NIRK” where the number of IRKs is saved. Max value is 16")

Thank you for your support

[Kenneth]

If you are a central role device I suggest to not use whitelist, just start scanning and receive all advertisement reports in the application. If the address type is public or random static you can simply compare it with an address list that is more than 8. If the address type is private resolvable you can use the im_address_resolve()-api and run it through all your IRK's you have to check if it's a previously bonded peer.

/**@brief Function for resolving a resolvable address with an identity resolution key (IRK).
 *
 * @details This function will use the ECB peripheral to resolve a resolvable address.
 *          This can be used to resolve the identity of a device distributing a random
 *          resolvable address based on any IRKs you have received earlier. If an address is
 *          resolved by an IRK, the device distributing the address must also know the IRK.
 *
 * @param[in] p_addr  A random resolvable address.
 * @param[in] p_irk   An identity resolution key (IRK).
 *
 * @retval true   The irk used matched the one used to create the address.
 * @retval false  The irk used did not match the one used to create the address, or an argument was
 *                NULL.
 */
bool im_address_resolve(ble_gap_addr_t const * p_addr, ble_gap_irk_t const * p_irk);

[pressure_sensor_nonconn_adv]

Thank you for your quick response and great support!

I also considered not using the whitelist at all but was not sure how it would impact the timings. Since the whitelist is implemented in hardware it will be much faster and is also recommended to use when we have paired peers.

Wouldn't the scanning without a whitelist for let's say 15 devices in an environment with many advertisers lead to a measurable decrease in the number of packets being detected/received?

I am using this chip in the Central and Peripheral role. In the central role we might have around 10 peripherals (including one with an App) and in the peripheral role we have 2 connections of which one is rather "intensive" (with an App)

[Kenneth]

pressure_sensor_nonconn_adv said:

Wouldn't the scanning without a whitelist for let's say 15 devices in an environment with many advertisers lead to a measurable decrease in the number of packets being detected/received?

You would still be able to receive advertisement packets while calculating, and considering it also take some time to receive packets (including possible scan response packets), so I don't expect it will have any major impact.

Best regards,
Kenneth