Don't understand sdk 15.0.0 ble_advdata_uuid_find

 I am using 128bit UUID but scanning for the 16bit 0x7000 as in the stack var in function on_adv_report

ble_uuid_t target_uuid = {.uuid = 0x7000, .type = BLE_UUID_TYPE_VENDOR_BEGIN};

The ble_advdata_uuid_find fails with the .type as 01 or 02

The     err_code = sd_ble_uuid_encode(p_target_uuid, &raw_uuid_len, raw_uuid); call returns raw_uuid_len of 0x10 for UUID type 02 and 2 for UUID type 01. 

The data.len is always 3 for either type

    if (data_offset == 0) is always zero so the function always fails?

I am sure I have missed something but don't see it:

Any help would be appreciated.

Thanks

  • Compared issue with  multirole_lesc and ble_app_hrs code sets:  The HRS x180D always shows up in the p_encoded_data along with the advertised name:  the UUID and then the name

    On the working code set the UUID  0x7000 never shows up in the p_encoded_data

    Here is the 128bit UUID {{0x61, 0x44, 0xd7, 0x98, 0xf6, 0x86, 0x7b, 0x89, 0xea, 0x4f, 0x00, 0xa3, 0x00, 0x70, 0x6d, 0x15}}  with the 7000

    I notice that when searching for 16bit UUIDs that the value (x180d) is put in the (call     err_code = sd_ble_uuid_encode(p_target_uuid, &raw_uuid_len, raw_uuid);) raw_uuid bytes zero and one.  In the 128bit uuid the bytes are as assumed in bytes 12 &13.

    There are only 5 bytes before the advertised name

    Still trolling for help

  • Hi!

    Hard to say what could be causing this.
    Maybe you could upload your project or some relevant code? That might help shed some light on what the issue might be.

    Also I suggest that you take a look at how this is done in the ble_app_uart/ble_app_uart_c example.
    The uart examples uses a 128-bit base UUID, and the central scans for the 16-bit service UUID (0x0001).

    I'll try to set this up myself, and see if I run into any issues similar to yours.

    Best regards,
    Joakim.