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

Less room for manufacturer data than expected

I created an App with one 16 bit service and some manufacturer data, but the maximum length of manufacturer data that doesn't cause an error is 16 bytes, when in theory it should be at least 20 bytes

If I construct the advertising data manually, I need

0x02,0x01,0x06 // Flags  - 3 bytes taken for this
0x03,0x03,0x00,0x18 //Service ID (0x1800) - 4 bytes taken for this
0x17,0xff,......... ( 20 bytes of advertising data) - 22 bytes taken this

However if I use ble_advertising_init what it sends to the SD is

0x03,0x19,0x00,0x00,  
0x02,0x01,0x06,   
0x03,0x03,0x00,0x18,   
0x13,0xff, (16 bytes of advertising data) 

The difference is that ble_advertising_init() creates

0x03,0x19,0x00,0x00 

at the start of the advertising data

Looking at the received data on my Android phone, The advertising data does not seem to contain this additional data.

Can someone tell me what this is, and why its being send to the SD (if its not actually being transmitted), because it appears to be wasting 4 bytes which I could use for additional manufacturer data

Thanks

Edit.

I cant find code 0x19 the BLE spec

www.bluetooth.com/.../generic-access-profile

Parents
  • You have to check the bluetooth assigned numbers document (which the SIG could make a lot easier to find than they do) and you'll see that 0x19 is appearance.

    So look at the code which makes the advertising data and see what you need to set for appearance in the structure to suppress it from being encoded. A cursory look at the latest version of the code I have here indicates you set the include_appearance flag to false.

  • @RK

    Thanks.

    I should have looked through the code to figure out when it was adding that data, but what also I didn't realise is that the GAP codes on that page are not in order.

    Well, they are in order for the first 2 pages of scrolling (up to 0x26) and then it goes back to 0x17

    I've now disabled the "appearance" and got my 4 bytes back ;-)

    PS. I'd already set

    advdata.name_type               = BLE_ADVDATA_NO_NAME;
    

    So I didnt waste space sending a name

Reply
  • @RK

    Thanks.

    I should have looked through the code to figure out when it was adding that data, but what also I didn't realise is that the GAP codes on that page are not in order.

    Well, they are in order for the first 2 pages of scrolling (up to 0x26) and then it goes back to 0x17

    I've now disabled the "appearance" and got my 4 bytes back ;-)

    PS. I'd already set

    advdata.name_type               = BLE_ADVDATA_NO_NAME;
    

    So I didnt waste space sending a name

Children
No Data
Related