RE: manufacturer specific data

MartinBL — Thu, 08 Oct 2015 07:59:10 GMT

Hi. Good to hear! If you are satisfied with the answer and don't have any more related questions then please accept the answer and close the case. This will make it easier for other users with the same problem to search for and find the answer.

RE: manufacturer specific data

SKo — Mon, 05 Oct 2015 07:41:38 GMT

Hi Martin,

your solution works perfect. By the way with your response you solved another issue I was facing. Thank you!

RE: manufacturer specific data

MartinBL — Mon, 28 Sep 2015 13:00:12 GMT

Hi.

As Carles describes here, you can put whatever data you want in the advertising packet, but you will have to comply with the triplet format [size, type, data] format that is described in the spec. Here is a list of types and here is more info on the triplet format. Comparing the data in your packet with the list you can see that the three first bytes of your advdata packet is a flag field, 02 = size (1 byte), 01 = type (flags, 1 byte), 06 = data (flags, 06 = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE).

However, getting rid of the flag field is easier said than done, but there is a workaround. In SDK 9 advertising is initiated with ble_advertising_init() which takes your advpacket, some options, etc as arguments. ble_advertising_init() is checking the validity of your advdata and will return an error if the packet doesn't include a flag field. The function also passes some important options and an eventhandler to be used in various functions in ble_advertising.c. In the end of ble_advertising_init() you will find sd_ble_gap_adv_data_set() defined in ble_gap.h. This is the function that sets your advdata and it won't complain as long as you follow the triplet scheme. So det simplest workaround I found (without tinkering with ble_advertising.c or ble_advdata.c) was this:

static void advertising_init(void)
{
    uint32_t      err_code;
    ble_advdata_t advdata;
    
    // Build an advertising packet as usual containing flags
    memset(&advdata, 0, sizeof(advdata));
    advdata.flags                   = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

    // Sett all relevant options
    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;

    // Call ble_advertising_init() to pass the options and the event handler to ble_advertising.c 
    err_code = ble_advertising_init(&advdata, NULL, &options, on_adv_evt, NULL);
    APP_ERROR_CHECK(err_code);
    
    // Build your advertising packet. 
    uint8_t m_addl_adv_manuf_data[] = {0x08, 0xFF, 0x11, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05};   
    
    // Cheat the softdevice by overwriting the advertising packet data
    err_code = sd_ble_gap_adv_data_set(m_addl_adv_manuf_data, sizeof(m_addl_adv_manuf_data), NULL, 0);
    APP_ERROR_CHECK(err_code);
}

The packet m_addl_adv_manuf_data is a 9 byte long array.

Length field, 1 byte
Data type value indicating manufacturer specific data, 1 byte
Manuf data, 7 bytes. (Company identifier 0x0011, payload 0x01, 0x02, 0x03, 0x04, 0x05)

If you are fine with some tinkering, possibly causing ripple effects in all examples and code your SDK folders, there is a very simple workaround:

Comment out the following in ble_advdata_set() found in ble_advdata.c:

    err_code = advdata_check(p_advdata);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }

Then you will skip the flag validation entirely. By doing this the code you posted worked "out of the box" on my system.

Finally note that because of the triplet system you will not be able to have more than 29 bytes of useful payload.