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?


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

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

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.

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

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

  • Update experimental_ble_app_blinky‘s main.c to reflect the following:

This example showcases the following advertisement configuration:

  • Enables Extended Advertisements via:

  • Configures the Primary Advertisement to use the LE 1M PHY:

  • Configures the Secondary Advertisement to use the LE 2M PHY:

  • 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!


  1. Avatar Mohan on March 15, 2020 at

    Hi Mohammad,
    Is it possible for BT classic or BLE host driver to do the following for all kinds of packets?
    1. Read signal strength of received packets
    2. Update/modify transmit power of a packet.

    Ex: 1. Host can set the inquiry transmit power level used to transmit the ID packets using HCI_Write_Inquiry_Transmit_Power_Level command.

    2. If host sent HCI_Write_Inquiry_Mode (Inquiry_Mode: with RSSI) command before inquiry, controller will send RSSI value for each discovered device in HCI_Inquiry_Result_with_RSSI event or HCI_Extended_Inquiry_Result event

    Similarly, is it possible to know RSSI of received packets for all types of packets such as inquiry response, page response, acknowledgements etc?
    is it possible to modify the transmit power of page packets, data packets, advertisement packets etc?

  2. Avatar Oscar Sanchez on February 7, 2019 at

    Hello Mohammad,
    great tutorial. Do you have an example for extended advertising yet??

    • Mohammad Afaneh Mohammad Afaneh on February 7, 2019 at

      Thanks, Oscar. Not yet, but it is on my list of upcoming posts. Stay tuned!

  3. Avatar Edward Lu on November 7, 2018 at


    Thank you very much for these tutorials, they are super helpful!

    I just have a question; I am trying to get some of the other types of extended advertising (like periodic advertising) working on the nrf52840, but I have not found anything in the SoftDevice v6.1.0 API or in any other online tutorials detailing how to actually implement this.

    Is it just not supported by the SoftDevice yet?

    Thank you so much for these tutorials again.

  4. Avatar Mike on May 8, 2018 at

    Great tutorial! Do you know how to enable AUX_CHAIN_IND packets? Is it just a matter of increasing the amount of advertising data and the Nordic SDK will add that data to the AUX_CHAIN_IND packets in the extended advertising event?

    Also, jus wondering if you know whether the Nordic SDK also implements the central side of scanning for extended advertising? I’ve looked through the latest SDK release notes but don’t seem to see that specified, though maybe I just missed it.

    • Mohammad Afaneh Mohammad Afaneh on May 9, 2018 at

      Hi Mike,

      I will look into it and get back to you. At the time I wrote the post, the nRF SDK had limited support for Advertising Extensions in general.

    • Mohammad Afaneh Mohammad Afaneh on May 18, 2018 at


      Sorry for the late response. I looked into the chained advertising packets and apparently they are not supported by the current nRF5 SDK + SoftDevice. I’m sure they’ll be adding it in a future update though.

      Have you figured out the Central part for scanning for extended asvertisements? I’ll be look at that soon and will update the comment with any new info I find out.

  5. Avatar arun on April 18, 2018 at

    brilliant tutorials. .

  6. Avatar Nadine on October 25, 2017 at

    Hello Mohammed,

    Thank you for your answer. I want to use bluez to fuzz. I found that function from bluez code that sends attribute protocol request over the air::

    guint g_attrib_send(GAttrib *attrib, guint id, const guint8 *pdu, guint16 len,
    GAttribResultFunc func, gpointer user_data,
    GDestroyNotify notify)
    struct command *c;
    GQueue *queue;
    uint8_t opcode;

    if (attrib->stale)
    return 0;

    c = g_try_new0(struct command, 1);
    if (c == NULL)
    return 0;

    opcode = pdu[0];

    c->opcode = opcode;
    c->expected = opcode2expected(opcode);
    c->pdu = g_malloc(len);

    fuzz(pdu, len);

    memcpy(c->pdu, pdu, len);
    c->len = len;
    c->func = func;
    c->user_data = user_data;
    c->notify = notify;

    if (is_response(opcode))
    queue = attrib->responses;
    queue = attrib->requests;

    I want to fuzz the attribute protocol before it gets send but I don’t know how. Any help will be appreciate

  7. Avatar Nadine on September 3, 2017 at

    Hello Mohammed,

    I am working on the BLE security testing with the BTLC1000 Board and want to fuzz the BLe protocol stack by sending malicious L2CAP Packets for example. Have you already done something like that?


    • Mohammad Afaneh Mohammad Afaneh on September 6, 2017 at

      Hi Nadine,

      I haven’t done any security testing and fuzzing with BLE. What tools are you looking at using for this? Are you looking to do this on the BTLC1000 itself or from a peer device? I know that the Ubertooth One is pretty popular among security professionals for testing and penetration testing.

Leave a Comment