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

Insert data in the extended advertisement of BLE 5

Hello

I would like to use the extended advertisement feature of BLE 5 but I have several questions:

1. If I want to broadcast data in "extended advertisement" messages (without connection): should I insert this data in the "manufacturing data" or can I add fields in the "ble_advdata_t" structure containing the data to send ? (what is the right method ?)

2. In which case do we need to request a new "company identifier"? If my devices broadcast data only (no need to connect), should I still have a "company identifier"?

Thank you
Parents
  • Hello,

    Check out the ble_app_rscs example as this uses extended advertising by default.

    It is found in SDK16.0.0\examples\ble_peripheral\ble_app_rscs

    As for the company identifier, you can't use Nordic's in an official product, so if you intend to certify this with Bluetooth, you need to use your own company identifier.

    That being said, I don't think you need a company identifier. You don't need to include it in the advertising packet, at least. It seems to run just fine without.

    You can read a bit more about company identifiers in this blog post. Search for "company ID"

    Is there a reason why you only use advertising? It will probably work, but be aware that you will not get any confirmation on whether or not an advertisement is scanned.

    BR,

    Edvin

  • Hello Edvin

    1. 
     I also use this example (ble_app_rscs) to develop extended advertising. In this example, they insert data in the "manufacturing data". But as I am new with the Bluetooth frame format, I was wondering if it is in the "manufacturing data" field that we indicate our data in general or so, we add new fields in the "ble_advdata_t" structure which contain our data. It's just a general question.

    2.
    Thank you very much.

  • 1: I believe so. It looks like this is how it is done in the example, at least. It is a bit hard to tell, because we don't have anything that can scan for extended advertising out of the box.

    However, I did a short test using ble_app_rscs (peripheral) + ble_app_rscs_c (central), where in the central project, I just changed the UUID that it is looking for from BLE_UUID_RUNNING_SPEED_AND_CADENCE to BLE_UUID_HUMAN_INTERFACE_DEVICE_SERVICE, just so it wouldn't connect, but keep scanning.

    Then I added the BLE_GAP_EVT_ADV_REPORT to the ble_evt_handler, to see the advertisement reports.

    Then I printed out what channels and the length of the advertising packet.

    What I saw is that I don't get the original advertising packet at all (the ones on channel 37, 38 and 39). It looks like they are stripped away from the softdevice, because they only contain the information of what channel and phy the extended advertising is coming on. So in fact, all the data that you send is sent in the extended advertising packet.

    You may want to turn down the advertising interval, and to insert your peripheral's advertising address in the if check to filter out the other advertisements, or it will be a lot of text printed. To see what address you have, use nRF connect for Desktop, and flash the peripheral DK with another example that doesn't use extended advertising. addr[0] is the address byte to the far right:

    Check out the implementation I used to test:

    static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
    {
        ret_code_t            err_code;
        ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
    
        switch (p_ble_evt->header.evt_id)
        {
            case BLE_GAP_EVT_ADV_REPORT:
                //if (p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[0] == 0xD3) // comment in this line, and change it to match the address of your DK
                {
                    NRF_LOG_INFO("adv_report from %02x:02x:02x:02x:02x:02x", p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[0],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[1],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[2],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[3],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[4],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[5]);
                    uint8_t channel = p_ble_evt->evt.gap_evt.params.adv_report.ch_index;
                    uint16_t len = (uint16_t)p_ble_evt->evt.gap_evt.params.adv_report.data.len;
                    NRF_LOG_INFO("adv_report channel %d, len %d", channel, len);
                    
                    NRF_LOG_INFO("advertisement:");
                    for (uint16_t i=0; i<len; i++)
                    {
                        NRF_LOG_RAW_INFO("%02x", p_ble_evt->evt.gap_evt.params.adv_report.data.p_data[i]);
                        if(i%10 == 0 && i != 0)
                        {
                            NRF_LOG_RAW_INFO("\r\n");
                        }
                        else if(i<len-1)
                        {
                            NRF_LOG_RAW_INFO(":");
                        }
                    }
                    NRF_LOG_RAW_INFO("\r\n");
                }
                break;
                case ...

Reply
  • 1: I believe so. It looks like this is how it is done in the example, at least. It is a bit hard to tell, because we don't have anything that can scan for extended advertising out of the box.

    However, I did a short test using ble_app_rscs (peripheral) + ble_app_rscs_c (central), where in the central project, I just changed the UUID that it is looking for from BLE_UUID_RUNNING_SPEED_AND_CADENCE to BLE_UUID_HUMAN_INTERFACE_DEVICE_SERVICE, just so it wouldn't connect, but keep scanning.

    Then I added the BLE_GAP_EVT_ADV_REPORT to the ble_evt_handler, to see the advertisement reports.

    Then I printed out what channels and the length of the advertising packet.

    What I saw is that I don't get the original advertising packet at all (the ones on channel 37, 38 and 39). It looks like they are stripped away from the softdevice, because they only contain the information of what channel and phy the extended advertising is coming on. So in fact, all the data that you send is sent in the extended advertising packet.

    You may want to turn down the advertising interval, and to insert your peripheral's advertising address in the if check to filter out the other advertisements, or it will be a lot of text printed. To see what address you have, use nRF connect for Desktop, and flash the peripheral DK with another example that doesn't use extended advertising. addr[0] is the address byte to the far right:

    Check out the implementation I used to test:

    static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
    {
        ret_code_t            err_code;
        ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
    
        switch (p_ble_evt->header.evt_id)
        {
            case BLE_GAP_EVT_ADV_REPORT:
                //if (p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[0] == 0xD3) // comment in this line, and change it to match the address of your DK
                {
                    NRF_LOG_INFO("adv_report from %02x:02x:02x:02x:02x:02x", p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[0],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[1],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[2],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[3],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[4],
                                                                            p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[5]);
                    uint8_t channel = p_ble_evt->evt.gap_evt.params.adv_report.ch_index;
                    uint16_t len = (uint16_t)p_ble_evt->evt.gap_evt.params.adv_report.data.len;
                    NRF_LOG_INFO("adv_report channel %d, len %d", channel, len);
                    
                    NRF_LOG_INFO("advertisement:");
                    for (uint16_t i=0; i<len; i++)
                    {
                        NRF_LOG_RAW_INFO("%02x", p_ble_evt->evt.gap_evt.params.adv_report.data.p_data[i]);
                        if(i%10 == 0 && i != 0)
                        {
                            NRF_LOG_RAW_INFO("\r\n");
                        }
                        else if(i<len-1)
                        {
                            NRF_LOG_RAW_INFO(":");
                        }
                    }
                    NRF_LOG_RAW_INFO("\r\n");
                }
                break;
                case ...

Children
Related