This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Advertising 1650 bytes of Host advertising data in an Auxiliary segment using Advertising Extensions

The BLE core specification states that using advertising extensions, the total host advertising data that can be advertised is 1650 bytes. This is achieved through fragmentation of data in multiple PDUs and chaining them together as one Auxiliary segment. 

I implemented extended advertising on nRF52832, and advertised custom data using the Manufacturer Specific Data field. But the maximum buffer size that I could provide for my advertising data was equal to BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED, which has the value 255 bytes. The advertisements were non-connectable and non-scannable undirected, and this 255 bytes of data used one AUX_ADV_IND PDU and one AUX_CHAIN_PDU. Thus I'm only able to send a maximum of 255 bytes of advertising data in one extended advertising event.

But I actually wanted my application to use more ADV_CHAIN_IND PDUs and fragment 1650 bytes of data as the specification says. Does your SoftDevice support sending 1650 bytes of data in a single extended advertising event? 

Parents
  • Hi Gautam, 

    Unfortunately it's not supported in our Softdevice in nRF5 SDK. 255 is the maximum data length for a chained advertising data set. 

    You can have a look here: https://devzone.nordicsemi.com/f/nordic-q-a/38702/maximum-extended-advertising-data-length-supported

    However, it's supported with our BLE stack in NRF Connect SDK. So if it's possible to change the SDK, I would suggest to have a look at the nRF Connect SDK. 
    What you need to change is to set CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=1650.

    Note that the nRF5 SDK is legacy development platform and we will not add new feature to the SDK. And if you want to have new feature and be "future proof" we would strongly suggest to move to nRF Connect SDK. 

  • Hey!

    Understood! Thanks for the quick and crisp response, Hung!

    Have a good day! Slight smile

  • Hi Hung!! 

    So following your suggestion, I shifted to nRF Connect SDK. I altered the periodic_adv sample and am using it for extended advertising. As you suggested, I set CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=1650. But unfortunately, I am still not able to get the AUX_CHAIN_IND PDUs.

    Basically, I am using the Manufacturer Specific Data type to advertise the data. However, I am still not able to send more than 249 bytes of data. This includes 1 byte of AD Type and 2 bytes of Company Identifier code. Thus, effectively, I'm able to send only 246 bytes of custom Payload.

    This is happening probably because the controller is not fragmenting the data into chain PDUs when it exceeds 255 bytes in total. All I'm getting is an AUX_ADV_IND PDU of length 255 bytes. Can you please suggest how to achieve advertising data chaining? 

  • Hi Sukriti, 

    I have tested here and saw the same problem. Only the first bytes got transmitted with AUX_ADV_IND when the rest 254 bytes gone missing. 
    I am checking with our team to see what could be the problem, this feature is expected to be supported in current nRF Connect SDK. 

  • Eagerly waiting for a positive response from your end! 

Reply Children
  • Hi Sukriti, 
    After the discussion with the R&D team, it's turned out that the issue was with the length definition of bt_data:  

    struct bt_data {
        uint8_t type;
        uint8_t data_len;
        const uint8_t *data;
    };
    Max length is uint8_t meaning the cap is 255. 

    To be able to advertise more than 255 bytes you would need to define multiple ad structure. 

    For example this one worked for me: 
    static const struct bt_data ad[] = {
        BT_DATA(BT_DATA_MANUFACTURER_DATA, mfg_data, 200),
        BT_DATA(BT_DATA_MANUFACTURER_DATA, mfg_data, 200),
        BT_DATA(BT_DATA_MANUFACTURER_DATA, mfg_data, 200),
        BT_DATA(BT_DATA_MANUFACTURER_DATA, mfg_data, 200),

    };
    I can see 800 bytes advertising in 4 chained adv packet. 
Related