This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

service data advertisement and 128 uuid

Hi,

I searched through the devzone but I cannot find a answer on this question but the question has been asked before. Some background. I have a working solution from another vendor and I want to switch to Nordic. In this solution I use service data to advertise our product including some data about the product. I am now looking in the SDK to see how I can implement this with Nordic. Ok, so the ble_advdata_service_data_t structure needs a uint16_t for de uuid. I use 128 bits uuid's. I can add them with sd_ble_uuid_vs_add. This returns a UUID type. Now the question is. How do I match the UUID type return from sd_ble_uuid_vs_add to the service_uuid field in ble_advdata_service_data_t structure.

Cheers, Marcel

  • The advertisement init at line 222 uses the 128 uuid (g_BlinkyServ.uuid_type) for service advertisement. I need to do service DATA advertisement (using ble_advdata_service_data_t) with a 128 bit uuid. This is different from service advertisement. Still you are using a illegal manufacturer id. This is alway a 16 bit uuid. A 128 bit uuid is not possible with manufacturer data.

  • Ok, then you can use the le_advdata_service_data_t for your uuid. The code is an example demo code not production. It does not matter whether I use illegal manufacturer id or not. My iOS counter part demo code still can read it. I do have a real ID which I do not provide with demo code. The info I transmit over manufacturer data is the 64bits chip unique ID. I use it as serial number so i can connected to multiple boards. In the Scan, I list them with the serial # so the user can select what that need. In another app (private one) I send both the 64bits serial # plus 3 x 16 bits values for model #, Hw rev #, fw rev #. Total of 112 bits + 16 bits manufac Id = 128bits. The p_data can be whatever you want to put in there. If you don't like using manufacturer data, you can use the ble_advdata_service_data_t instead. I've never tried that one though. Plus I still get my full 128bits service uuid transmitted with it so the total is 256bits. My be you can take a sniffer and compare the packets. Nordic SDK may have a different way to do thing than what you used to have but the transmitted packet should be very similar

  • Thank you for bearing with me. The problem is there is already an implementation using a different vendor and there is already an iOS app in the field. That 's why I have to use this type: BLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID of advertisement. I think I can solve te problem by extending service_data_encode function or create my own encoder but I did not tried that yet. I personally find it strange how Nordic implemented it and deals with 128 uuid's. Most people, I think, wil not make products which already have a Bluetooth SIG profile and therefore must use 128 uuid's. You are right that the Nordic SDK may have different ways and that only the transmitted packet is important. But sadly enough the forgot to implement 128 uuid service data type of advertisement. I will make a case out of this because Nordic is not responding here. It would be really nice if it is added to the SDK

  • Please have a look at experimental_ble_app_uart, it includes a 128 bit UUID in the scan response.

    It is not included in the advertising packet, because it would become to big with both a device name and a 128 bit UUID in it.

    However, you can easily remove the device name (use BLE_ADVDATA_NO_NAME), and add the UUID to the advertising packet by replacing:

    scanrsp.uuids_complete.uuid_cnt = sizeof(adv_uuids) / sizeof(adv_uuids[0]);
    scanrsp.uuids_complete.p_uuids  = adv_uuids;
    

    with:

    advdata.uuids_complete.uuid_cnt = sizeof(adv_uuids) / sizeof(adv_uuids[0]);
    advdata.uuids_complete.p_uuids  = adv_uuids;
    
  • The answer given by Petter Myhre is exactly what I did in my example code.

Related