Maximum number of bytes that can be used in beacon advertising.

[ysuleiman]

In the ble_app_beacon example in nRF SDK 17.02, there are two defines namely APP_BEACON_INFO_LENGTH (0x17) and APP_ADV_DATA_LENGTH (0x15). The former defines length of the array namely m_beacon_info[] which is 23 bytes. And this array will be passed to the manuf_specific_data struct. My question is :

1. Will this 23 bytes be received at the scanner side after parsing 31 bytes of data frame which is actually received by the receiver's radio or even lesser than that?

2. I read somewhere that BLE GAP allows 26 bytes to be used as manufacturer specific data? Would it be alright to actually include the remaining bytes (3 bytes) into the m_beacon_info and then pass it to the manuf_specific_struct in the similar manner so that we retrieve these 26 bytes at the scanner's side?

3. Can we use these 26 bytes of data as we please like filling the m_beacon_info array with whatever information we want to like string, numbers, etc?

4. Am I right to guess that APP_ADV_DATA_LENGTH (0x15) indicates the number of data bytes that follows so that the BLE stack can parse through it exactly to the number of bytes of data (17 bytes) to access?

5. Beacon is by definition unconnectable, so the idea of scan response data shouldn't work with beacon, right? To make use of scan response data, we will have to advertise with normal advertising which uses gap_params_init() and gatt_init or is it still possible with beacon?

6.  I checked a few of the scanner codes on the forum. The one I have checked doesn't use gap_params_init() which is understandable since no connection is made. But one of them uses gatt_init() and the other doesn't use gatt_init(). What exactly does gatt_init() do? Can GATT work independent of GAP (we don't initialize GAP yet we can initialize GATT)?

Thank you so much. I would highly appreciate the clarification.

[ovrebekk]

Hi 

1. Will this 23 bytes be received at the scanner side after parsing 31 bytes of data frame which is actually received by the receiver's radio or even lesser than that?

Not sure I understand this question. As long as all the advertising data fields fit on the transmitter side they will be successfully received on the other side as well.

If you try to cram more than 31 bytes into one packet you should get an error when trying to configure the packet. 

2. I read somewhere that BLE GAP allows 26 bytes to be used as manufacturer specific data? Would it be alright to actually include the remaining bytes (3 bytes) into the m_beacon_info and then pass it to the manuf_specific_struct in the similar manner so that we retrieve these 26 bytes at the scanner's side?

If all you have in the advertise packet is the manufacturer specific data field then you should have room for 27 bytes of data (plus 2 bytes for manufacturer ID, and the standard 1 byte length and 1 byte type fields). 

If you want to have room for the flags field in the packet you will lose 3 bytes, so then you are left with 24 bytes of data. 

It should be fine to change the m_beacon_info struct as you want, as long as you are not planning to be compatible with any other beacon systems out there. 

3. Can we use these 26 bytes of data as we please like filling the m_beacon_info array with whatever information we want to like string, numbers, etc?

Yes. As I said above you can put whatever you like in here as long as you implement both the beacon and the scanner side, and make sure they are set up the same way. 

4. Am I right to guess that APP_ADV_DATA_LENGTH (0x15) indicates the number of data bytes that follows so that the BLE stack can parse through it exactly to the number of bytes of data (17 bytes) to access?

APP_ADV_DATA_LENGTH is the length of the manufacturer specific data, not including the 2 byte company ID. 

APP_BEACON_INFO_LENGTH also includes the company ID. 

5. Beacon is by definition unconnectable, so the idea of scan response data shouldn't work with beacon, right? To make use of scan response data, we will have to advertise with normal advertising which uses gap_params_init() and gatt_init or is it still possible with beacon?

If you use the BLE_GAP_ADV_TYPE_NONCONNECTABLE_SCANNABLE_UNDIRECTED advertising type it is possible to send scan requests but not connection requests, in case you want to prevent anyone from trying to connect to you. 

Also, if you want to create a connectable beacon there is really nothing stopping you from doing this, unless you want to implement a specific beacon standard that doesn't allow it. There is nothing in the core Bluetooth specification saying you can't implement a connectable beacon. 

6.  I checked a few of the scanner codes on the forum. The one I have checked doesn't use gap_params_init() which is understandable since no connection is made. But one of them uses gatt_init() and the other doesn't use gatt_init(). What exactly does gatt_init() do? Can GATT work independent of GAP (we don't initialize GAP yet we can initialize GATT)?

All advertising and scanning functionality is exposed through the GAP interface.

The reason most of the scanner examples don't include a gap_params_init(..) function is that all the scan setup is handled by the nrf_ble_scan module, and the setup is done in the scan_init(..) function instead, but in the end both of these functions will call the GAP API under the hood (all GAP functions have the "sd_ble_gap" prefix). 

To put it another way, you can't do anything with BLE without interfacing with the GAP API

GATT on the other hand is only used after you have established a connection, and if any example is including gatt_init() it implies that the example supports connection establishment, and is not a pure advertiser or scanner example. 

Best regards
Torbjørn