BlueNRG-MS v7.2c Central is not receiving ADV_IND & SCAN_RSP > 18 bytes - why it cannot receive up to MAX_ADV_DATA_LEN?

[Scott Löhr]

Posted on May 12, 2018 at 05:47

Hello - wrt the maximum total size of a BLE advertisement or scan response of 31 bytes:

The BlueNRG-MS v7.2c Peripheral can generate either at max expected length.

But when I run the BlueNRG-MS v7.2c Central, if the total length of either packet is > 18 bytes, then the corresponding ADV_IND or SCAN_RSP event is never received as a EVT_LE_ADVERTISING_REPORT event.

The Central device of the embedded BLE stack of the 3 other vendor platforms I have evaluated can all receive up to the maximum total length of either the advertisement or scan response in addition to the BLE stacks on the iOS and Android devices.

Is this observation caused by an error in my implementation of the ST BlueNRG Central, or is it a known and documented limitation? It is suspicious that the BlueNRG-MS Peripheral can produce either at the max length of 31 bytes, but the Central is limited to 18 bytes total. Even more suspicious is that the observed limit of 18 is less than a full length Notification of 20 bytes, which my implementation of the BlueNRG Central can receive once connected.

To be sure, bluenrg_gap.h contains this constant:

&sharpdefine MAX_ADV_DATA_LEN                        (31)

#bluenrg-ms-adv_ind-scan_rsp-max_adv_data_len

[Scott Löhr]

Posted on May 14, 2018 at 19:32

Note that today I have changed the title of this question since it may have looked like I was asking the community what is the max length of the advertising data or scan response. To be clear, I understand that it is 31 bytes total and very well documented. I am reporting an observation that when running the ST BlueNRG-MS with v7.2c, configured as a GAP_CENTRAL_ROLE_IDB05A1 in Mode 4 (Mode 4: master/slave, 4 connections, RAM1 and RAM2 simultaneous scanning and advertising), if a BLE Peripheral implements an advertisement or scan response that is longer than 18 total bytes (yes, I know, those bytes have to be carefully constructed according to specification as length byte, data type, data; length byte, data type, data...) then the ST BlueNRG-MS Central device never generates the corresponding ADV_IND or SCAN_RSP event to the application. I note that using the BlueNRG-MS with v7.2c, configured as GAP_PERIPHERAL_ROLE_IDB05A1, the ST BlueNRG-MS Peripheral can generate advertisements and scan response with MAX_ADV_DATA_LEN bytes, and using the embedded BLE Central demos of other vendors, the Central can receive this max length.

Thus I am asking the community for help with this:

- can you duplicate this observation?

- if not, can you imagine the mistake that I am making working with the ST BLE Central sample application that could cause this limitation?

- if yes, is this limitation of the ST BLE Central documented as an erratum and/or scheduled to be fixed in an imminent f/w release for the BlueNRG-MS?

[Scott Löhr · Accepted solution]

Posted on May 18, 2018 at 05:37

How embarrassing - and I cannot even delete this post (only comments to posts)  :\

Anyway, when I originally ported the ACI sample app code ~2 years ago, I was only focused on the BLE Peripheral, and the biggest packet I had ever seen was 22+3 bytes, so I rounded up and set a max expected packet size from the BlueNRG-MS to 30+3 bytes for the FreeRTOS queues that I push them into in the BlueNRG-IRQ interrupt for later processing at the task level. Well, that max size has been good enough to get a lot of useful stuff working, even as a BLE Central ... until now, of course, when I ran into this issue of not being able to find an advertising Peripheral with bigger advertisement/scan response data sizes.

Now a hci_uart_pckt --> hci_event_pckt --> evt_le_meta_event --> le_advertising_info with a 31-byte advertising/scan response payload (and the empirical result that BlueNRG-MS only ever passes 1 advertisement/scan response at a time even though the byte for #of messages implies that there could be more, there never is) all of this requires a receive buffer of at least 43+3 bytes. So I will bump up the max Rx buf size accordingly and see how many years I can last before I make another embarrassing post for help ... or maybe I will still be able find this one and mercifully be reminded of where to look   :-0