Advertising 128 bit UUID for custom service

Hi,

What macro should be used in the bt_data ad struct in order to advertise a custom 128 bit UUID? I have tried the following: BT_UUID_128_ENCODE(BT_UUID_CUSTOM_SERVICE).

Thanks,

Adam

Parents
  • Probably some code snippets that you used might help us see the issue. What kind of errors are you getting?

    The eddystone sample uses below initialization to advertise all of 128 bit UUID, just an example to show you.

    static const struct bt_data ad[] = {
    	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
    	/* Eddystone Service UUID a3c87500-8ed3-4bdf-8a39-a01bebede295 */
    	BT_DATA_BYTES(BT_DATA_UUID128_ALL,
    		      0x95, 0xe2, 0xed, 0xeb, 0x1b, 0xa0, 0x39, 0x8a,
    		      0xdf, 0x4b, 0xd3, 0x8e, 0x00, 0x75, 0xc8, 0xa3),
    };
     

  • Hi Susheel,

    I have attached the relevant code below. I am now getting the following error: too big advertising data. It works perfectly when I leave out the other SIG defined UUIDs. The error probably occurs because I am already advertising three other SIG defined services.

    1. Is there anyway to encode this 128 bit data into a smaller number that can be advertised?

    2. Or would it be a better idea to just include the 128 but UUID in the scan response sd data? If so, I am using the Android nRF Connect app - how do I request scan response data so that I can see the 128 bit UUID.

    3. Any other suggestions?

    4. Also, what is the max size in bits for a legacy advertising packet?

    Thanks so much,

    Adam

    Here is my advertising struct:

    static struct bt_data ad[] = {
    	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
    	BT_DATA_BYTES(BT_DATA_UUID16_ALL,
    		      BT_UUID_16_ENCODE(BT_UUID_HTS_VAL),
    			  BT_UUID_16_ENCODE(BT_UUID_DIS_VAL),
    		      BT_UUID_16_ENCODE(BT_UUID_BAS_VAL)),
    	BT_DATA_BYTES(BT_DATA_UUID128_ALL, RSSI_SERVICE_UUID),
    };

    In my service.h file, I have the following: 

    #define RSSI_SERVICE_UUID 0xb4, 0xa0, 0x76, 0x45, 0xE9, 0x47, 0xC5, \
                                    0x93, 0x9D, 0x9D, 0x03, 0x45, 0x76, 0xA0, 0xB4, 0x49
    In my service.c file, I have the following: 
    #define BT_UUID_RSSI_SERVICE            BT_UUID_DECLARE_128(RSSI_SERVICE_UUID)
  • Thanks.

    It works now - I was not sending the sd data originally.

    However, now the device name is not printing in full whenever I include sd data. I don't have this issue when I am not sending sd data. Could this be because the advertising packet is too long to fit the full device name?

    Thanks,

    Adam

  • adam_atmo said:
    Could this be because the advertising packet is too long to fit the full device name?

    It most likely is too long. How did you split the adv data and the scan response data? Can you show us your new declaration for ad and sd?

  • Sure, attached below:

    static struct bt_data ad[] = {
    	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
    	BT_DATA_BYTES(BT_DATA_UUID16_ALL,
    		      BT_UUID_16_ENCODE(BT_UUID_HTS_VAL),
    			  BT_UUID_16_ENCODE(BT_UUID_DIS_VAL),
    		      BT_UUID_16_ENCODE(BT_UUID_BAS_VAL)),
    			  { /* TX power adv data */},
    };
    
    /* Scan response data.
     * Includes 128 bit UUID for custom RSSI service.
     */
    static const struct bt_data sd[] = 
    {
    	BT_DATA_BYTES(BT_DATA_UUID128_ALL, RSSI_SERVICE_UUID),
    };

  • the ad seems to be of total bytes of 2 (flags) + 1 type for flags + 6 (HTS+DIS+BAS) + 1 (type for HTS/DIS/BAS) + 1 (length field)  = 11 bytes.

    So you have 27-11 = 16 bytes for device name + type and length, which equals 14 bytes of actual device name.

  • Thanks Susheel,

    However, it seems that it is the introduction of the SD data that limits the length of the name. I don’t have an issue with this when I am not sending scan response data. Have you included the SD data in your calculation?

Reply Children
Related