nRF52832 SDK15.2 - Scan Module 128bits UUID filter

[MPS]

Hi,

Is there somewhere an example of the scan module with a filter on a 128bits UUID address ?

Thanks in advance for your help

Best regards

[Mttrinh]

Hi,

I suggest you to have a look the hrs central example, inside the on_adv_report you will find ble_advdata_uuid_find().

[MPS]

Hi Mttrinh,

Thanks for your answer.

With SDK15.2, it seems we don't use on_adv_report. I think it's the old way with older sdk.

I wanted to use the new scan module and I think I found the solution by myself.

I still have to see how to change the scan settings without using the defaults set in the sdk_config.h

[Goudra]

Hi,

I'm also looking to add 128bit uuid in my scan filter. i request you, please explain how you achieve this.

Thanks and regards 

basava.

[Mttrinh]

Hi,

Have a look at the nrf_ble_scan_filter_set() function inside scan_init() in UART example.

[EvanJohnson]

Hey MPS,

I know it's late, but I saw this thread while I was searching for the same answer. Here's a declaration I found in ble.h:

/**@brief Add a Vendor Specific base UUID.
 *
 * @details This call enables the application to add a Vendor Specific base UUID to the BLE stack's table, for later
 * use with all other modules and APIs. This then allows the application to use the shorter, 24-bit @ref ble_uuid_t
 * format when dealing with both 16-bit and 128-bit UUIDs without having to check for lengths and having split code
 * paths. This is accomplished by extending the grouping mechanism that the Bluetooth SIG standard base UUID uses
 * for all other 128-bit UUIDs. The type field in the @ref ble_uuid_t structure is an index (relative to
 * @ref BLE_UUID_TYPE_VENDOR_BEGIN) to the table populated by multiple calls to this function, and the UUID field
 * in the same structure contains the 2 bytes at indexes 12 and 13. The number of possible 128-bit UUIDs available to
 * the application is therefore the number of Vendor Specific UUIDs added with the help of this function times 65536,
 * although restricted to modifying bytes 12 and 13 for each of the entries in the supplied array.
 *
 * @note Bytes 12 and 13 of the provided UUID will not be used internally, since those are always replaced by
 * the 16-bit uuid field in @ref ble_uuid_t.
 *
 * @note If a UUID is already present in the BLE stack's internal table, the corresponding index will be returned in
 * p_uuid_type along with an @ref NRF_SUCCESS error code.
 *
 * @param[in]  p_vs_uuid    Pointer to a 16-octet (128-bit) little endian Vendor Specific base UUID disregarding
 *                          bytes 12 and 13.
 * @param[out] p_uuid_type  Pointer to a uint8_t where the type field in @ref ble_uuid_t corresponding to this UUID will be stored.
 *
 * @retval ::NRF_SUCCESS Successfully added the Vendor Specific base UUID.
 * @retval ::NRF_ERROR_INVALID_ADDR If p_vs_uuid or p_uuid_type is NULL or invalid.
 * @retval ::NRF_ERROR_NO_MEM If there are no more free slots for VS UUIDs.
 */
SVCALL(SD_BLE_UUID_VS_ADD, uint32_t, sd_ble_uuid_vs_add(ble_uuid128_t const *p_vs_uuid, uint8_t *p_uuid_type));

In the nordic UART service, the call looks like this:

err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_ble_nus_c->uuid_type);

As Mttrinh suggests, the central UART example is where you can see it fully