Introduction

Bluetooth Low Energy was designed to provide considerably reduced power consumption and cost while maintaining communication ranges similar to Bluetooth Classic. 

However, that is no longer the case. With Bluetooth Version 5.0, a new “long-range” mode was introduced. You can now achieve ranges of over 1 kilometer using Bluetooth Low Energy! Long-range mode is not only useful for extending the range of a Bluetooth connection or discovery of advertisements, but it also helps in achieving more robust communication in noisy RF environments and in areas with many obstacles. Examples of applications include:

  • Remote control and remote identification system for drones [1]
  • Monitoring sensors deployed on large-area farms
  • Making connections more robust in areas with many obstacles such as in industrial environments.

Now, you may be interested in learning more about long-range mode and implementing it into your own application, but you don’t want to go through the 3000 pages of the Bluetooth Specification document in order to figure out the steps and configurations necessary for this!

Well, you’ve come to the right place.

In this post, I’ll guide you through the necessary steps for configuring long-range mode in your Bluetooth Low Energy application. We’ll go over all the background technical details of long-range mode, the most important concepts, then cover the necessary steps for configuring each of the Central and Peripheral devices to communicate using long-range mode.

We’ll go over:

  • What is Long-range mode (Coded PHY)?
  • Technical Details of Coded PHY
  • Details of Coded PHY packets
  • Restrictions applied when using Coded PHY
  • Implementation of Coded PHY for BLE Central and BLE Peripheral devices

Once you finish reading this blog post, you will understand the overall concepts and the steps required to implement ranges of over 1KM on your BLE Peripheral and BLE Central devices.

Long-Range Mode in Bluetooth Version 5.0

Long-range mode, also known with the technical term Coded PHY, was introduced in Bluetooth 5.0 and allows Bluetooth connectivity to extend beyond 30-100 feet to ranges beyond even 1 kilometer! In order to support this new mode, some hardware changes were required. Specifically, the receiver end sensitivity level required was increased for supporting each of the two modes of Coded PHY (S=2 and S=8):

Source: Bluetooth version 5.1 Core Specification document

The important thing to keep in mind is that when choosing a Bluetooth LE chipset/module for both the Central and Peripheral devices, you want to make sure that they support Coded PHY (not just Bluetooth 5.0 or later, since support for long-range mode is optional per the Bluetooth 5.0 specification).

What is Long-range mode (Coded PHY)? 

A new PHY was introduced in Bluetooth Version 5.0 called Coded PHY. The raw data is still transmitted at the rate of 1Mbps. But the data includes redundancy in the user data which brings down the rate to either 500 Kbps or 125 Kbps, depending on the configuration used.

The data rates referenced above include packet overhead, headers, and other data, so the effective user-data rate is ultimately lower than the raw data rate. Redundancy allows the receiver to recover the original data from the errors that occur in the transmission using Forward Error Correction (FEC) algorithms rather than increasing transmit power. The higher the redundancy, the higher the probability of recovering data. This is why the PHY rate is usually referred to in units of Megasymbols per second.

Here are the different PHYs and rates available in Bluetooth version 5.0 and beyond:

  • Original 1M PHY: 1 Megasymbols/second –> where each data bit is represented by 1 symbol –> 1 Mbps
  • Coded PHY: 1 Megasymbols/second –> where each data bit is represented by 2 or 8 symbols –> 500 Kbps, or 125 Kbps
  • 2M PHY: 2 Megasymbols/second –> where each data bit is represented by 1 symbol –> 2 Mbps

And here’s a table summarizing the differences:

Source: Bluetooth version 5.1 Core Specification document

In this post, we will focus on the Coded PHY and how it can be used to achieve ranges of up to 1.5 kilometers line-of-sight!

Before we move on, I’ll leave you with a few links and videos created by companies showcasing the capabilities of Coded PHY:

Technical Details

Before we get into how we can design our Bluetooth LE application to utilize Coded PHY, let’s go over some important technical details about this mode.

Coding

  • There are two options for configuration when using Coded PHY:
    1. S=2, where 2 symbols represent each data bit –> 500 Kbps data rate
    2. S=8, where 8 symbols represent each data bit –> 125 Kbps data rate
  • The term Coding refers to adding redundancy to the data being transmitted. It utilizes Forward Error Correction (FEC) to allow the receiver to detect errors and recover the original data without the need to retransmit the data.
  • Coding consists of two processes performed on the data before it is transmitted:
    • Data is coded by the FEC convolutional encoder.
    • Output data from the previous step is spread by a pattern mapper.
  • There is a significant impact of the Coded PHY choice on the radio-on time, power consumption and duty cycle for scheduling and coexistence over the air. Due to this, careful consideration needs to be exercised when choosing the Coded PHY and the specific coding scheme (S=2 or S=8). S=8 represents the worst-case scenario causing an almost 8 times the packet size compared to the LE 1M PHY.

Coded PHY Packet Format

Coded PHY BLE packets have a different format than the standard 1M or 2M PHYs. Let’s take a look at the packet format:

https://lh3.googleusercontent.com/6344TgsPzoRodMmX5hTsoAIsoEtPSiNzFjb8X2LIKgQJVTRzg8c2gQZ0GR4juIDJ4dRLoftL2aNNV3w53MgbLnyonLOu_JMPemGGX2wP-ckBRHk2Lt9t8IzgWBYqCytdPauywlMr
Source: Bluetooth version 5.1 Core Specification document

Important Notes About the Format:

  • The Preamble is never coded, which allows the packet to be detected in any mode (Coded PHY, 1M PHY, or 2M PHY) before determining which mode was used for the remaining packet’s data.
  • FEC block 1 is always coded with S=8,
  • FEC block 2 is coded with S=2 or S=8 (depending on the configuration).
  • The CI (Coding Indicator) is used to indicate which coding scheme is used in FEC block 2 (S=2 or S=8).
  • The timing values shown indicate how long it takes to transmit the specific field within the packet.

Here’s a table that shows the size and duration of each of the fields within the packet (taken from the Bluetooth 5.1 spec):

https://lh6.googleusercontent.com/YjAxwONQPAV5v_x_wb2fcxyuMKyuKsaioeJ09EN4N9UJR7V4Fp27THv0UzT8vglFVNpnXs2Vdn1WHOjw-qShgqxrzD1YIeM4YvtzmAtHDrp33dcqmDvcNL1RrJZBYciDF_fFD7TT
Source: Bluetooth version 5.1 Core Specification document

The table shows the differences between using S=2 and S=8 for coding. Notice how the choice impacts the radio-on time, which in turn impacts power consumption.

Advertising State

For two Bluetooth LE devices to successfully connect over long-range mode, one device (the Peripheral) will need to advertise on the Coded PHY while the other (the Central) will need to be configured to look for advertisements on the Coded PHY.

In this mode, Extended Advertisements are used. The way this works is by advertising on the Primary Advertisement channels, where these Primary Channel Advertisements point to Secondary Channel Advertisements that hold the advertising information needed to establish a connection.

Understanding the appropriate Advertising types used in the Coded PHY mode is crucial for developing BLE applications that can operate using long-range mode. Without the correct setup, a BLE Central device will not be able to discover and/or connect to a BLE Peripheral over the Coded PHY.

Let’s look at the different Advertising types used in Coded PHY:

https://lh3.googleusercontent.com/uYwDT_i1QDg1dVQeacwihQftmxWhn9F39aoOmILyG14YLNuGFwZC80tzVvA7QAUb0FMG2WQrtBvq-FYaM4HngfQ4IkJ9qO5ZoOfFfkM4oJewP1r3jGzDmoADiMAvSZKBYu9hDRun
Source: Bluetooth version 5.1 Core Specification document

Notice that the only Primary Advertising type allowed in Coded PHY is of type ADV_EXT_IND. The rest of the Advertising types allowed in Coded PHY are Secondary Advertising packets (AUX_SCAN_REQ, AUX_CONNECT_REQ, AUX_ADV_IND, AUX_SCAN_RSP, AUX_SYNC_IND, AUX_CHAIN_IND, and AUX_CONNECT_RSP).

This means that connection requests on Coded PHY do not occur on the Primary Advertisement channels, rather they occur on the Secondary Advertisement channels. The PDU types used in this case are the AUX_CONNECT_REQ and AUX_CONNECT_RSP types.

PHY Update Procedure

Bluetooth provides the flexibility to switch to using different PHYs during a connection. Different PHYs can be used in each direction as well between the two connected devices. For example, this procedure can be used to switch to using the Coded PHY after two devices have connected using the standard 1M PHY allowing the two devices to increase the range at which they maintain the connection.

The PHY Update Procedure can be initiated by either the master or the slave after the connection is established. 

When the Master initiates the connection:

  • Master sends LL_PHY_REQ PDU
  • Slave responds with LL_PHY_RSP PDU
  • Master then responds to this with LL_PHY_IND PDU
https://lh4.googleusercontent.com/CyrjFu1kOnhbaU1qEKvvx5MQf-7_z93sZOoRvH_0sbWExaRWcG7GsR2X4SOo9lcnrU4B7RDdk91GIlOOghQ6UGFeXDRNbarN7XkfdEDeCg1fMZxql-z4n0bAj1qRt8iWERFwRt0a

When the Slave initiates the connection:

  • Slave sends LL_PHY_REQ PDU
  • Master then responds to this with LL_PHY_IND PDU

The PDU includes both the preferred transmit and receive PHYs.

Implementation Steps for Coded PHY

Next, we will go through the steps necessary for implementing Coded PHY on a Bluetooth LE Central and a Bluetooth LE Peripheral. We will also go over the advertisement types that allow a connection to be established. Finally, we will go over the details of each step and focus on the general implementation steps according to the official Bluetooth specification.

Peripheral Configuration

  1. Set up to use Coded PHY as the configured PHY for both Primary and Secondary Advertising.
  2. Set up to use Extended Advertising, which is necessary for Coded PHY mode.
  3. Set up Primary Advertising to use the type ADV_EXT_IND (Extended Connectable Nonscannable Undirected advertising).
  4. Set the LE General Discoverable Mode flag to 1.

Central Configuration

  1. Configure the Central to accept and discover Extended Advertisement packets (since Advertising on the Coded PHY requires the use of Extended Advertisements).
  2. When starting the scan/discovery process, make sure the Central is configured to scan on the Coded PHY.
  3. Make sure that when a Peripheral is discovered, that the connection parameters are set up to use the Coded PHY when a connection is initiated. This makes sure that when the devices connect, they keep using the Coded PHY instead of switching to another PHY (using the PHY Update Request).

With these steps, your BLE application should be able to advertise, discover, connect, and transfer data all using the Coded PHY.

Next Steps: Implement Coded PHY for BLE Central and BLE Peripheral Devices on the Nordic nRF52840 chipset

Naturally, the next step would be to walk through the detailed steps for implementation and testing of your Coded PHY for BLE Central and BLE Peripheral Devices on the Nordic nRF52840 chipset. If you’re interested in learning more about how to set up ranges of over 1 kilometer for your Bluetooth LE Peripheral and Bluetooth LE Central Devices on the nRF52840 chipset, check out the all-new Bluetooth Developer Academy.

By joining the Bluetooth Developer Academy, you will get access to a growing library of courses and tutorials.

Here’s what one Academy member has to say:

If you’re developing a BLE project, you need two things, a good BLE sniffer and the Bluetooth Developer Academy. I am very happy to be part of this community and look forward to what comes next.

– Christopher Gates, Principal System Security Architect – Velentium

The current courses include:

  • The Basics of Bluetooth Low Energy
  • Analysis of BLE events using a BLE sniffer
  • Long-range mode (Coded PHY) using Bluetooth 5.0
  • Developing nRF52 applications using Visual Studio Code
  • Over the Air Device Firmware Update (OTA DFU) – nRF52 use case
  • Getting Started with Zephyr (including adding custom GATT Services and Characteristics)
  • The Developer’s Guide to what’s new in Bluetooth 5.2
  • SweynTooth: A Summary for BLE Developers
  • Introduction to BLE Security
  • Getting Started with BlueZ development
  • Introduction to BLE Development for iOS
  • …and more courses added each month!

For a full list of courses included, check out the Courses Library here:

Bluetooth Developer Academy Courses Library

The Academy also features a thriving community of Bluetooth experts, developers, and innovators. You’ll get to connect and interact with other experts in the Bluetooth space, learn from others’ experience and knowledge, and share yours.

Also included in the Academy is access to private support from me personally.

In the community, you will find:

  • Discussions around new features such as long-range mode (Bluetooth 5.0) and direction-finding (Bluetooth 5.1).
  • Discussions around the capabilities of different BLE sniffers.
  • Comparisons of BLE support and restrictions in iOS and Android.
  • Various technical questions and answers to these questions.
  • Listing of Bluetooth-related job openings.
  • And many more discussions!

Learn More About the Bluetooth Developer Academy

Summary

In this post, we went over the steps you will need to achieve ranges of over 1 kilometer for communication between two BLE devices.

We covered:

  • The technical details of Coded PHY including the two different configurations available (S=2, and S=8)
  • The details of Coded PHY packets
  • The restrictions applied when using Coded PHY
  • The different procedures related to Coded PHY
  • The steps required to implement Coded PHY for BLE Central and BLE Peripheral devices

8 Comments

  1. Avatar simone on February 3, 2020 at

    Great! very good study!

    In your opinion, in the future will be possible to use mesh stardard with coded phy?

    • Mohammad Afaneh Mohammad Afaneh on February 3, 2020 at

      Unfortunately, we won’t know until something is released publicly. But, I believe it is one of the most asked questions, and I imagine the mesh Working Group is working on supporting it in future releases. You could also ping the Bluetooth mesh Working Group Chair, Szymon Slupik, directly on Twitter (https://twitter.com/hdwrx) and ask. Won’t hurt to ask!

  2. Avatar mtailor on January 10, 2020 at

    Nicely explained.
    Which I had read this before reading the spec multiples times to understand all this 🙂

    Something to think about?
    How does the baseband decide that an incoming packet is 1MPHY or LE_CODED?
    I think it needs to make that decision withing 1 bit or byte time

    • Mohammad Afaneh Mohammad Afaneh on January 13, 2020 at

      Thanks, Mahendra.

      In terms of your question. From my understanding, you have to configure it to look for either 1M or LE Coded PHY, but not both at the same time. Or am I missing something?

  3. Avatar Amit on January 7, 2020 at

    Would it be possible to use this technique to develop a low node count mesh with large distances between the nodes? The real trick to it that I can see is that a single node can’t always be a central or peripheral, since the nodes would all need to be able to discover each other

    • Mohammad Afaneh Mohammad Afaneh on January 7, 2020 at

      Hi Amit,

      Unfortunately, the current Bluetooth mesh specification does not allow the use of Coded PHY (long-range mode). However, there are discussions about this on Nordic’s DevZone (if you’re using the Nordic platform), and it seems they have a way to at least minimally support it.

      https://devzone.nordicsemi.com/f/nordic-q-a/29813/change-phy-in-mesh

  4. Avatar Marinus on January 6, 2020 at

    Excellent. Keep it up.

    • Mohammad Afaneh Mohammad Afaneh on January 7, 2020 at

      Thanks, Marinus.

Leave a Comment