Bluetooth 5 Advertisements: Everything you need to know

You’ve probably heard so much about the recently released Bluetooth 5.

You’ve seen all the hype on 2x Speed, 4x Range, and 8x Advertising data increase capabilities.

But what does this all mean?? How does it achieve all these improvements? Is it really possible to achieve all these simultaneously?? What about power consumption? How is that affected?

Look:

There was so much media hype surrounding the release of Bluetooth 5, and lots of conflicting information with very few details. Many media articles made it sound like you can achieve all these simultaneously!

In this first post of a series on Bluetooth 5, I’ll go ahead and demystify all these facts for you as well as cover Bluetooth 5 Advertisements in detail.

The goal with this series of blog posts is:

  • Fully understand the 3 main improvements that Bluetooth 5 achieves (Speed, Range, and Advertisements).
  • Know which of these will benefit your application/use-case the most.
  • How you can utilize the new improvements of Bluetooth 5 to your advantage.
  • How to determine whether a BLE chip/module supports the new features you’re interested in utilizing.
  • Which applications and use cases will benefit from each of these improvements.
  • Have a full example of implementing each of these features on a chosen platform.

First, let’s make it clear that Bluetooth 5 does not achieve both increased range and speed simultaneously – in fact, you will absolutely sacrifice speed in favor of range and vice versa!

A few things to note:

  • Not all these new Bluetooth 5 features require new hardware.
  • Some vendors will provide software updates to support some of these new features of Bluetooth 5 (for features that don’t require a hardware update).
  • Vendors can claim Bluetooth 5 support, but they won’t necessarily support the popular improvements, so be careful when choosing a module/chip with the intention of utilizing higher speeds or extended range. According to the spec section Volume 1, Part A, 1.2:

The mandatory symbol rate is 1 megasymbol per second (Msym/s), where 1 symbol represents 1 bit therefore supporting a bit rate of 1 megabit per second (Mb/s), which is referred to as the LE 1M PHY. The 1 Msym/s symbol rate may optionally support error correction coding, which is referred to as the LE Coded PHY.

An optional symbol rate of 2 Msym/s may be supported, with a bit rate of 2 Mb/s, which is referred to as the LE 2M PHY.

Notice the “optional” keyword in both cases of the LE 2M PHY (achieving 2x speed) and LE Coded PHY (achieving longer range via Forward-Error Correction).

PHY is the term used to refer to the Physical Layer of Bluetooth technology. For more info on the term, refer to the Wikipedia article on PHY.

So, let’s take a look at what’s new with Bluetooth 5.0 (compared to 4.2 and earlier versions). Several new features are introduced in the Bluetooth Core Specification 5.0 Release (compared to version 4.2):

  • Slot Availability Mask (SAM)
  • 2 Msym/s PHY for LE
  • LE Long Range
  • High Duty Cycle Non-Connectable Advertising
  • LE Advertising Extensions
  • LE Channel Selection Algorithm #2

We will start by talking briefly about the new higher speed 2 Msym/s PHY and the Long Range feature (utilizing the Coded PHY). After that, we will go deep into Bluetooth 5 Advertisements in general as well the new LE Advertising Extensions feature. In upcoming posts, we’ll go over each of the longer range and higher speed features in more detail.

We will also go over how to implement Extended Advertisements on the nRF52840 Preview Development Kit and provide the complete source code. Since these are new Bluetooth 5 features, an app such as nRF Connect or any other smartphone app that’s running on a non-Bluetooth 5 supported device won’t be able to discover the advertisements. This is why we will be using the new Bluetooth Tracker by Ellisys. The Tracker is one of the best commercial sniffers out there (if not the best) because of its form factor, competitive price and elegant software UI design compared to others out there, and best of all it fully supports Bluetooth 5.

Bonus: Download my free report on the 5 Essential Bluetooth Low Energy Tools which help you develop for BLE in the most efficient manner.

How Bluetooth 5 increases speed to 2x and range to 4x

With the addition of the new 2 Msym/second PHY, Bluetooth 5 can now transfer data at 2x the rate of the original 1 Msym/s PHY. There are three PHYs in Bluetooth 5:

  • 1 Mbps PHY: This PHY is mandatory and is uncoded (modulated at 1 Megasymbol/sec). Uncoded means that each symbol is represented by exactly one bit, so a theoretical data rate of 1 Megasymbol/sec equates to 1 Mbps of data.
  • 2 Mbps PHY: This is uncoded as well (modulated at 2 Megasymbol/sec), and helps achieve the higher speed (2 Mbps) than Bluetooth 4.2.
  • Coded PHY: This is also modulated at 1 Megasymbol/sec. By using a coding technique, the data can be error-corrected on the receiving end (to a given extent). This helps achieve the longer range in Bluetooth 5 – we are simply increasing the receiver sensitivity rather than changing transmit power on the transmitter side.

This following figure from the official spec better explains this:  Table for PHY types in Bluetooth 5

There are certainly trade-offs for choosing one of these PHYs over the other (there are also restrictions on where each can be used). In addition to the increased speed, the new 2M PHY also reduces power consumption since the same amount of data is transmitted in less time reducing the radio-on time. Coexistence is also improved because of the less radio-on time.

The benefit of using the LE Coded PHY is increased range with the trade-off of both higher power consumption and reduced speed (down to 125kbps or 500 kbps depending on the coding used S=2 vs. S=8).

Here are a few videos showing both the longer range and higher speed features of Bluetooth 5 by Nordic Semiconductor and Texas Instruments:

Bluetooth 5 Advertisements

Bluetooth Low Energy uses 40 different frequency channels (PHY channels), separated by 2 MHz. Three (3) of these channels are called Primary Advertisement channels, while the remaining 37 channels are used for Secondary Advertisements as well as Data channels for transfers during a connection. Advertisements are used by devices to broadcast data and info for other observer devices to discover and process. It allows the device to broadcast this information for multiple devices to discover without a connection between the observers and broadcaster.

Advertisements always start with advertisement packets sent on the 3 primary channels (or a subset of these channels). Extra information can then be offloaded to the Secondary advertisement channels to allow for more data to be broadcast. There’s also an additional mode called Periodic Advertisement that allows a scanner or observer to be synchronized with the advertisements sent continuously by the broadcaster.

The two main categories of advertisements are:

  1. Legacy Advertisements (same advertisements from the previous versions of Bluetooth Low Energy 4.0, 4.1, 4.2 and also exist in 5.0). They include the following types of PDU (Protocol Data Unit):
    1. ADV_IND
    2. ADV_DIRECT_IND
    3. ADV_NONCONN_IND
    4. ADV_SCAN_IND
  2. Extended Advertisements (introduced in Bluetooth 5). These can be utilized for sending more data than the legacy advertisements allow. They can also be used to initiate Periodic Advertisements. Extended Advertisements can only be discovered by devices that support this feature. They include the following types of PDU (Protocol Data Unit):
    1. ADV_EXT_IND
    2. AUX_ADV_IND
    3. AUX_SYNC_IND
    4. AUX_CHAIN_IND

To better understand the different advertising PDUs and which PHY is allowed for each, we refer to the spec (Volume 6, Part B, Section 2.3):

Advertisement PDU PHY Table Part 1

Advertisement PDU PHY Table Part 2

This table lays out the PHYs can be used for each of the Advertising PDU Types. You will notice that all the legacy advertisement PDUs we listed can only be sent on the original LE 1M PHY, and that the only Primary Advertisement PDU that can be sent on anything other than the 1M PHY is the ADV_EXT_IND (which is the only case where one of the new PHYs can be used on the primary advertising channels). All others are Secondary Advertising packets and can be sent on any of the three PHYs.

To better understand where each of these PDU types is used, let’s look at another table from the Bluetooth 5.0 Spec (Volume 6, Part B, Section 4.4.2, Table 4.1):

Bluetooth 5 Advertising Event Types Table

You’ll notice that the only Advertising Event that does not allow ADV_EXT_IND is the Connectable and Scannable Undirected Event. For this advertising event type, ADV_INT is the only type allowed.

A few notes about the two types of advertising channels:

Primary advertisement channels

  • Set of 3 fixed PHY channels (channels 37, 38 & 39)
  • Divided into advertising events where each event can occur on each of the 3 advertising PHY channels (or a subset)
  • Consecutive events start with the first advertising PHY channel (e.g. if advertisements start with channel 37, then each event will start with an advertisement packet sent on channel 37)
  • Events occur at regular intervals
  • Some advertising devices allow scan requests or connection requests on the same advertising PHY channel
  • The advertising device can send a scan response packet on the same advertising PHY channel within the same advertising event

Secondary advertisement channels

  • Set of 37 fixed PHY channels (same as the data channels used during a connection – channels 0-36)
  • Not part of the advertisement event, but rather part of the extended advertisement event
  • Begin at the same time as the advertisement event on the primary channel and end with the last packet on the secondary channel
  • Used to offload data that would otherwise exist on the primary channel
  • They are called “auxiliary packets”
  • An advertisement packet on the primary channel contains the PHY channel and the offset to the start time of the extended advertisement packet
  • Secondary advertisement channel can use any LE PHY (Uncoded 1M PHY, Uncoded 2M PHY, or Coded S=8 or S=2 PHY)
  • All advertising packets in the secondary channel should use the same PHY

Bluetooth 5 Extended Advertisements

Extended Advertisements are a way to advertise more (offloaded) data than what’s allowed with Legacy Advertisements. Offloading is accomplished by first advertising on the primary channel that points to an auxiliary packet on the secondary channel.

Note: Since non-Bluetooth 5 devices will not be able to discover extended advertisements, it is recommended that advertisers also use an advertising set with legacy advertising PDUs for older scanning devices to be able to discover the end device.

Advertising sets are used to send out different types of advertising events simultaneously. Each advertisement set will have different advertisement parameters such as advertising PDU type, advertising interval, and PHY.

When advertising on the LE Uncoded 1M PHY:

  • Scan requests and responses can take place on the same PHY channel as the original advertisement or be offloaded to the secondary channel.
  • In some cases when advertising on the Uncoded PHY, connection requests and responses are offloaded to the secondary channel.

When advertising on the LE Coded PHY:

  • Scan requests, scan responses, connection requests, and connection responses ARE ALWAYS offloaded to the secondary channel.

Periodic Advertisements

Another feature of Bluetooth 5 Extended Advertisements is Periodic Advertisements. These are used for broadcasting packets to devices at a set period between two unconnected devices, meaning that more than one device can listen and tune in on these periodic advertisements. They consist of advertisements sent at a fixed interval with the advertisement data changing from time to time.

The way this is accomplished is as follows (from the spec Volume 6, Part B, Section 4.4.2.3):

Periodic Advertisements in Bluetooth 5 using Extended Advertisements

As you can see from the figure above, the primary advertisement channel is used to transmit the ADV_EXT_IND PDU type which holds information (Time offset, PHY…etc) that can be used to find the AUX_ADV_IND PDU packet. That packet, in turn, contains the SyncInfo field which defines the data needed to synchronize to the periodic advertisement packets (AUX_SYNC_IND and AUX_CHAIN_IND) in a way similar to how connections are formed (channel map, hop sequence, which PHY…etc).

Therefore, a scanner can target an advertising device by first discovering the advertisement event on the primary channel, and then tuning into the appropriate secondary channel and timing based on information sent in the primary advertisement packet.

An example of Extended Advertisements (on nRF52 Series) and sniffing using Ellisys Bluetooth Tracker

We will go through an example of implementing Bluetooth 5 Extended Advertisements using the nRF52840 Preview Development Kit and show the packets as captured by the Ellisys Bluetooth Tracker sniffer.

This example will be based on the nRF52840 Preview Development Kit (PDK) by Nordic Semiconductor. If you haven’t set up your development environment for this development kit, then follow my Complete nRF52 Mac Development Tutorial. In this example, however, I’ll be using the experimental Blinky peripheral app example provided by the nRF SDK.

In order to implement Bluetooth 5 features on the nRF52840 PDK, you will need to do the following:

  1. Make sure you start with the latest SDK version (in my case, 13.1.0, available here).
  2. Update to use a SoftDevice release with version >= 5.0.0-3.alpha (available here).
  3. Update the linker file to support the new SoftDevice (since the current version of the SDK v13.1.0 does not include this SoftDevice release yet).
  4. Update the Makefile to use the new SoftDevice image when flashing the target.
  5. Modify an example program to implement Bluetooth 5 features (in our case, we are implementing the Extended Advertisement feature).
  6. Flash the target device with the SoftDevice (version >= 5.0.0-3.alpha).
  7. Flash the target device with the compiled application.
  8. You will need another device that supports Bluetooth 5 Extended Advertisements to discover and listen to the advertisements sent by the target (you can either use a Bluetooth 5 sniffer or another development Kit configured as a scanner/observer).

Let’s go over each step in detail.

Steps 1-4: Update the SDK and the SoftDevice

I recommend you make a copy of the SDK and make this change in the copy so you don’t end up breaking other applications you’ve developed that rely on older SoftDevice releases. In my case, I started with the example app labeled “experimental_ble_app_blinky” under the examples/ble_peripheral folder of the nRF5 SDK.

Download the latest SoftDevice version 5.0.0-3.alpha or greater available here. You can follow the migration document that’s included in the release to update your application to use the new SoftDevice release. Here are the steps to take:

  • Extract the downloaded file to a known location
  • Navigate to the folder labeled s140_nrf52840_5.0.0-3.alpha_API and copy and overwrite the contents of the folder named include to the folder located at components/softdevice/s140/headers
  • Create a project using the example experimental_ble_app_blinky in NetBeans (or any other IDE of choice). You can follow my tutorial on Setting up your Mac Development environment for nRF52.
  • Navigate to the folder components/softdevice/s140/hex and copy the file s140_nrf52840_5.0.0-3.alpha_softdevice.hex from the SoftDevice folder you download
  • Navigate to the experimental_ble_app_blinky/pca10056/s140/armgcc/ folder and edit the file Makefile to reflect the changes below. The file is updated to flash the device with the new SoftDevice version instead of the older one.
# Flash softdevice
flash_softdevice:
    @echo Flashing: s140_nrf52840_5.0.0-3.alpha_softdevice.hex
    nrfjprog --program $(SDK_ROOT)/components/softdevice/s140/hex/s140_nrf52840_5.0.0-3.alpha_softdevice.hex -f nrf52 --sectorerase 
    nrfjprog --reset -f nrf52
  • Update the file experimental_ble_app_blinky/pca10056/s140/armgcc/experimental_ble_app_blinky_gcc_nrf52.ld to reflect the following changes below. This change is meant to accommodate the update of the SoftDevice which takes more space in Flash and thus pushing out the application to start from the address at 0x24000.
MEMORY
{
  FLASH (rx) : ORIGIN = 0x24000, LENGTH = 0xde000
  RAM (rwx) :  ORIGIN = 0x20002178, LENGTH = 0x3de88
}

Step 5: Modify an example program to implement Bluetooth 5 features

  • Update experimental_ble_app_blinky‘s main.c to reflect the following:
/**
 * Copyright (c) 2015 - 2017, Nordic Semiconductor ASA
 * 
 * All rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 * 
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 * 
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 * 
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 * 
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 * 
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 * 
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 * 
 */
/**
 * @brief Blinky Sample Application main file.
 *
 * This file contains the source code for a sample server application using the LED Button service.
 */

#include 
#include 
//#include <sys/unistd.h>
//#include "sdk_config.h"
#include "nordic_common.h"
#include "nrf.h"
#include "app_error.h"
#include "ble.h"
#include "ble_hci.h"
#include "ble_srv_common.h"
#include "ble_advdata.h"
#include "ble_conn_params.h"
#include "softdevice_handler.h"
#include "app_timer.h"
#include "app_button.h"
#include "ble_lbs.h"
#include "boards.h"
#include "nrf_ble_gatt.h"

#define NRF_LOG_MODULE_NAME "APP"
#include "nrf_log.h"
#include "nrf_log_ctrl.h"


#define APP_FEATURE_NOT_SUPPORTED       BLE_GATT_STATUS_ATTERR_APP_BEGIN + 2    /**< Reply when unsupported features are requested. */

#define ADVERTISING_LED                 BSP_BOARD_LED_0                         /**< Is on when device is advertising. */
#define CONNECTED_LED                   BSP_BOARD_LED_1                         /**< Is on when device has connected. */
#define LEDBUTTON_LED                   BSP_BOARD_LED_2                         /**< LED to be toggled with the help of the LED Button Service. */
#define LEDBUTTON_BUTTON                BSP_BUTTON_0                            /**< Button that will trigger the notification event with the LED Button Service */

#define DEVICE_NAME                     "Nordic_Blinky"                         /**< Name of device. Will be included in the advertising data. */

#define APP_ADV_INTERVAL                64                                      /**< The advertising interval (in units of 0.625 ms; this value corresponds to 40 ms). */
#define APP_ADV_TIMEOUT_IN_SECONDS      BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED   /**< The advertising time-out (in units of seconds). When set to 0, we will never time out. */

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(100, UNIT_1_25_MS)        /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(200, UNIT_1_25_MS)        /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY                   0                                       /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)         /**< Connection supervisory time-out (4 seconds). */

#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(20000)                  /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (15 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(5000)                   /**< Time between each call to sd_ble_gap_conn_param_update after the first call (5 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                       /**< Number of attempts before giving up the connection parameter negotiation. */

#define BUTTON_DETECTION_DELAY          APP_TIMER_TICKS(50)                     /**< Delay from a GPIOTE event until a button is reported as pushed (in number of timer ticks). */

#define CONN_CFG_TAG                    BLE_CONN_CFG_TAG_DEFAULT                /**< A tag that refers to the BLE stack configuration we set with @ref sd_ble_cfg_set. Default tag is @ref BLE_CONN_CFG_TAG_DEFAULT. */

#define DEAD_BEEF                       0xDEADBEEF                              /**< Value used as error code on stack dump, can be used to identify stack location on stack unwind. */


static uint16_t       m_conn_handle = BLE_CONN_HANDLE_INVALID;                  /**< Handle of the current connection. */
static nrf_ble_gatt_t m_gatt;                                                   /**< GATT module instance. */
static ble_lbs_t      m_lbs;                                                    /**< LED Button Service instance. */ /**@brief Function for assert macro callback. * * @details This function will be called in case of an assert in the SoftDevice. * * @warning This handler is an example only and does not fit a final product. You need to analyze * how your product is supposed to react in case of Assert. * @warning On assert from the SoftDevice, the system can only recover on reset. * * @param[in] line_num Line number of the failing ASSERT call. * @param[in] p_file_name File name of the failing ASSERT call. */ void assert_nrf_callback(uint16_t line_num, const uint8_t * p_file_name) { app_error_handler(DEAD_BEEF, line_num, p_file_name); } /**@brief Function for the LEDs initialization. * * @details Initializes all LEDs used by the application. */ static void leds_init(void) { bsp_board_leds_init(); } /**@brief Function for the Timer initialization. * * @details Initializes the timer module. */ static void timers_init(void) { // Initialize timer module, making it use the scheduler ret_code_t err_code = app_timer_init(); APP_ERROR_CHECK(err_code); } /**@brief Function for the GAP initialization. * * @details This function sets up all the necessary GAP (Generic Access Profile) parameters of the * device including the device name, appearance, and the preferred connection parameters. */ static void gap_params_init(void) { ret_code_t err_code; ble_gap_conn_params_t gap_conn_params; ble_gap_conn_sec_mode_t sec_mode; BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode); err_code = sd_ble_gap_device_name_set(&sec_mode, (const uint8_t *)DEVICE_NAME, strlen(DEVICE_NAME)); APP_ERROR_CHECK(err_code); memset(&gap_conn_params, 0, sizeof(gap_conn_params)); gap_conn_params.min_conn_interval = MIN_CONN_INTERVAL; gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL; gap_conn_params.slave_latency = SLAVE_LATENCY; gap_conn_params.conn_sup_timeout = CONN_SUP_TIMEOUT; err_code = sd_ble_gap_ppcp_set(&gap_conn_params); APP_ERROR_CHECK(err_code); } /**@brief Function for initializing the GATT module. */ static void gatt_init(void) { ret_code_t err_code = nrf_ble_gatt_init(&m_gatt, NULL); APP_ERROR_CHECK(err_code); } /**@brief Function for initializing the Advertising functionality. * * @details Encodes the required advertising data and passes it to the stack. * Also builds a structure to be passed to the stack when starting advertising. */ static void advertising_init(void) { ret_code_t err_code; ble_advdata_t advdata; ble_uuid_t adv_uuids[] = {{LBS_UUID_SERVICE, m_lbs.uuid_type}}; // Build and set advertising data memset(&advdata, 0, sizeof(advdata)); advdata.name_type = BLE_ADVDATA_FULL_NAME; advdata.include_appearance = false; advdata.uuids_complete.uuid_cnt = sizeof(adv_uuids) / sizeof(adv_uuids[0]); advdata.uuids_complete.p_uuids = adv_uuids; advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE; err_code = ble_advdata_set(&advdata, NULL); APP_ERROR_CHECK(err_code); } static void advertising_start(void) { ble_gap_adv_params_t adv_params = { .properties = { .connectable = 1, }, .p_peer_addr = NULL, .fp = BLE_GAP_ADV_FP_ANY, .interval = APP_ADV_INTERVAL, .duration = 0, .primary_phy = BLE_GAP_PHY_1MBPS, .secondary_phy = BLE_GAP_PHY_2MBPS, .max_ext_adv = 0, .secondary_max_skip = 0, .advertising_sid = 0, .scan_req_notification = 0, .adv_fragmentation_len = 0, }; ret_code_t err_code = sd_ble_gap_adv_start(BLE_GAP_ADV_SET_HANDLE_DEFAULT, &adv_params, CONN_CFG_TAG); APP_ERROR_CHECK(err_code); NRF_LOG_INFO("Starting advertising.\r\n"); bsp_board_led_on(ADVERTISING_LED); } /**@brief Function for handling write events to the LED characteristic. * * @param[in] p_lbs Instance of LED Button Service to which the write applies. * @param[in] led_state Written/desired state of the LED. */ static void led_write_handler(uint16_t conn_handle, ble_lbs_t * p_lbs, uint8_t led_state) { if (led_state) { bsp_board_led_on(LEDBUTTON_LED); NRF_LOG_INFO("Received LED ON!\r\n"); } else { bsp_board_led_off(LEDBUTTON_LED); NRF_LOG_INFO("Received LED OFF!\r\n"); } } /**@brief Function for initializing services that will be used by the application. */ static void services_init(void) { ret_code_t err_code; ble_lbs_init_t init; init.led_write_handler = led_write_handler; err_code = ble_lbs_init(&m_lbs, &init); APP_ERROR_CHECK(err_code); } /**@brief Function for handling the Connection Parameters Module. * * @details This function will be called for all events in the Connection Parameters Module that * are passed to the application. * * @note All this function does is to disconnect. This could have been done by simply * setting the disconnect_on_fail config parameter, but instead we use the event * handler mechanism to demonstrate its use. * * @param[in] p_evt Event received from the Connection Parameters Module. */ static void on_conn_params_evt(ble_conn_params_evt_t * p_evt) { ret_code_t err_code; if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_FAILED)
    {
        err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);
        APP_ERROR_CHECK(err_code);
    }
}


/**@brief Function for handling a Connection Parameters error.
 *
 * @param[in] nrf_error  Error code containing information about what went wrong.
 */
static void conn_params_error_handler(uint32_t nrf_error)
{
    APP_ERROR_HANDLER(nrf_error);
}


/**@brief Function for initializing the Connection Parameters module.
 */
static void conn_params_init(void)
{
    ret_code_t             err_code;
    ble_conn_params_init_t cp_init;

    memset(&cp_init, 0, sizeof(cp_init));

    cp_init.p_conn_params                  = NULL;
    cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
    cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
    cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
    cp_init.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID;
    cp_init.disconnect_on_fail             = false;
    cp_init.evt_handler                    = on_conn_params_evt;
    cp_init.error_handler                  = conn_params_error_handler;

    err_code = ble_conn_params_init(&cp_init);
    APP_ERROR_CHECK(err_code);
}

/**@brief Function for handling the Application's BLE stack events.
 *
 * @param[in] p_ble_evt  Bluetooth stack event.
 */
static void on_ble_evt(ble_evt_t * p_ble_evt)
{
    ret_code_t err_code;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            NRF_LOG_INFO("Connected\r\n");
            bsp_board_led_on(CONNECTED_LED);
            bsp_board_led_off(ADVERTISING_LED);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;

            err_code = app_button_enable();
            APP_ERROR_CHECK(err_code);
            break; // BLE_GAP_EVT_CONNECTED

        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected\r\n");
            bsp_board_led_off(CONNECTED_LED);
            m_conn_handle = BLE_CONN_HANDLE_INVALID;
            err_code = app_button_disable();
            APP_ERROR_CHECK(err_code);
            advertising_start();
            break; // BLE_GAP_EVT_DISCONNECTED

        case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
            // Pairing not supported
            err_code = sd_ble_gap_sec_params_reply(m_conn_handle,
                                                   BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP,
                                                   NULL,
                                                   NULL);
            APP_ERROR_CHECK(err_code);
            break; // BLE_GAP_EVT_SEC_PARAMS_REQUEST

        case BLE_GATTS_EVT_SYS_ATTR_MISSING:
            // No system attributes have been stored.
            err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0, 0);
            APP_ERROR_CHECK(err_code);
            break; // BLE_GATTS_EVT_SYS_ATTR_MISSING

        case BLE_GATTC_EVT_TIMEOUT:
            // Disconnect on GATT Client timeout event.
            NRF_LOG_DEBUG("GATT Client Timeout.\r\n");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break; // BLE_GATTC_EVT_TIMEOUT

        case BLE_GATTS_EVT_TIMEOUT:
            // Disconnect on GATT Server timeout event.
            NRF_LOG_DEBUG("GATT Server Timeout.\r\n");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break; // BLE_GATTS_EVT_TIMEOUT

        case BLE_EVT_USER_MEM_REQUEST:
            err_code = sd_ble_user_mem_reply(p_ble_evt->evt.gattc_evt.conn_handle, NULL);
            APP_ERROR_CHECK(err_code);
            break; // BLE_EVT_USER_MEM_REQUEST

        case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
        {
            ble_gatts_evt_rw_authorize_request_t  req;
            ble_gatts_rw_authorize_reply_params_t auth_reply;

            req = p_ble_evt->evt.gatts_evt.params.authorize_request;

            if (req.type != BLE_GATTS_AUTHORIZE_TYPE_INVALID)
            {
                if ((req.request.write.op == BLE_GATTS_OP_PREP_WRITE_REQ)     ||
                    (req.request.write.op == BLE_GATTS_OP_EXEC_WRITE_REQ_NOW) ||
                    (req.request.write.op == BLE_GATTS_OP_EXEC_WRITE_REQ_CANCEL))
                {
                    if (req.type == BLE_GATTS_AUTHORIZE_TYPE_WRITE)
                    {
                        auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_WRITE;
                    }
                    else
                    {
                        auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
                    }
                    auth_reply.params.write.gatt_status = APP_FEATURE_NOT_SUPPORTED;
                    err_code = sd_ble_gatts_rw_authorize_reply(p_ble_evt->evt.gatts_evt.conn_handle,
                                                               &auth_reply);
                    APP_ERROR_CHECK(err_code);
                }
            }
        } break; // BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST

        default:
            // No implementation needed.
            break;
    }
}


/**@brief Function for dispatching a BLE stack event to all modules with a BLE stack event handler.
 *
 * @details This function is called from the scheduler in the main loop after a BLE stack
 *          event has been received.
 *
 * @param[in] p_ble_evt  Bluetooth stack event.
 */
static void ble_evt_dispatch(ble_evt_t * p_ble_evt)
{
    on_ble_evt(p_ble_evt);
    ble_conn_params_on_ble_evt(p_ble_evt);
    ble_lbs_on_ble_evt(&m_lbs, p_ble_evt);
    nrf_ble_gatt_on_ble_evt(&m_gatt, p_ble_evt);
}


/**@brief Function for initializing the BLE stack.
 *
 * @details Initializes the SoftDevice and the BLE event interrupt.
 */
static void ble_stack_init(void)
{
    ret_code_t err_code;

    nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC;

    // Initialize the SoftDevice handler module.
    SOFTDEVICE_HANDLER_INIT(&clock_lf_cfg, NULL);

    // Fetch the start address of the application RAM.
    uint32_t ram_start = 0;
    err_code = softdevice_app_ram_start_get(&ram_start);
    APP_ERROR_CHECK(err_code);

    // Overwrite some of the default configurations for the BLE stack.
    ble_cfg_t ble_cfg;

    memset(&ble_cfg, 0, sizeof(ble_cfg));
    ble_cfg.gap_cfg.role_count_cfg.periph_role_count  = BLE_GAP_ROLE_COUNT_PERIPH_DEFAULT;
    ble_cfg.gap_cfg.adv_cfg.use_adv_ext = 1;
    ble_cfg.gap_cfg.role_count_cfg.central_role_count = 0;
    ble_cfg.gap_cfg.role_count_cfg.central_sec_count  = 0;
    err_code = sd_ble_cfg_set(BLE_GAP_CFG_ROLE_COUNT, &ble_cfg, ram_start);
    APP_ERROR_CHECK(err_code);
    
    // Enable BLE stack.
    err_code = softdevice_enable(&ram_start);
    APP_ERROR_CHECK(err_code);

    // Subscribe for BLE events.
    err_code = softdevice_ble_evt_handler_set(ble_evt_dispatch);
    APP_ERROR_CHECK(err_code);
}


/**@brief Function for handling events from the button handler module.
 *
 * @param[in] pin_no        The pin that the event applies to.
 * @param[in] button_action The button action (press/release).
 */
static void button_event_handler(uint8_t pin_no, uint8_t button_action)
{
    ret_code_t err_code;

    switch (pin_no)
    {
        case LEDBUTTON_BUTTON:
            NRF_LOG_INFO("Send button state change.\r\n");
            err_code = ble_lbs_on_button_change(m_conn_handle, &m_lbs, button_action);
            if (err_code != NRF_SUCCESS &&
                err_code != BLE_ERROR_INVALID_CONN_HANDLE &&
                err_code != NRF_ERROR_INVALID_STATE &&
                err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING)
            {
                APP_ERROR_CHECK(err_code);
            }
            break;

        default:
            APP_ERROR_HANDLER(pin_no);
            break;
    }
}


/**@brief Function for initializing the button handler module.
 */
static void buttons_init(void)
{
    ret_code_t err_code;

    //The array must be static because a pointer to it will be saved in the button handler module.
    static app_button_cfg_t buttons[] =
    {
        {LEDBUTTON_BUTTON, false, BUTTON_PULL, button_event_handler}
    };

    err_code = app_button_init(buttons, sizeof(buttons) / sizeof(buttons[0]),
                               BUTTON_DETECTION_DELAY);
    APP_ERROR_CHECK(err_code);
}


static void log_init(void)
{
    ret_code_t err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);
}


/**@brief Function for the Power Manager.
 */
static void power_manage(void)
{
    ret_code_t err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}


/**@brief Function for application main entry.
 */
int main(void)
{
    // Initialize.
    leds_init();
    timers_init();
    log_init();
    buttons_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();

    // Start execution.
    NRF_LOG_INFO("Blinky example started.\r\n");
    advertising_start();

    // Enter main loop.
    for (;;)
    {
        if (NRF_LOG_PROCESS() == false)
        {
            power_manage();
        }
    }
}


/**
 * @}
 */

This example showcases the following advertisement configuration:

  • Enables Extended Advertisements via:
    ble_cfg.gap_cfg.adv_cfg.use_adv_ext = 1;
  • Configures the Primary Advertisement to use the LE 1M PHY:
        .primary_phy   = BLE_GAP_PHY_1MBPS,
  • Configures the Secondary Advertisement to use the LE 2M PHY:
        .secondary_phy = BLE_GAP_PHY_2MBPS,
  • You can modify the Primary PHY to use the LE 1M PHY instead (per the spec and Table that’s shown above – you cannot use LE 2M PHY)
  • You can modify the Secondary PHY to use any of the three PHYs (LE 1M PHY, LE 2M PHY, or LE Coded PHY)
  • The advertisement data will be broadcast and sent over the extended advertisement packets. In this case, it will include the Name and the LBS_UUID_SERVICE (LED Button Service Server).

Steps 6 & 7: Flashing the SoftDevice and Application firmware

Follow my tutorial on Setting up your Mac Development environment for nRF52.

Step 8: Use a sniffer or another Bluetooth 5 device to capture advertisements

Here’s a video tutorial showing the different advertisement settings and how they appear when captured by the Ellisys Tracker.

From the Ellisys Tracker sniffer capture:

Extended Advertisement Data captured by Ellisys Tracker

Unfortunately, the nRF5x SDK and SoftDevice (as of July 2017) does not yet support advertisement packets to contain data larger than 31 bytes, so the name here is cut off, even though we specified it as a Complete Local Name instead of a Shortened Local Name (the API shortened it for us).

How and when can you utilize Bluetooth 5 Advertisements?

No doubt that Beacon applications will benefit the most from extended advertisements. However, it will take time before you can practically utilize this feature since it will depend on the scanning devices (smartphones, tablets, PCs) supporting Bluetooth 5 Extended Advertisements.

Beacons can now broadcast more data and allow for a better user experience. Connectable devices can also utilize this to send more data and allow connections on the secondary advertising channels (which can help avoid interference and noise from other devices broadcasting on the primary channels).

The use of Periodic Advertisements can also help in making the broadcasting device more consistently discovered and monitored, with the possibility of the broadcast data being updated to reflect certain attributes and aspects of the broadcasting device (e.g. in the case where a scanning device is always present in the proximity of a broadcasting device, now this scanning device can more consistently “follow” the advertiser and monitor its updates more frequently).

Conclusion & Summary

Extended Advertisements (including periodic advertisements) is just one of the exciting and promising features of the new Bluetooth 5. We will go into more detail on the other two features of Bluetooth 5: longer range, and higher speed in the upcoming posts.

To summarize what we covered today:

  • Overview of Bluetooth 5 and its major improvements
  • How Bluetooth 5 achieves higher speed and longer range
  • General overview of Bluetooth advertising
  • Types of Bluetooth 5 advertising channels
  • In-depth look into Extended Advertisements and Periodic Advertisements
  • Example code for sending extended advertisements using the nRF52840 Preview Development Kit
  • Video showing the capture of these advertisements by a commercial Bluetooth 5 sniffer (Ellisys Bluetooth Tracker)
  •  How and when to utilize Extended Advertisements
If you would like to download the code used in this post, please enter your email address in the form below. You’ll get a .zip containing all the source code, and I will also send you a FREE 9-page Report on the Essential Bluetooth Developer Tools. In addition, you will receive exclusive content, tips, and tricks that I don’t post to the blog!