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

How to get full Service UUID from given BASE UUID

Hi all

I am trying to pair nrf52840 (as a central) with ESP32 (as peripheral).

 Now I want to get the service uuid so that i can pass to advertising service in ESP32 code.How do I get the full-service UUID, I see that in the ble_lbs_c service  UUID is declared as 0x1523 characteristic  UUID as 0x1525 and LBS_UUID_BASE {0x23, 0xD1, 0xBC, 0xEA, 0x5F, 0x78, 0x23, 0x15, 0xDE, 0xEF, 0x12, 0x12, 0x00, 0x00, 0x00, 0x00}

I tried to pass the service uuid as #define SERVICE_UUID   "23151212EFDE1523785FEABCD1" on ESP32 program but that didnt work. What is the exact order of the UUID? If you need  details on esp32 code here is the example esp32 program

I am using ble_app_blinky_c example on nrf52840.

Thank you in advance

Parents
  • Hello,

    I am not sure how the ESP libraries work, or how they set up their UUID. Have you tried looking at this device using nRF Connect? Whatever the outcome of the UUID is when you set it like that, you can compare it to the scanned UUID (if the ESP advertises using it's UUID at all). You can download the app version of nRF Connect on google play store or the iOS App Store. Alternatively, you can use the nRF Connect for Desktop (which requires an extra nRF DK/dongle).

  • Hi Edvin

    Thank you for your quick response but I think there might be a misunderstanding. I am trying to find out, what the full-service UUID that will be formed by the Central(in this case Nrf52840) not ESP32.Once I get that I would use it , for advertising in ESP32 code.

    Thank you again.

  • Please look at the scan_init in ble_app_uart_c, as this is looking for a specific UUID, which you can try to modify to match your UUID. Remember to also set NRF_BLE_SCAN_UUID_CNT to 1 in sdk_config.h.

    If you insert the correct UUID, does nrf_ble_scan_connect_with_target() get called inside the nrf_ble_scan_on_adv_report() in nrf_ble_scan.c?

  • Hi Edvin

    I did some digging a bit. It seems like adv_name_compare() in nrf_ble_scan.c returns false. To be specific i think ble_advdata_name_find returns false. I tried to log NRF_LOG_DEBUG("adv_data %s",p_adv_report->data.p_data) it prints out  "ESP32  #N_x...." with some strange characters after that.

    I have tried with NRF52 peripheral board which connects successfully, but the log above doesn't print anything, and ble_advdata_name_find returns true. 

    What could be the cause of returning false (in esp32 peripheral case) ?

  • Can you show me what the entire advertising pack looks like?

     

    davidm said:
    What could be the cause of returning false (in esp32 peripheral case) ?

     The obvious answer is that ble_advdata_name_find returns false. 

    Try to print out the entire p_data, and see what it looks like, then you can analyze ble_advdata_name find, to see why it returns false. 

    But let me see the entire advertising data packet that contains "ESP32 #N_x...".

    BR,
    Edvin

  • Edvin,

    NRF_LOG_DEBUG("%s",  p_adv_report->data.p_data); prints -> ESP32
    #Ѽê_x#Þï#
    NRF_LOG_RAW_INFO("raw data %s:", p_adv_report->data.p_data);prints -> ESP32
    NRF_LOG_RAW_INFO("%02x:", p_adv_report->data.p_data); prints-> 20002C28
    By the way "ESP32" you see in the logs, is the name I configured on esp32 peripheral board to be the name of the device.
  • Can you please try the snippet that I used in the previous reply?

    What I wanted you to see is the different flags that are used in an advertising packet, which you can read about here. In the section "Example 1" you can see how the name is behind the flag 0x09. This is why I wanted you to print all the bytes in hexadecimal format (%02x), so that I could see what your packet contains. When you print using %s, it will only print the ascii values of the packet. Your advertising data doesn't start with ESP32. There has to be some flags before that. 

    The last one you printed:

     

    davidm said:
    NRF_LOG_RAW_INFO("%02x:", p_adv_report->data.p_data); prints-> 20002C28

     Will only print one byte. 

Reply
  • Can you please try the snippet that I used in the previous reply?

    What I wanted you to see is the different flags that are used in an advertising packet, which you can read about here. In the section "Example 1" you can see how the name is behind the flag 0x09. This is why I wanted you to print all the bytes in hexadecimal format (%02x), so that I could see what your packet contains. When you print using %s, it will only print the ascii values of the packet. Your advertising data doesn't start with ESP32. There has to be some flags before that. 

    The last one you printed:

     

    davidm said:
    NRF_LOG_RAW_INFO("%02x:", p_adv_report->data.p_data); prints-> 20002C28

     Will only print one byte. 

Children
  • Oh, my apologies and Thank you for your patience...Here is what I get when I iterate through p_adv_report->data.p_data .   02:01:06:06:09:45:53:50:33:32:02:0A:03:11:07:23:D1:BC:EA:5F:78:23:15:DE:EF:12:12:23:15:00:00

  • Ok. comparing this to the link in the previous reply, and the values from here.

    I'll try to break it down:

    So, the advertising name of the device is "ESP32". And the service UUID is the bottom one.

    Please remind me how you set the scan filter.

    By the way, if you are just using these two devices, and don't really need anything generic, you can just use:

    It is quite hardcoded, but it will connect to this device.

  • Hi Edvin

    Thank you for the breakdown. I still need to read about Scanning and data structuring to get a better understanding.

    Regarding matching, Ideally, there would be multiple devices trying to connect with the peripheral(Esp32) so hardcoding, would not work in my case.

     I am using ble_app_blinky_c central example looking in the code snipet below  ,it does get inside name_filter_enabled but  adv_short_name_compare(p_adv_report, p_scan_ctx) is always false. 

    I have also  attached the nrf_ble_scan_c below.

  • davidm said:
    it does get inside name_filter_enabled but  adv_short_name_compare(p_adv_report, p_scan_ctx)

     Ah! There we go.

    The advertisement doesn't contain a short name. It contains a complete name. (see the difference between 0x08 and 0x09)

    adv_short_name_compare (if you go to the definition, a couple of steps inside this function) you will see that it looks for BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME, which is 0x08, while your advertisement contains BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME which is 0x09. Try to set:

    NRF_BLE_SCAN_NAME_CNT to 1, and NRF_BLE_SCAN_SHORT_NAME_CNT to 0, so that you use the correct function, adv_name_compare() instead of adv_short_name_compare().

  • Hi Edvin

    My mistake, I meant to say ...it does get inside name_filter_enabled but  adv_name_compare(p_adv_report, p_scan_ctx)is always false.

    It was a copy/paste  error.