Based on ultra-wideband (UWB), it can quickly realize real-time positioning with an accuracy of 10 cm ...

Radio positioning systems have become a standard feature of almost all types of mobile devices and related applications. Among the many radio positioning methods, the real-time positioning system (RTLS) based on ultra-wideband (UWB) radio frequency communication plays a central role, ensuring that positioning information can also be obtained when more familiar technologies such as GPS cannot provide coverage.
With the growing demand for higher precision RTLS, developers find themselves trapped in complex high-precision methods such as two-way ranging or time difference of arrival (TDOA) positioning.
Decawave's integrated modules and software provide developers with a simpler RTLS solution that can easily provide more accurate positioning results.
This article will review RTLS applications and algorithms, including bidirectional ranging and TDOA, and discuss related implementation tradeoffs for different RTLS methods. After that, this article will introduce a Decawave UWB transceiver, focusing on the specific requirements for design using this device. Finally, this article will discuss the Decawave software architecture and supporting firmware development, and explain the specific methods of developing user applications on the Decawave platform.
The role of RTLS systems Precision RTLS has become an effective method for determining or tracking the location of people and moving assets in office buildings, warehouses, manufacturing plants, and assembly lines. According to this method, a mobile object (tag) uses the standard format and UWB technology specified in the low-rate wireless personal area network (LR-WPAN) standard IEEE 802.15.4-2011 to exchange information with fixed-position devices (location points). By determining the distance between the tag and multiple anchor points, related applications can determine the position of the tag relative to these known anchor points, and then determine the absolute position of the tag.
RTLS methods RTLS applications use several methods to determine distance. In the simplest method, the application or tag can use the received signal strength indicator (RSSI) parameters provided by most transceivers to assess the tag's position relative to the transmit location. Because there are many factors that may affect the link budget, this method can only provide a rough location estimate at most. In contrast, many emerging RTLS-based applications require absolute positions to a few centimeters.
High-precision RTLS uses a time-of-flight method, which is almost unaffected by large changes in RF signal strength. According to this method, the position of the tag can be determined by measuring the time required for the RF signal to pass from the tag to multiple positioning points. Using known propagation delays when RF signals propagate through the air, RTLS applications can convert time of flight into distance.
For example, if the flight time between the tag and all three anchor points is exactly the same, then logically, this will only happen if the tag is equidistant from these anchor points. Since the application knows the exact location of each anchor point, it can determine the absolute position of the label.
However, to measure the propagation time of the tag transmitter, the positioning point receiver needs to use the same time base as the tag to correctly evaluate the time information embedded in the tag message. If the time base of the anchor point lags or leads the time base of the label, the calculated distance will be closer or farther than the actual distance, respectively.
An RTLS method takes a simple approach to this problem, which is to synchronize the time between the tag transmitter and the anchor receiver to ensure that each anchor receives the same time base as the tag. Even in the best case, achieving time synchronization is challenging, and in RTLS applications where wireless tags move around, this is simply not practical.
Another method, TDOA, only synchronizes the anchor points, thereby eliminating the difficulties associated with mobile tag synchronization. To determine the location, the RTLS application uses the difference in arrival time of the tag signal measured across multiple anchor points. For example, consider the previous example where the three anchor points (A1, A2, and A3) are equally spaced around a label. After the tag moves, if the TDOA of each anchor point is found to be 0, 1 nanosecond (ns) and 0, it means that the tag has moved about 30 centimeters (cm) in a straight line away from the anchor point A2 (assuming radio frequency The speed of propagation is the speed of light). TDOA's positioning point synchronization requirements are much less difficult than trying to synchronize positioning points and tags. But even so, the accuracy of this method still depends on highly accurate synchronization. Even a one-nanosecond synchronization difference can cause a difference of a few centimeters in position measurement.
Two-way ranging The two-way ranging RTLS method does not require precise time synchronization at all, but introduces transmission capability requirements in the label. This method avoids the uncertainty caused by different time bases by supporting the exchange of timing information between tags and positioning points. The tags and anchors do not need to synchronize their time bases, but use a short two-way information transmission protocol to accurately determine the flight time and accurately calculate the tag position.
According to this method, the tag emits a short identification signal to "illuminate the identity" to the surrounding anchor points. Each anchor point that receives the initial identification information of the tag then cooperates with the tag for a brief two-way data exchange to determine the flight time without considering the time base difference between the anchor point and the tag.
Decawave defines this process from the perspective of the discovery phase and the ranging phase in its bidirectional ranging RTLS protocol (Figure 1). During discovery, the tag periodically transmits a short identification signal (ie blink signal) and waits for a response from the location point. After the tags and anchor points are identified with each other, the paired tags and anchor points use a short two-way information exchange, which contains the information needed for ranging.

Figure 1: In Decawave's two-way ranging protocol, tags and anchors exchange a series of messages to complete discovery and provide ranging information. (Source: Decawave)
For developers, the challenges of implementing these precisely designed message exchange protocols and their underlying UWB radio subsystem can be daunting. But with the Decawave DWM1001 module, developers can quickly add precise RTLS functionality to their applications with little extra work.
Integrated RTLS module Decawave DWM1001 module can fully implement RTLS, integrating Decawave DW1000 UWB transceiver with a Nordic Semiconductor NRF52832 wireless MCU and a STMicroelectronics LIS2DH12 3-axis motion sensor. Although the DW1000 provides the RF signal transmission function in compliance with the IEEE 802.15.4-2011 standard, the NRF52832 MCU still implements its embedded firmware for RTLS applications. The LIS2DH12 sensor plays an important role in power management.
In any complex RF application, RF design often brings some of the most difficult challenges, especially in mobile applications that require extremely small packages and extremely low power consumption. The DWM1001 module solves these problems by taking full advantage of the integrated RF design provided by the DW1000 transceiver (Figure 2).

Figure 2: The Decawave DW1000 transceiver integrates the radio signal path and digital control logic to provide a complete IEEE802.15.4-2011 compliant system. (Source: Decawave)
DW1000 provides a complete UWB transceiver with integrated RF front-end, capable of supporting six IEEE802.15.4-2011 channels from 3.5 GHz to 6.5 GHz, with standard bit rates of 110 Kb / s, 850 Kb / s, and 6.81 Mb / s. The device's integrated digital control subsystem is used to manage transceivers, and supports bidirectional ranging and TDOA RTLS systems, with a positioning accuracy of up to 10 cm. With integrated one-time programmable memory (OTP), developers can store data for calibration and error correction, while the device ’s configurable uninterruptible memory (AON) is retained during the device ’s low-power states described below Configuration Data.
During operation, the device sends and receives standard IEEE802.15.4-2011 frames, which contain the synchronization header (SHR), physical layer header (PHR), and up to 127 words that constitute the overall physical layer service data unit (PSDU) Section data. In addition to standard frames, the device also supports a proprietary frame format, which provides up to 1023 data bytes for applications that need to send larger data payloads but do not require compliance with the IEEE802.15.4-2011 standard.
For standard-compliant applications, developers can choose from a series of operating modes to meet specific bidirectional ranging and TDOA operation use cases. These operating modes pre-combine data rate, payload size and pre-configured preamble length. For example, a mode suitable for remote applications combines a lower data rate and a longer preamble that facilitates discovery and ranging in interference or weaker signals. Conversely, modes with higher data rates and shorter preambles support short-range applications. Other modes support the characteristics of such long-range and short-range applications with data payloads of different sizes.
Minimize power consumption In practice, developers will choose an operating mode with the shortest frame size possible to minimize overall power consumption and allow the device to quickly recover to a low-power state. DW1000 provides multiple low-power modes. During the inactive period, the device can be placed in standby mode, which consumes only 19 milliamperes (mA). If it is necessary to remain inactive for a long time, developers can put the device into a low-power sleep mode. At this time, the current consumption is only about 1 microampere (μA), while the current consumption of deep sleep mode is not more than 100 nanoamperes ( nA) (typical value 50 nA).
But like any RF design, the power consumption during transceiver operation will increase significantly. For example, to transmit frames that comply with the IEEE802.15.4-2011 standard, longer frame components such as sync headers and data packets consume most of the power consumption (Figure 3).

Figure 3: Decawave DW1000's RTLS frame transmission will cause the power consumption of each frame component to increase significantly, which prompts designers to start looking for the working mode with the shortest useful synchronization header and data payload. (Source: Decawave)
The power consumption associated with receiver operation is even greater, which poses even more difficult challenges for power-constrained designs (Figure 4). Developers can set the DW1000 to resume one of its low-power states after sending or receiving operations. Even so, the nature of standard protocols and frames makes few options for reducing power consumption during frame operations.

Figure 4: Due to the long duration of the preamble search phase, the power consumption required to receive frames is even higher than the transmission operation. (Source: Decawave)
DW1000 provides a unique energy-saving function to reduce the power consumption of the preamble RX stage. Developers can program a special preamble sniffing mode for the device instead of keeping the receiver working. In this case, the DW1000 periodically powers on the receiver, searches for the preamble, and returns to the standby state if the preamble is not found (Figure 5).

Figure 5: Developers can use the DW1000's sniffing function to reduce power consumption related to receiver operation, allowing the device to alternate between standby mode and receiver active mode. (Source: Decawave)
Functions such as preamble sniffing are especially important for battery-powered tags. Developers can apply multiple energy-saving methods during RTLS operation. One method uses different known delays in the two-way ranging protocol shown in Figure 1.
For example, in the discovery phase, the initial response of the positioning point to the label "blink signal" ranging will occur after a certain delay. Developers can estimate this delay based on the frame rate and other parameters, measure their actual value in their anchor point design, and even build a specific response delay time in their anchor point design. Then, the developer can safely keep the tag receiver turned off within the expected delay time, turn on the receiver to search for the response, and turn off the receiver again if the ranging initialization response does not arrive within a reasonable window.
Similarly, developers can take measures to limit the time that the radio needs to be kept on during the ranging process. For example, developers can preload all required data in the device and use direct memory access to speed up data transfer between the DW1000 and the host memory.
Although these low-level optimizations can increase incremental energy savings, developers can further improve energy savings by dynamically changing the location update rate. After the label stops moving, there is no need to continue the high-energy discovery and ranging phase. The tag can safely enter a low-power sleep state and wake up after it starts moving to continue to update at the nominal rate.
By integrating the LIS2DH12 motion sensor, the DWM1001 module supports dynamic rate adjustment and supports two motion-related operating modes: low power consumption and response mode. Developers can configure the module. When LIS2DH12 senses that the module is at rest, the DW1000 transceiver operates in low power mode. When LIS2DH12 detects movement, the transceiver can revert to response mode, then the DW1000 transceiver will return to the normal update rate.
Developers can further optimize their RTLS applications to control the update rate based on the object's speed and acceleration. For example, a slow-moving label may only require a low update frequency to maintain the necessary positioning accuracy. As the tag speed increases, the application can respond by increasing the location update rate.
RTLS development In addition to supporting RTLS features such as dynamic update rates, this module also provides basic RTLS development advantages. For example, the DW1000 transceiver has a variety of specific interface requirements for power supply decoupling, antenna network matching, reference oscillators, and other components (Figure 6). Similarly, NRF52832 wireless MCU and LIS2DH12 motion sensor also have their own interface design requirements.

Figure 6: The Decawave DW1000 transceiver uses strict interface requirements to ensure reliable power, RF, and timing signals. (Source: Decawave)
Although advanced devices like this have a highly simplified design, designers who want to achieve the highest performance with the lowest power consumption may still face serious challenges if they want to optimize integration. The DWM1001 module will reduce the integration requirements by at least several power, ground, and digital interface connections (Figure 7).

Figure 7: The Decawave DWM1001 module simplifies RTLS development by providing a fully integrated design that integrates a DW1000 transceiver with a wireless MCU and motion sensor. (Source: Decawave)
Software model Similarly, the module leverages its pre-installed Decawave positioning and network stack (PANS) library firmware to greatly simplify software development and integration. The PANS library is built on the MCU's on-chip Bluetooth low energy (BLE) stack, and includes an open source eCos real-time operating system (RTOS), a network layer, and support for BLE services, RTLS management services, and bidirectional ranging (TWR) positioning engines Several application layers (Figure 8).

Figure 8: The Decawave Location and Network Stack (PANS) library combines the Bluetooth stack, RTOS, network layer, and application service layer to provide a feature-rich RTLS application platform. (Source: Decawave)
When building a firmware application running on the MCU of the DWM1001, developers access the PANS library through a comprehensive application programming interface (API), which provides the corresponding entry points for each PANS module to configure and control the module. The PANS API contains multiple API sets for individual modules, including developer C code, serial interface libraries (CPI and UART), and BLE libraries (Figure 9).
The application directly connects to these four high-level APIs, and then converts these calls into a common API call to the PANS library through a common API parser to achieve access to the PANS library. In this role, the common layer provides a common interface to the PANS library.

Figure 9: Decawave provides access to the PANS library through a wide range of APIs, and each API provides simple access to the underlying threaded execution model. (Source: Decawave)
Threaded architecture In this architecture, the DWM1001 firmware software uses a threaded model, which basically provides a separate thread for each module and library in the stack. The respective threads of the four modules at the top of the stack pass the parsing request to the generic API parser thread, which validates each request and calls the PANS library to generate the corresponding response. The generic API thread then uses the callback function provided when the call was initiated to return the result to the calling module at the top of the stack.
Although this multi-tier system may seem very complex, it is relatively simple from the developer's programming model. Using API calls with independent thread callbacks helps optimize resource utilization and overall application performance.
At the same time, the underlying complexity is also masked by a series of APIs that translate advanced application-oriented calls into optimized threaded operations that interact with the DWM1001 hardware. The DWM1001 programming model further simplifies developer interaction with this system. Developers use user-specific application threads built into the system without interacting with multiple threads and APIs.
As shown in Listing 1, the developer uses a simple API call (dwm_thread_create) to call the user application thread registered with the user application thread function (app_thread_entry).
Copy / * Create thread * /
rv = dwm_thread_create (THREAD_APP_PRIO, app_thread_entry, (void *) NULL, "app", THREAD_APP_STACK_SIZE, & hndl);
APP_ERR_CHECK (rv);

/ * Start the thread * /
dwm_thread_resume (hndl);
Listing 1: Using the Decawave threading model, developers only need a pair of simple API calls to register and start their user application threads. (Code source: Decawave)
Decawave provides user application thread and callback sample code. The sample code is bundled in an Oracle Virtual Box virtual machine image, which contains a complete tool chain, library, and simple sample application. This software package is designed to work with the Decawave DWM1001-DEV development board connected to a Windows PC and provides a framework for creating custom RTLS application software.
The sample code included in this package demonstrates key user thread function design patterns (Listing 2). In this example, the user thread function (app_thread_entry) sets application-specific configuration parameters (such as update rate) and registers the callback using the API function dwm_evt_cb_register and its callback function name (on_dwm_evt). After registering the callback, the example thread enters the main loop-in this case, a series of delayed function calls to reduce resource utilization.
Copy void app_thread_entry (uint32_t data)
{
.
.
.
/ * Update rate set to 1 second, staTIonary update rate set to 5 seconds * /
APP_ERR_CHECK (dwm_upd_rate_set (10, 50));

/ * Register event callback * /
dwm_evt_cb_register (on_dwm_evt, 0);

.
.
.

while (1) {
/ * Thread loop * /
dwm_thread_delay (100);
}
}
Listing 2: In this fragment of the Decawave firmware development kit, the sample code shows the basic design pattern used to register callbacks and execute the main loop in user application thread routines. (Code source: Decawave)
The sample callback function (on_dwm_evt) demonstrates the basic event handler that is called when an event occurs (Listing 3). In this code example, the only valid event is the availability of new location information (DWM_EVT_NEW_LOC_DATA). In the handler for this event, the code demonstrates the simple call set required to retrieve the position data generated by available anchors. After completing its event processing tasks, the callback goes directly to sleep.
Copy / **
* Event callback
*
* @param [in] p_evt Pointer to event structure
* @param [in] p_data Pointer to user data
* /
void on_dwm_evt (dwm_evt_t * p_evt, void * p_data)
{
int i;

switch (p_evt-> header.id) {
/ * New locaTIon data * /
case DWM_EVT_NEW_LOC_DATA:
/ * Process the data * /

printf ("T:% lu", dwm_sysTIme_us_get ());
if (p_evt-> data.loc.p_pos == 0) {
/ * LocaTIon engine is disabled * /
} else {
printf ("POS: [% ld,% ld,% ld,% u]", p_evt-> data.loc.p_pos-> x,
p_evt-> data.loc.p_pos-> y, p_evt-> data.loc.p_pos-> z,
p_evt-> data.loc.p_pos-> qf);
}

for (i = 0; i <p_evt-> data.loc.anchors.dist.cnt; ++ i) {
printf ("DIST% d:", i);

printf ("0x% 04X", (unsigned int) (p_evt-> data.loc.anchors.dist.addr [i] & 0xffff));
if (i <p_evt-> data.loc.anchors.an_pos.cnt) {
printf ("[% ld,% ld,% ld]",
p_evt-> data.loc.anchors.an_pos.pos [i] .x,
p_evt-> data.loc.anchors.an_pos.pos [i] .y,
p_evt-> data.loc.anchors.an_pos.pos [i] .z);
}

printf ("= [% lu,% u]", p_evt-> data.loc.anchors.dist.dist [i],
p_evt-> data.loc.anchors.dist.qf [i]);
}
printf ("");
break;

default:
break;
}

/ * Indicate the application has finished the tasks and can now * /
dwm_sleep ();
}
Listing 3: The callback demonstrated by this Decawave sample application fragment provides a basic event handler for accessing new location data. (Code source: Decawave)
For example, in a complete Internet of Things (IoT) RTLS application, tags and anchor points communicate through routing anchor points that are connected to a gateway system connected to the Internet. Decawave is about to launch its second version of the firmware package, which will provide gateway support through Linux-based software packages and will use familiar IoT information transfer protocols, including HTTP, WebSockets, MQTT, and AMQP.
Summary RTLS plays an increasingly important role in a wide range of applications. Although RTLS methods are based on relatively simple principles, the implementation of these methods requires complex RF / analog design, system design, and software development to ensure the highest accuracy with minimum power consumption.
The Decawave DWM1001 module provides a complete RTLS system, which combines Decawave's integrated DW1000 UWB transceiver with a wireless MCU and motion sensor. Using this module and supporting software package, developers can quickly implement a high-precision battery-powered RTLS system.