The feature – LE Advertising Extensions – is introduced by Bluetooth Specification Version 5.0. It defines 2 types of advertising channels, primary advertising channel and secondary advertising channel. Channels from 0 to 36 known as LE piconet channels in Bluetooth Specification 4.2 or earlier versions can also be used to send advertisements, and they are called secondary advertising channels. Table 1 shows the differences between Bluetooth 5.0 and earlier versions supporting this feature.
|Bluetooth 4.2 or earlier||Bluetooth 5.0|
|Channels – 37, 38 and 39||Advertisement broadcast channel||Primary advertising channel|
|Channels – 0 to 36||LE piconet channel||LE piconet channel or secondary advertising channel|
|Max payload for single adv packet (AdvData)||0-31 bytes||0-254 bytes|
Table 1. Comparison of Bluetooth 5.0 and earlier versions
The PDU payload of primary advertising channels can vary in length from 6 to 37 bytes, 6-byte address is mandatory to present in the packet, so the advData is limited to no more than 31 bytes, the same as previous versions. Bluetooth 5.0 introduces a way to use secondary advertising channels to offload the data that would otherwise be transmitted on the primary advertising channel. The advertising packets on primary channels contain the information in which secondary advertising channel and the offset to the start time the auxiliary data will be transmitted. Figure 1 shows the timing of extended advertising.
Figure 1. Timing of extended advertising
ADV_EXT_IND – advertising packets on primary advertising channels. These packets only include the information on which channel and when the AUX_ADV_IND will happen.
AUX_ADV_IND – advertising packet on secondary advertising channels. This packet could contain up to 254 bytes payload.
The procedure of a scanner to scan an extended advertising looks like:
Silabs Bluetooth SDK has the support for Bluetooth LE advertising extensions feature since version 2.9.0, the limitation for now is the maximum advertising data is 191 bytes. Users don’t need to do the above 3 steps by themselves because the Bluetooth stack will do it and users just need to configure the advertising packet payload and set the advertising type then start advertising. Note, the advertising cannot be scannable and connectable at the same time according to the Bluetooth 5.0 SPEC.
To run this example, you will need to download Simplicity Studio and the attachment at the end of this article.
Figure 2. RTT
Figure 3. Tera Term
Attached the source code for scanner.bin file, the project is based on Bluetooth SDK 2.9.2. There are some codes not used at all because the project is derived from other purpose.
Hi, Thanks for providing with an example.
Although, I haven't been able to try the sample myself yet, I have looked at the code in Attachment.zip.
I understood the code, its just that I did not see any calls to 'gecko_cmd_le_gap_set_advertise_phy' .
Is it not necessary to use this call with 'le_gap_phy_coded' parameter to use Extended Advertisements?
Additionally, will this AE be visible in scanning when tried with a Bluetooth 5.0 enabled mobile handsets (e.g iPhone X or OnePlus-5)?
This example uses the standard 1M PHY, it doesn't need to call the set_advertise_phy function to set it to the coded phy. I didn't test it with any smartphones.
Thanks for responding Kevin.
I'd just like to clear a thing or two from my understanding perspective.
Isn't it true that For Advertisement Extensions (or Extended Advertisements) it is mandatory to use coded PHY channel? If no, can I advertise user data of 100+ bytes on standard 1M PHY using 'gecko_cmd_le_gap_set_advertise_phy(0, le_gap_phy_1m, le_gap_phy_1m);'
I can see that maximum limit in the current SDK version is 191 Bytes.
So could you validate the steps that I am following:
My code looks like this:
// Some code
// Assumption: By now the code above has set the user data and length properly
// length is 100+ Bytes set in variable 'len' and 'pData' is the pointer pointing to data
/* After looking at the example Attachment.zip I am not certain about if I require le_gap_phy_coded */
gecko_cmd_le_gap_set_advertise_phy(0, le_gap_phy_coded, le_gap_phy_coded);
gecko_cmd_le_gap_bt5_set_adv_data(0, 0, len, pData);
gecko_cmd_le_gap_start_advertising(0, le_gap_user_data, le_gap_scannable_non_connectable);
//gecko_cmd_le_gap_start_advertising(0, le_gap_user_data, le_gap_connectable_non_scannable);
I may have the requirement to send data lesser than 31 bytes at times. Secondly, I am using 'le_gap_scannable_non_connectable' as the device has to be non-connectable. As I understand, with Advertisement Extensions a device can either be connectable or scannable at a time. It can not be both at the same time.
Is above sequence correct?
As I understand the Core SPEC, I don't see there is any statement that the AE must be on coded PHY. The sequence you used to send extended advertising is fine.
"I may have the requirement to send data lesser than 31 bytes at times. Secondly, I am using 'le_gap_scannable_non_connectable' as the device has to be non-connectable. As I understand, with Advertisement Extensions a device can either be connectable or scannable at a time. It can not be both at the same time. "
-> Yes, that's true.
I purchased a SLWSTK6020B which is a Bluetooth Kit for EFR32™ Blue Gecko SoCs (https://www.silabs.com/products/development-tools/wireless/bluetooth/blue-gecko-bluetooth-low-energy-soc-starter-kit)
I downloaded the source code for the scanner that is provided (scanner.zip) .
I also have a Blue Gecko Starter Kit - SLWSTK6101C (https://www.silabs.com/products/development-tools/wireless/bluetooth/bluegecko-bluetooth-low-energy-module-wireless-starter-kit) and a Blue Gecko Bluetooth® Module +8 dBm Output Power Radio Board (SLWRB4306A).
I am using the SLWRB4306A as a advertiser and SLWSTK6020B as Scanner, with the source codes provided above.
When advertisement mode is set to extended in SLWSTK6101C advertiser, I can not see the extended advertisement packets as shown in figures above.
When I change the advertisement mode to legacy in advertiser, I can see the BLE advertisements on my BLE 4.2-Enabled mobile handset, but I do not see anything on JLink-RTT Terminal (Can only be accessed while SLWSTK6020B is in debug mode).
In all cases, the Terminal displays "Scan result............................Number of adv = 0"
Can you help me with what am I missing here?
(I can see a U.FL connector for antenna on SLWRB4104A, but antenna is not connected, if it matters, please let me know)
In the scanner example, when it receives the adv from peer devices, it filters out only the extended adv, as you can see below lines:
case gecko_evt_le_gap_scan_response_id: // filter only cares extended adv if(evt->data.evt_le_gap_scan_response.packet_type && 0x80) insert_item(&evt->data.evt_le_gap_scan_response); break;
This is why you won't get legacy adv in the scanner. But I don't know why you can't get the extended adv, I want you to confirm which radio board you were using for the scanner, is it BRD4100 or BRD4104? I think you should use the BRD4104a because BRD4100 doesn't support AE if I remember correctly.
Hi Kevin, thank you for responding.
I didn't realise that it filters out legacy advertisements and proceeds only with Extended advertisement packets, but I also had put a breakpoint at the 'if(evt->data.evt_le_gap_scan_response.packet_type && 0x80)' statement, which would have been evaluated as false for a legacy advertisement, the code never hit the breakpoint barring a few occasions where it had a dfu-related event, so I guess it is not receiving any advertisements at all.
I have confirmed that the scanner has a BRD4104a Rev A01 board. Please refer the attached image.
Will it make sense to use any of the sample application to make it act as a iBeacon and see if the BLE Radio is functional?
Also, any thoughts on if antenna is mandatory?
Sorry that I forgot to answer your question about the antenna in my last comment, it's not mandatory. There is a PCB antenna in the radio board, and there is also a 0 Ohm switch to change which the radio connects to, and by default, it connects to the PCB antenna.
It's weird that it doesn't work, because what I used to develop and verify this example works is exactly BRD4104a boards. Could you first check with the basic examples in the SDK to make sure there is no problem with the board in any ways. If nothing wrong is found, I may need to know what you modified to the examples to have the problem reproduced on my side.