This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52832 SDK15.2 - Scan Module 128bits UUID filter

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

Parents
  • 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 suggests, the central UART example is where you can see it fully

Reply
  • 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 suggests, the central UART example is where you can see it fully

Children
No Data
Related