Maximum extended advertising data length supported

[Olivier Balitch]

Hello,

I have PCA10040 development board with nRF52832, Softdevice S132 v6.1.0 & SDK 15.1.0). I wanted to use the extended advertisement feature to advertise more than 255 bytes of data.

Looking:

- In the release note (s132_nrf52_6.1.0_release-notes.pdf), I see that chained advertisement is supported since v6.1.0

- On the nordic site at https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.sds%2Fdita%2Fsoftdevices%2Fs130%2Fs130sds.html, I read "Advertising and scanning up to 255 bytes of advertising data in an advertising event".

- In the ble_gap.h header file, I see  BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED = 255.

The information in the release note, the site and the code are not consistent to me and it's not clear that chained advertisement are supported.

The BLE specification mentions that up to 1650 bytes could be sent in an extended advertisement. So, if chained advertisement is supported,  I would have imagined that  BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED > 255 with a maximal value of 1650.

Do you confirm that s132 supports chained advertising? If yes how many chained packet does s132 softdevice support?

What is the BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED define for? How do you ensure user does not provide more than 1650 bytes?

While writing the above lines, I noticed that in ble_gap.h there is a define set to 1650 (only for "advertising data received from advertiser" says the comment).

#define BLE_GAP_SCAN_BUFFER_EXTENDED_MAX           (1650)                           /**< Maximum data length for an
                                                                                         extended advertising set. */
#define BLE_GAP_SCAN_BUFFER_EXTENDED_MAX_SUPPORTED (255)                            /**< Maximum supported data length for
                                                                                         an extended advertising set. */

The BLE_GAP_SCAN_BUFFER_EXTENDED_MAX_SUPPORTED define makes me think again that the maximum supported data is 255 not 1650 which means that chained advertising is not supported. Do you confirm my understanding?

Thanks.

Best regards,

Olivier

[Kenneth]

Hi,

The hardware limit the maximum on-air packet to 255 bytes, in this case the 255 bytes must be split between adv mode, extended headers and advertisement data. The softdevice api have limited the max advertisement data also to 255 bytes (likely due to some internal implementation trade-offs).

Then depending on the length of the total advertisement packet (mode+headers+data), it may be split into 2 on-air packets, hence the advertisement packets are chained.

Best regards,
Kenneth

[Olivier Balitch]

Hi Kenneth,

Thanks for your quick feedback. If I understand you correctly, you are saying that chained advertisement is supported and that the on air packet can contain up to 255 bytes.

The BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED is the define being used to limit the number of bytes per packet. Is that correct?

What is the maximum number of chained packet supported or the maximum supported length for extended advertising data with s132 softdevice & nRF52832?

How do you ensure user does not provide more than 1650 bytes (length given in the BLE Core specification)?

Best regards,

Olivier

[Kenneth]

Hi, 

BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED is the total number of bytes supported, in this case 255 bytes, this means that the total number of "chained" advertisement packets are up to 2 (or 1 depending on whether you call the first packet "chained"). Two packets are required since 255 bytes will not fit into one advertisement packet due to headers. I agree it is slightly odd calling it "chained" advertisement packets, since the second packet is only a few bytes long in most cases.

Best regards,
Kenneth

[Olivier Balitch]

Hi Kenneth,

Ok, that's very clear.

Thanks.

Best regards,

Olivier