Editor’s Note: Part 1 of this two-part series describes the capabilities of Bluetooth 5.1 direction finding, an addition to Bluetooth Low Energy firmware that enables designers to develop Angle of Arrival (AoA) and Angle of Departure (AoD)-based location applications such as asset tracking and indoor positioning systems (IPSs). This second and final part explores suitable development platforms and SoCs upon which Bluetooth 5.1 direction finding applications can be built and configured.
The latest version of the Bluetooth Core Specification, version 5.1, has made it easier for developers to implement asset tracking and indoor positioning systems (IPSs). Specifically, the specification adds a continuous tone extension (CTE) to a Bluetooth packet to enable a receiver to extract “IQ” data (the in-phase and quadrature-phase information required to calculate the position of a transceiver) from the RF signal without the disruptive effects of modulation. In addition, it is now much simpler for the developer to configure the protocol to perform IQ sampling by using the Host Controller Interface (HCI) to configure the controller for such sampling.
However, extracting IQ data is still not simple, requiring the use of a well-designed antenna array allied to a wireless microprocessor. Even when IQ data has been made available, it must still be processed to take into account multipath reception, signal polarization, and propagation delays, noise, and jitter before the location of the transmitter can be calculated.
This article describes what’s needed for a practical solution and then introduces suitable development platforms and modules from Dialog Semiconductor, Silicon Labs, and Nordic Semiconductor that can be used to build Bluetooth 5.1 direction finding applications. Finally, the article shows how to get started prototyping, testing, and verifying designs on these platforms.
Bluetooth 5.1 packet architecture
Bluetooth 5.1 packets include a CTE comprising digital “1s” to ensure that for this part of the signal the antenna receives a constant frequency (instead of the modulated frequency normally used to convey Bluetooth data). In addition, this data string is not whitened (i.e. decorrelated). A suitably configured Bluetooth Low Energy (LE) radio receiving a packet incorporating a CTE signal proceeds by taking IQ samples during the CTE period. A single IQ sample consists of the signal’s amplitude and phase angle represented as Cartesian coordinates (Figure 1).
Figure 1: Direction finding applications commence with the receiving Bluetooth LE device taking phase angle and amplitude IQ samples during the CTE portion of a Bluetooth packet for each antenna in an array. These samples are represented as (I,Q) Cartesian coordinates. (Image source: Bluetooth SIG)
The Bluetooth Core Specification v5.1 details changes to the Bluetooth LE controller that enable AoA and AoD techniques to use either connected (“paired”) or connectionless communication. However, AoA will typically be used for connected applications such as asset tracking, while AoD will be used with connectionless applications such as IPS.
Connected direction finding uses standard Bluetooth 5.1 packets with the CTE appended to the end. In contrast, connectionless direction finding uses a CTE added to Bluetooth periodic advertising packets (Figure 2).
Figure 2: Bluetooth 5.1 packet structure showing location and duration of CTE. Connected applications append the CTE to standard packets while connectionless applications use an advertising packet. (Image source: Bluetooth SIG)
In both connected and connectionless scenarios, the developer must perform some set-up and configuration steps to initiate CTEs at the transmitter and IQ sampling at the receiver. The choice of AoA or AoD-based applications determines the exact process.
Building a direction finding solution
AoA is suited to applications like asset tracking where the transmitter is a mobile item such as a simple, low-cost tag, while the receivers (or locators) are fixed reference points. The advantage of this implementation is that the tag only needs to transmit the Bluetooth 5.1 protocol packets using a single antenna (rather than an array) and isn’t required to run the computationally intensive algorithms that ultimately determine transmitter location (see Part 1).
While the design of a tag in an asset tracking system follows relatively straightforward radio frequency (RF) design principles, the tag does require a Bluetooth 5.1 transceiver so that packets can be configured to include CTEs. When selecting a transceiver, it is important to note that the CTE can’t be sent over a Bluetooth LE Coded PHY (the radio used to implement Bluetooth 5 technology’s long-range feature); rather the PHY must be of the uncoded type.
Some commercial Bluetooth 5.1 products are available, including for example, Dialog Semiconductor’s DA14691 Bluetooth 5 LE SoC for location service applications. The chip is powered by an Arm® Cortex®-M33 microprocessor and includes 512 Kbytes of random access memory (RAM). Dialog has made a Bluetooth 5.1 stack available for the DA14691. Silicon Labs has also released a Bluetooth 5.1 stack for its EFR32BG13 Bluetooth LE SoC; the chip uses an Arm Cortex-M4 microprocessor with 64 Kbytes of RAM and 512 Kbytes of flash. In addition, Nordic Semiconductor has taken a further step by launching a new “Direction Finding” hardware and software solution in the form of the nRF52811. This Bluetooth LE SoC is Bluetooth 5.1 compatible and integrates an Arm Cortex-M4 microprocessor teamed with the multiprotocol radio from Nordic’s high-end nRF52840 device. The chip includes 192 Kbytes of flash and 24 Kbytes of RAM.
These devices are suitable for transmitters and receivers in a Bluetooth direction finding application. Each supports CTE transmission and can capture IQ samples with the aid of profile level information specifying the antenna layout of the transmitter. Theoretically, these devices can also perform the complex calculations needed to work out the angle of incidence of the incoming radio signal, and from that the position of the transceiver. However, while the Arm Cortex-M33 and M4 processors used by these SoCs are relatively powerful, if they are engaged in simultaneous supervision of the wireless protocol while running complex direction finding algorithms, the performance of the application could be sluggish.
Depending on the performance and latency demanded in the application, a developer could consider a companion processor—with access to additional RAM and flash—specifically for the application software. Nordic’s nRF52811, for example, is designed to interface with a companion processor via Inter-Integrated Circuit (I2C) and Serial Peripheral Interface (SPI) interfaces.
A further design challenge is that to keep costs down, Bluetooth LE SoCs typically don’t have either the multiple antenna ports or the switching capability needed to systematically work through each antenna in the array. Consequently, an RF switch is needed to connect the Bluetooth LE SoC’s single antenna port to the multiple antennas of the array and to switch between antennas to gather IQ data from each (Figure 3).
Figure 3: In an AoA direction finding asset tracking system the tag uses a single antenna and conventional Bluetooth LE SoC to send Bluetooth 5.1 packets with CTE. The main computation occurs on the multi-antenna locator side of the system where the signal data gathered by the locator is fed to a location engine that runs the direction finding algorithms. (Image source: Bluetooth SIG)
The receiver (or locator) requires an antenna array to detect—via the IQ data—the phase difference of the signal due to the difference in distance from each antenna in the array to the single transmitting antenna. It is the difference between the phase angle at each antenna that determines the AoA or AoD.
The antenna design typically falls into one of three types: the uniform linear array (ULA), uniform rectangular array (URA), and uniform circular array (UCA). Antenna array design requires lots of experience, and it is often more efficient for the developer to leave it to a third-party specialist to both configure the optimum array and offer a bill of materials (BoM) for its construction in volume, as discussed in Part 1.
The requirement for the antenna array, companion processors, additional memory, and antenna management increases the complexity at the locator end of the asset tracking solution as well as its cost and power consumption. On the plus side, locators will typically remain in fixed locations and so could be mains-powered. For most solutions, relatively few of the devices will be needed in comparison to the number of tags.
AoD implementations are a little more complex. In this scenario, it is the transmitter that incorporates the antenna array. The receiver performs IQ sampling, taking measurements from its single antenna and using details of the design of the antenna array in the remote transmitter to attribute the measurements to particular antennae.
In the AoD implementation, fixed locator beacons require a Bluetooth 5.1 transceiver, an RF switch, and multiple antennas to transmit the beacon signal, but not the additional processor and memory needed in AoA implementations because no signal analysis is performed on this side of the link. However, the mobile receiver, while only requiring a single antenna, does need the hardware and software to perform the direction finding calculations (Figure 4). In IPS applications, for example, the receiver is likely to be a Bluetooth 5.1-compatible smartphone, which has ample processor and memory resources to complete the task.
Figure 4: In an AoD direction finding IPS system the fixed beacons use antenna arrays to send Bluetooth 5.1 packets with CTE. The main computation occurs on the mobile device, such as a consumer’s smartphone. (Image source: Bluetooth SIG)
Prototyping with Bluetooth 5.1
Dialog Semiconductor, Silicon Labs, and Nordic Semiconductor have currently focused their solutions on the part of AoA and AoD applications that transmit the CTE, receive such packets, and perform the IQ sampling. The developer is then left to decide which resources (i.e. hardware and location engine firmware) will be needed to perform the actual direction finding calculations. This, however, is likely to change in the near future as vendors release enhanced direction finding solutions.
For example, each of the companies offers development tools that support the prototyping of a tag in an AoA asset tracking application. The development process generally follows that for a conventional low-power wireless device. For example, a development kit comprising a factory supplied, fully-functional transceiver based on the Bluetooth 5.1 target device and peripherals is connected to a PC or Mac hosting a suitable integrated development environment (IDE) and the chip supplier’s software tools to enable application development.
In Dialog’s case, the company advises basing Bluetooth 5.1 development on the DA14695-00HQDEVKT-P-ND dev kit. The kit includes a motherboard, a daughterboard based on the DA14695 Bluetooth 5.1 SoC, and cables for connecting to a PC. The DK also supports Arduino and MikroElektronika mikroBUS shields, and power measurements.
Silicon Labs offers the SLWSTK6006A Wireless Gecko Starter Kit. This DK comes with no less than six EFR32BG21 Bluetooth 5.1 SoC-based daughter boards, enabling prototyping of an asset tracking system with multiple tags. The DK is designed for use with the company’s Simplicity Studio, which supports the Flex SDK application and configuration software development tools.
Nordic’s offering is the nRF52840-DK evaluation board based on the company’s nRF52840 SoC, which is fully compatible with the nRF52811 Bluetooth 5.1 SoC. Application development and system configuration are performed via the company’s nRF5 SDK, a software development tool supported by a number of popular IDEs. (For more information on Bluetooth Low Energy application development, see the Digi-Key article, “Bluetooth 4.1, 4.2 and 5 Compatible Bluetooth Low Energy SoCs and Tools Meet IoT Challenges”.)
Bluetooth 5.1 doesn’t transmit packets with CTE or perform IQ sampling by default; the developer must configure the system to add these features using the vendor’s development tools. The tools enable access to the Host Controller Interface (HCI), which is then used by the host to configure the controller for CTE generation and IQ sampling.
For connectionless scenarios (the type typically used by AoD), the host performs the following controller initialization steps (Figure 5):
- Configure extended advertising
- Configure periodic advertising
- Configure CTE transmission
- Enable CTE advertising
- Enable periodic advertising
- Enable extended advertising
- Set the advertising data
Figure 5: Controller initialization steps performed by the host for connectionless scenarios (typically used by AoD). (Image source: Bluetooth SIG)
Scanning devices designed to receive CTE data and take IQ samples transmitted by the advertiser must be configured as follows:
- Configure extended scanning
- Start extended scanning
- Synchronize with received periodic advertising sync packets
- Enable connectionless IQ sampling
With connected scenarios, such as those typically used by AoA, either the master or the slave device requests the other device to send packets with CTEs. Requests are made by sending a Link Layer (LL) CTE request packet which contains a number of parameters that configure the CTE creation. If the remote device does not support CTE, it will advise the local device of that fact, and the local device will not send further CTE requests using the current connection.
The detailed process is as follows. The requesting device proceeds by:
- Configuring CTE receive parameters in the controller
- Enabling CTE requests in the controller
- Receiving and processing IQ reports
- Disabling CTE request transmission when no longer required
The responding device proceeds by:
- Configuring CTE transmit parameters in the controller
- Enabling CTE responses in the controller
- Receiving and responding to LL CTE requests from the other device
In the Bluetooth 5.1 specification the HCI features a new command — “LE Read Antenna Information” — that allows the host to obtain information about the antennae supported by its controller. The procedure for obtaining information about the antenna array in a remote device is yet to be defined.
When performing IQ sampling with an antenna array, each of the samples captured must be attributed to a specific antenna, and the sampling must be completed in a systematic manner. Using a pattern specified in HCI configuration commands and following strict timing rules aids this systematic approach. How these rules are applied and which device is subject to which rules, depends on whether the application is using AoA or AoD and whether the device is transmitting or receiving. For example, a transmitting device with a single antenna sends continuous packets with CTE. However, IQ sampling is always performed by the receiving device, irrespective of the number of antennae it employs.
The time allocated to CTE processing is divided into an initial 4 microsecond (μs) guard period, an 8 μs reference period, and then a sequence of either switch slots, sample slots, or pairs of switch and sample slots (Figure 6).
Figure 6: This example illustrates the switching and sampling for 1 µs and 2 µs timing for an AoA application. The transmitting device with a single antenna transmits packets with CTE continuously while IQ sampling is performed by the receiving device according to a switching and sampling sequence. (Image source: Bluetooth SIG)
During the reference period, no antenna switching occurs and eight IQ samples are acquired. The host may be able to use the reference samples to estimate the frequency of the signal and infer the wavelength, improving the precision of the angle calculations.
Enhancements made to the Bluetooth Core Specification in version 5.1 generate the raw data needed for direction finding using CTE and IQ sampling. The specification uses proven engineering techniques for determining signal direction and standardizes the interfaces, configurations, and interactions. A further advantage is that accurate direction finding is now interoperable across all chip vendors offering Bluetooth solutions.
Chipmakers have been quick to offer hardware solutions, software, DKs, and SDKs that allow developers to quickly become familiar with configuring systems that take advantage of Bluetooth direction finding. Commercial asset tracking and IPS applications still demand a high level of development expertise, particularly in the design of antenna arrays and location engine firmware, but future Bluetooth direction finding profiles promise to further ease this challenge.
1: Bluetooth Direction Finding: A Technical Overview, Martin Wooley, Bluetooth SIG, March 2019.