FULLY Custom Advertisement Data

RE: FULLY Custom Advertisement Data

Carles — Mon, 24 Aug 2015 12:01:02 GMT

Hi there,

Just to clarify some points:

The SoftDevice does not verify if the advertising flags are present or not, you can have advertising data and scan response data without any flags at all
The only aspect of the advertising data that is strictly enforced is the "triplet" format. You need to comply with the [size, type, ] format that is described in the spec

This means that if you want to take all 31 bytes, you won't be able to, but you can easily use 29 of them for whatever you want:

  uint8_t adata[31];
  memset(adata, 0x00, sizeof(adata));
  adata[0] = 30;
  adata[1] = BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA;
  // now fill the 29 bytes with whatever you want
  for(i = 2; i < sizeof(adata); i++)
    adata[i] = i;

  retv = sd_ble_gap_adv_data_set(adata, sizeof(adata), NULL, 0);

RE: FULLY Custom Advertisement Data

endnode — Fri, 21 Aug 2015 14:20:16 GMT

Hi Martin, many thanks for the update. Sorry for being picky but I see that your example contains AD_FLAGS element at the beginning:

// flags for discoverable/connectable
    adv_data[0] = 0x02; // ad field length = 2 bytes
    adv_data[1] = 0x01;   // ad field type = 0x01 [Flags)
    adv_data[2] = 0x06; // flags = 0x06, connectable/undirected

This is compliant to BT SIG specification but what if we want to do non-compliant advertisement (= or just avoiding GAP/GATT compliancy but rely on L2CAP and other parts of BT Smart stack)? Could you check if you can realy put any 31-byte "rubbish" string to the adv data?

Thanks Jan

RE: FULLY Custom Advertisement Data

Marius Heil — Fri, 21 Aug 2015 14:19:59 GMT

The sd_ble_gap_adv_data_set() function will check if your advertising packet conforms to the Bluetooth standard and will run some checks on it. If you want to build an advertising packet that is compatible with the BLE specification, that works, but non-compatible packets will fail.

I am not too sure about whether the flags need to be included. The latest BLE addendum allows to leave the flags field empty if it is a non-connectable advertising message, but I guess that they have not yet implemented this.

RE: FULLY Custom Advertisement Data

endnode — Fri, 21 Aug 2015 13:54:35 GMT

Hi Martin, I've understood there is no way to avoid setting AD_FLAGS element on nRF51 when using S110/S120/S130 stacks. Is it correct? Thanks Jan

RE: FULLY Custom Advertisement Data

samet kocatepe — Fri, 21 Aug 2015 13:05:41 GMT

hi martin. thank you for fast reply. fully custom advertisement means that , users can create their own advertisement data up to 31 bytes freely. in their forum there is an example named as "custom_advertisement" . link textyou can reach example .( in zip file open .bgs with notepad++ ).regards.

RE: FULLY Custom Advertisement Data

MartinBL — Fri, 21 Aug 2015 12:27:22 GMT

Hi. I'm not really sure what you mean by fully custom, but here is a tutorial on how to initialize advertising and scan response with various information like UUIDs, manufacturer specific data, tx power, etc.

EDIT:

You can use sd_ble_gap_adv_data_set() to make your own custom advertising and scan response packet. See this and this semi relevant discussions or search devzone for the function.

I tried it very quickly with the following code and it seems to work, but I don't have time to test it thoroughly and there might very well be a more elegant way to do it.

static void advertising_init(void)
{
    uint32_t      err_code;
    ble_advdata_t advdata;

    // Build advertising data struct to pass into @ref ble_advertising_init.
    memset(&advdata, 0, sizeof(advdata));
    advdata.flags                   = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

    ble_adv_modes_config_t options = {0};
    options.ble_adv_fast_enabled  = BLE_ADV_FAST_ENABLED;
    options.ble_adv_fast_interval = APP_ADV_INTERVAL;
    options.ble_adv_fast_timeout  = APP_ADV_TIMEOUT_IN_SECONDS;

    err_code = ble_advertising_init(&advdata, NULL, &options, on_adv_evt, NULL);
    APP_ERROR_CHECK(err_code);

    uint8_t adv_data[13] = {0};
    uint8_t sr_data[20] = {0};

    // flags for discoverable/connectable
    adv_data[0] = 0x02; // ad field length = 2 bytes
    adv_data[1] = 0x01;   // ad field type = 0x01 [Flags)
    adv_data[2] = 0x06; // flags = 0x06, connectable/undirected

    // tx power field advertisement, iOS apps may need this
    adv_data[3] = 0x02; // ad field length = 2 bytes
    adv_data[4] = 0x0a;    // ad field type = 0x0A [TX Power)
    adv_data[5] = 0x03; // TX power in dBm
    // NOTE: TX power is a signed 8-bit value, and is not changed automatically
    // when using "hardware_set_txpower[<power>)". This may be anywhere from -23
    // to +3 based on your settings. Negative values may be converted to two's
    // complement form by adding 256, so for example -23 dBm would be 233 or 0xE9.
    
    // custom manufacturer
    adv_data[6] = 0x06; // ad field length = 5 bytes [arbitrary, maybe more or less but minimum 3)
    adv_data[7] = 0xff; // ad field type = 0xFF [Manufacturer Specific Data)
    adv_data[8] = 0xff; // unknown/prototype Company Identifier Code - octet 2 
    adv_data[9] = 0xff; // unknown/prototype Company Identifier Code - octet 1 
    adv_data[10] = 0xb1; // custom data byte //1 [can be anything)
    adv_data[11] = 0xb2; // custom data byte //2 [can be anything)
    adv_data[12] = 0xb3; // custom data byte //3 (can be anything)
    // NOTE: manufacturer data fields should contain the Company Identifier Code
    // in order to stay within BT 4.0 spec. You should also ideally obtain an
    // an official Company Identifier Code, but 0xFFFF is suitable for development.
    // (this is why the minimum ad field length for this is 3, so the CIC fits)

    // More bytes are possible here, but not necessary for this demo.
    // Compare with automatically generated ad packets from other
    // demo projects to see what else you might put here, or read
    // the relevant portions of the Bluetooth 4.0 Core Spec document
    // for greater detail.
    
    // -------------------------------
    // build custom scan response data
    // -------------------------------

    // get Bluetooth MAC address of this device (NOTE: this is little-endian!)

    sr_data[0] = 0x13;  // ad field length = 19 bytes (0x13)
    sr_data[1] = 0x09;   // ad field type = 0x09 (Complete local name)
    sr_data[2] = 0x06;  // 'M'
    sr_data[3] = 0x79;  // 'y'
    sr_data[4] = 0x20;  // ' '
    sr_data[5] = 0x57;  // 'W'
    sr_data[6] = 0x69;  // 'i'
    sr_data[7] = 0x64;  // 'd'
    sr_data[8] = 0x67;  // 'g'
    sr_data[9] = 0x65;  // 'e'
    sr_data[10] = 0x74; // 't'
    sr_data[11] = 0x20; // ' '
    sr_data[12] = 0x01;
    sr_data[13] = 0x02;
    sr_data[14] = 0x03;
    sr_data[15] = 0x04;
    sr_data[16] = 0x05;
    sr_data[17] = 0x06;
    sr_data[18] = 0x07;
    sr_data[19] = 0x08;
    
    uint32_t err_code;
    err_code = sd_ble_gap_adv_data_set(adv_data, 13, sr_data, 20);
    APP_ERROR_CHECK(err_code);
}