Broadcast and Scan

Functions of Broadcasting

Broadcasting is the foundation of BLE device discovery and connection. Broadcast packets are sent by the broadcaster (Peripheral), and the master device (Central) discovers BLE devices and can establish connections with them by scanning broadcast packets.

BLE broadcasting functions
Function	Description
Scanning/Connection Discovery	Peripheral (slave device) allows Central (master device) to discover and connect through broadcasting
Direct Data Transfer Without Connection	Broadcast packets can carry a small amount of data, suitable for sending notifications, location information, sensor data, etc.
Signal Triggering Behavior	Such as iBeacon, Eddystone used for positioning, waking up applications, etc.
Device Identity Recognition	Broadcasting includes device name, UUID, manufacturer information, etc., which is convenient for identifying device types

Before reading this section, it is recommended to read the BLE Device Discovery section first to understand the introduction of BLE 4.2 broadcasting.

Common Data Types and Their Names in Broadcasting

In the BLE broadcast packet, each piece of data is composed of Length + Type + Value, and the Type field is defined according to the Bluetooth SIG specification. The following are common data types in broadcast packets.

BLE broadcast data types
Type (Hex)	Name (English)	Chinese Explanation	Common Uses/Notes
0x01	Flags	Flag bits, indicating device capabilities	Indicates whether it supports BR/EDR, whether it is in broadcast mode, etc., mandatory
0x02	Incomplete List of 16-bit UUIDs	Incomplete 16-bit service UUID list	Some of the GATT services provided by the broadcasting device
0x03	Complete List of 16-bit UUIDs	Complete 16-bit service UUID list	Notify all services, commonly used for general BLE peripherals
0x06	Incomplete List of 128-bit UUIDs	Incomplete 128-bit service UUID list	Part of the custom service’s UUID (128-bit)
0x07	Complete List of 128-bit UUIDs	Complete 128-bit service UUID list	Full broadcast of custom services
0x08	Shortened Local Name	Shortened device name	Save space, prioritize short names
0x09	Complete Local Name	Complete device name	Broadcast device name, visible when scanning with a mobile phone
0x0A	Tx Power Level	Transmission power level (dBm)	Used to estimate distance, in conjunction with RSSI
0x16	Service Data - 16-bit UUID	Service data with 16-bit UUID	Broadcast some service-related data (such as temperature, battery level)
0xFF	Manufacturer Specific Data	Manufacturer’s custom data segment	Widely used in iBeacon, Eddystone, custom protocols

For more broadcast data types, please refer to Assigned Numbers.

New Broadcast Features Introduced in BLE 5.0

BLE 5.0 introduces new mechanisms such as Extended Advertising and Periodic Advertising to break through some limitations of traditional broadcasting. The broadcasting in BLE 4.2 and previous versions is known as Legacy Advertising. Compared to BLE 4.x, Extended Advertising brings significant improvements and enhancements in broadcasting, with the main goal of supporting longer distances, larger data volumes, and more flexible low-power applications. Here is a comparison of the two types of broadcasting:

BLE 4.x vs BLE 5.0 Broadcast Feature Comparison
Feature/Difference	BLE 4.x	BLE 5.0
Broadcast Data Capacity	Up to 31 bytes	Up to 255 bytes (Extended Advertising)
Number of Broadcast Channels	Fixed 3 (37,38,39)	Supports more channels (all 40 available for Extended Advertising)
Broadcast Distance Support	Typically around 50 meters	Up to 200 meters (using Coded PHY)
Broadcast Rate	Standard 1 Mbps	Supports 2 Mbps high-speed broadcast
Broadcast Mode	Legacy Advertising	Added Extended Advertising Supports Periodic Advertising
Broadcast Connection Capability	Can only carry connection request information in broadcast	Broadcast data and connection requests can be separated, more flexible
Multi PHY Support (Physical Layer)	Only 1 Mbps	Added 2 Mbps and Coded PHY (500/125 kbps)
Broadcast Power Consumption vs Distance/Rate	Limited	Further, faster, more power-saving (according to configuration selection)

The biggest advantage of BLE 5.0 broadcasting (Extended Advertising) is the increase in broadcast data capacity. However, some mainstream mobile phones do not fully support BLE 5.0 broadcasting, and there may be problems such as connection failure, inability to search for broadcasts, and inability to parse broadcast data in actual use. If optimal compatibility is considered, it is recommended to use traditional broadcasting.

Known compatibility issues with Extended Advertising packets include:

IOS 18.5 devices may not be able to scan for 1M PHY Extended Advertising packets
Some Android devices may not be able to scan for non-1M PHY Extended Advertising packets

Broadcast API Usage Instructions

The NimBLE protocol stack provides two sets of broadcast APIs for BLE 4.x and BLE 5.0, each with corresponding configuration items and cannot be used simultaneously. For example, the bleprph_example example defaults to using the BLE 5.0 broadcast API. If you need to use the BLE 4.x broadcast API, in addition to turning off the example configuration item EXAMPLE_EXTENDED_ADV to make the main program call the 4.x broadcast API, you also need to turn off the broadcast configuration item BT_NIMBLE_EXT_ADV.

After the launch of BLE 5.0, traditional broadcasting is considered a subset of BLE 5.0 broadcasting, and the BLE 5.0 broadcasting API can also send traditional broadcasts. For specific implementation code, refer to the ble_multi_adv_example example.

Explanation of Broadcast Parameters

For the configuration of broadcast connection parameters, refer to the ble_gap_ext_adv_params structure.

The following configuration items need special attention:

itvl_min: Unit is 1.25 ms, the value range is 0x0006 to 0x0C80
itvl_max: Unit is 1.25 ms, the value range is 0x0006 to 0x0C80
channel_map: Specifies the channels used for broadcasting, 0x00 represents the default three channels, 0x01, 0x02, 0x04 represent channels 37, 38, 39 respectively, 0x07 represents all three channels 37, 38, 39
own_addr_type: 0x00, 0x01, 0x02, 0x03 represent the broadcast address types of public address, random address, resolvable public address, and resolvable random address respectively

In addition, when configuring the broadcast type, it should be noted that non-directed connectable broadcasts must be scannable.

Scanning

Scanning is the basis for discovering and connecting BLE devices. The central device discovers BLE devices and can establish connections with them by scanning broadcast packets.

For theoretical knowledge related to scanning, please refer to the Basic Concepts of Scanning section.

Instructions for Using Scanning API

Similar to broadcasting, in the NimBLE protocol stack, two sets of APIs are provided to start scanning, namely ble_gap_disc and ble_gap_ext_disc.

Use the ble_gap_disc API to start scanning. The scanning-related configuration items are configured by the ble_gap_disc_params structure. For usage, refer to the examples blecent and ble_multi_adv.
Use the ble_gap_ext_disc API to start scanning. The scanning-related configuration items are configured by the ble_gap_ext_disc_params structure. For usage, refer to the example ble_multi_conn.

Note

Avoid printing too much data in the scanning callback, otherwise the task watchdog may be triggered if there are too many surrounding devices and the printing is not timely.

Broadcast Packet Filtering

Configure disc_params.filter_duplicates = 1 to enable broadcast packet filtering. However, the specific method of broadcast packet filtering is determined by the configuration item BT_CTRL_SCAN_DUPL_TYPE.

Scan Duplicate By Device Address (default): Filters broadcast packets from the same device address
Scan Duplicate By Advertising Data: Filter identical broadcast packets
Scan Duplicate By Advertising Set Handle: Filters broadcast packets from the same device with the same content

The number of scan response packets and broadcast packets received is inconsistent.

The protocol stipulates that devices should not send scan requests for every consecutive advertisement packet to avoid generating excessive responses. If this function is indeed necessary, ESP32-C3 and previously released chips can enable the configuration item BT_CTRL_SCAN_BACKOFF_UPPERLIMITMAX, while ESP32-C2 and later chips can force the initiation of scan requests by setting the configuration item BT_CTRL_SCAN_BACKOFF_UPPERLIMITMAX to 1.