1. Introduction
1.1. Before You Start
- Before you start you need to:
Install the latest SmartSnippets Studio
Download the latest SDK version .
These can be downloaded from the Renesas Engineering community portal. Additionally, for this tutorial, either a DA14531/DA1453x Pro or USB Devkits is required.
The goal of this tutorial is not to cover every detail related to advertising but to:
Provide a basic understanding of the Bluetooth Low Energy advertising concepts
Explain how to change the advertising contents and connection parameters using the Renesas SDK
Verify the correct functionality of the Bluetooth Low Energy device using the SmartSnippets Toolbox (integrated in the SmartSnippets Studio)
DA1453x is referring to DA14531-00, DA14531-01, DA14530, DA14535 and DA14533
The DA14531-00 is the main DA14531 device. The -00 is just a new naming to introduce the variant DA14531-01. The DA14531-01 is a ROM variant of the main DA14531-00.
The DA14535 is a DA14531 upgrade.
The DA14533 is optimized for automotive and industrial applications at higher temperatures, and it is rated as operating up to 105 ºC and compliant with the AEC-Q100 (Grade 2) standard.
DA1458x is referring to DA14585 and DA14586.
Note
This document is applicable to both the SDK 5.0.x (DA14580/1/2/3) and SDK 6.0.x (DA14585/6 and DA1453x) if it is not mentioned specifically for a particular application.
1.2. Bluetooth Low Energy Protocol
Figure 1 Bluetooth Low Energy Protocol Stack
1.2.1. BLE Link-Layer States
State |
Description |
---|---|
Standby |
Does not transmit or receive packets |
Advertising |
Broadcasts advertisements in advertising channels |
Scanning |
Looks for Advertisers |
Initiating |
Initiates connection to Advertiser |
Connection : Master Role |
Communicates with device in the Slave role, defines timings of transmissions |
Connection : Slave Role |
Communicates with a single device in Master Role |
Figure 2 BLE Link-Layer States
1.3. Advertising State
When a Bluetooth Low Energy device wants to communicate its presence to other devices in the area, it broadcasts small packets of data which are called advertising packets or advertisements.
- An advertising packet can be used to:
Indicate to other devices, either publicly or targeted, that the device is ready to accept a request for connection.
Broadcast information to devices nearby.
An advertising packet is small and has a well-defined format. As a result, only a restricted amount of user data can be carried. To work around this restriction, the Advertising State also supports, upon request, the transmission of a secondary Scan Response packet which contains additional data. These data can be requested by a potential client using a Scan Request without establishing a permanent connection to the device.
- An advertising packet is made up of a number of fields which typically includes:
The name of the device
Some or all of the services supported by the device
Advertising packets may also contain proprietary manufacturer-specific data and flags declaring the capabilities of the device. This is explained in detail in the Changing the Advertising Data section.
1.3.1. Packet Format
Bluetooth Low Energy implements only one link-layer packet format, which is illustrated in the following figure:
Figure 3 BLE Packet Format
A packet can be 80 to 376 bits in length, and has the following fields:
- Preamble:
This field is used for synchronization purposes and it’s always an alternating sequence of 0s and 1s, i.e.
0xAA
or0x55
.- Access Address:
This field is always
0x8E89BED6
for advertising packets. It serves as a correlation mechanism between transmitting and receiving devices.- PDU:
There are two Protocol Data Unit (PDU) formats, one for advertising packets and one for data packets. The Advertising PDU consists of the 16-bit PDU header and the payload. If the advertising mode allows it, the active Scanner (via a Scan Request) may request up to 31 bytes of additional information from the Advertiser. This means that a sizeable portion of data can be received from the advertising device even without establishing a connection.
The first field of the PDU header is the PDU Type. Table 2 shows the seven advertising PDU Types.
Packet |
Usage |
---|---|
ADV_IND |
Connectable undirected advertising event |
ADV_DIRECT_IND |
Connectable directed advertising event |
ADV_NONCONN_IND |
Non-connectable undirected advertising event |
ADV_SCAN_IND |
Scannable undirected advertising event |
SCAN_RSP |
Response to Scan Request from Scanner |
CONNECT_REQ |
Connect Request by Initiator |
SCAN_REQ |
Scan Request for further information from Advertiser |
The first distinction that we can make, is that some devices may wish to make their presence and connection availability known only to a particular device. For this purpose they could use the ADV_DIRECT_IND type and include in their payload both their address and the Initiator’s. When an Advertiser sends an ADV_DIRECT_IND type packet, it can only accept a Connect Request by the designated device. Any Scan Requests will be ignored.
For some application purposes the Advertiser doesn’t want to allow any connections to it by other devices. This is especially the case for BLE Beacons, which advertise data like temperature or other sensor measurements, and setting a connection link with other devices wouldn’t be efficient. The ADV_NONCONN_IND type serves this purpose.
In the previous case, the Advertiser doesn’t allow any connections or requests to it, but in some instances there may be additional data that won’t fit in the remaining available payload or this would consume more power on average. Setting the ADV_SCAN_IND would allow any interested device to ask for more information by means of a Scan Request.
If a scanning device wants to request more information, for the cases of ADV_IND or ADV_SCAN_IND packets, then it has to set the PDU type of the request packet to SCAN_REQ. The Advertiser will then answer with a SCAN_RSP packet type and the additional data. If the Scanner wants to connect to the Advertiser, it will do it with a CONNECT_REQ packet type.
For more details, you can refer to table 2.3 in the Bluetooth 5.0 spec (Vol 6, Part B, section 2.3).
1.3.2. Payload Format
Figure 3 shows the payload of an ADV_IND packet. The total size of the advertising payload is between 0 and 37 bytes long. This payload has an advertisement address of 6 bytes and a variable number of advertisement data structures (0 to 31 bytes).
Payload |
|
---|---|
Advertisement Address (AdvA) (6 Bytes) |
Advertisement Data (AdvData) (0 to 31 Bytes) |
Table 3 shows the fields of the PDU. You can see the possible advertising data type (AD Type) values listed in the Bluetooth SIG website (not in the Core Specification document).
Figure 4 Advertising Data Format
The following example shows the decoding of the Advertising Data sent by the DA14585/DA14586 or DA1453x device using a barebone example.
Figure 5 Advertising Data Format example
In this example, we can identify four AD elements (AD0, AD1, AD2, and AD3). Their respective data types are:
0x01 = flags: Multiple one-bit boolean flags. The AD0 flags value is
0x06
(00000110); that means that two flags are set on Bit 1 and Bit 2. According to table 18.1 (Flags) on the Core specification these flags are:Bit 1: LE General Discoverable Mode
Bit 2: BR/EDR Not Supported
0x03 = Complete List of 16-bit Service Class UUIDs: A list of one or more UUIDs indicating which services are supported. In this example, the AD1 value is 0x180A which corresponds to Device Information Service. The Bluetooth website provides a complete list of the adopted service UUIDs values.
0x09 = Complete Local Name: Contains the human-readable device name that is discovered by the Central. The AD2 value is DLG-TUTORIAL.
0xff = Manufacturer specific: A specific AD Type reserved for proprietary data.