Last Updated on April 11, 2022 by Mohammad Afaneh
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 
- 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):
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:
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:
- nRF52840-DK Range Testing With BLE, ZigBee and Thread Protocols at 0, 4 and 8dBm Transmit Power Settings
- Bluetooth: Tried and Tested in the Harshest Environments
- InPlay SwiftRadio SoC Long Range Demo
- How Motsai Uses Long-Range Wireless for Industrial IoT and Agriculture Solutions
- Bluetooth® 5, Refined for the IoT
- TI: Long Range with CC2640R2F
- Nordic Semiconductor – Bluetooth 5 Long Range Test with nRF52840
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.
- There are two options for configuration when using Coded PHY:
- S=2, where 2 symbols represent each data bit –> 500 Kbps data rate
- 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:
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):
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.
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:
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
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.
- Set up to use Coded PHY as the configured PHY for both Primary and Secondary Advertising.
- Set up to use Extended Advertising, which is necessary for Coded PHY mode.
- Set up Primary Advertising to use the type ADV_EXT_IND (Extended Connectable Nonscannable Undirected advertising).
- Set the LE General Discoverable Mode flag to 1.
- Configure the Central to accept and discover Extended Advertisement packets (since Advertising on the Coded PHY requires the use of Extended Advertisements).
- When starting the scan/discovery process, make sure the Central is configured to scan on the Coded PHY.
- Make sure that when a Peripheral is discovered, 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 and supported Android phones
The Bluetooth Developer Academy
… take your BLE knowledge to the next level
If you’re looking to get access to full video courses covering more topics, then check out the Bluetooth Developer Academy.
As part of all the courses within the Academy, you’ll also be able to download the full source code to use as a reference or use within your own application.
By joining the Bluetooth Developer Academy, you will get access to a growing library of video courses (one course released every single month).
For a full list of courses included, check out the Courses Library here:
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 Academy also features access to a private community of Bluetooth experts, developers, and innovators. You’ll get to connect and interact with me and other experts in the Bluetooth space, learn from others’ experiences and knowledge, and share yours as well.
So, what are you waiting for?? Join today!
In this post, we went over the steps you will need to achieve ranges of over 1 kilometer for communication between two BLE devices.
- 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
I’m Mohammad, a Bluetooth Developer and the Founder of Novel Bits. I have a Masters in Electrical and Computer Engineering and have been developing Bluetooth Low Energy applications since 2014. I enjoy reading non-fiction books and love cycling and playing table tennis.