1. Introduction

1.1. Before You Start

Before you start you need to:

  • Install the latest SmartSnippets Studio

  • Download the latest SDK version (current version is SDK v6.0.12 for DA14585/DA14586 and DA14531).

These can be downloaded from the Dialog Semiconductor support portal.

Additionally, for this tutorial, either a Pro or USB Development kit 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 Dialog SDK

  • Verify the correct functionality of the Bluetooth Low Energy device using the SmartSnippets Toolbox (integrated in the SmartSnippets Studio)


This document is applicable to both the SDK 5.0.x (DA14580/1/2/3) and SDK 6.0.x (DA14585/6 and DA14531) if it is not mentioned specifically for a particular application.

1.2. Bluetooth Low Energy Protocol

Bluetooth Low Energy protocol stack

Figure 1 Bluetooth Low Energy Protocol Stack

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:

'Bluetooth Low Energy data payload'

Figure 3 BLE Packet Format

A packet can be 80 to 376 bits in length, and has the following fields:


This field is used for synchronization purposes and it’s always an alternating sequence of 0s and 1s, i.e. 0xAA or 0x55.

Access Address

This field is always 0x8E89BED6 for advertising packets. It serves as a correlation mechanism between transmitting and receiving devices.


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.

Table 2 Advertising Packets




Connectable undirected advertising event


Connectable directed advertising event


Non-connectable undirected advertising event


Scannable undirected advertising event


Response to Scan Request from Scanner


Connect Request by Initiator


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).

Table 3 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).

'Advertising Data Format'

Figure 4 Advertising Data Format

The following example shows the decoding of the Advertising Data sent by the DA14585/DA14586 or DA14531 device using a barebone example.

'Advertising Data Format 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.