Rapidly Implement a Real-Time Location System Accurate to 10 cm

Contributed By Digi-Key's North American Editors

Radiolocation systems have become a ubiquitous feature in nearly every type of mobile device and associated application. Among radiolocation approaches, real-time location systems (RTLS) based on ultra-wideband (UWB) RF communications play a central role in ensuring available location information when more familiar technologies such as GPS are unable to provide coverage.

With growing demand for more accurate RTLS, developers find themselves caught in the complexity of high-precision methods such as two-way ranging or time difference of arrival (TDOA) localization.

An integrated module and software from Decawave provides developers with a simpler RTLS solution able to deliver more accurate localization results with minimal effort.

This article reviews RTLS applications and algorithms, including two-way ranging and TDOA, and discusses implementation tradeoffs associated within different RTLS methods. The article then introduces a Decawave UWB transceiver, emphasizing specific requirements for designing with it. The article concludes with a discussion of the Decawave software architecture and accompanying firmware development, illustrating specific techniques for developing user applications on the Decawave platform.

The role of RTLS systems

Precision RTLSs have emerged as an effective method for determining the location or tracking of people or mobile assets in office complexes, warehouses, manufacturing plants, and assembly lines. In this approach, a mobile object (tag) exchanges information with fixed-position devices (anchors) using standard formats and UWB technologies specified in IEEE 802.15.4-2011 for low-rate wireless personal area networks (LR-WPANs). By determining the distance between the tag and several anchors, applications can determine the tag’s relative position to those known anchors – and thus, the tag’s absolute position.

RTLS methods

RTLS applications use a variety of techniques for determining distance. In the simplest approach, the application or tag can use the received signal strength indicator (RSSI) parameter available with most transceivers to assess the tag’s location relative to the transmitting anchors. Due to the many factors that can affect link budget, this approach can at best provide only a broad estimate of position. In contrast, many emerging RTLS-based applications require determination of absolute location within a few centimeters.

High-precision RTLS uses time-of-flight methods that are largely immune to significant changes in variation in RF signal strength. In this approach, the location of a tag can be determined by measuring the time required for an RF signal to pass from the tag to several anchors. Using the known propagation delay of RF signals through air, RTLS applications can translate time-of-flight to distance.

For example, if the time-of-flight between a tag and each of three anchors is found to be exactly the same. This situation can only reasonably occur if the tag is equidistant from those anchors. Since the application knows the exact location of each anchor, it can determine the absolute location of the tag.

To measure the propagation time from the tag transmitter, however, the anchor receiver needs to use the same time base as the tag to correctly assess the time information embedded in the tag’s message. If an anchor’s time base lags or leads a tag’s time base, the calculated distance will be respectively shorter or longer than the actual distance.

One RTLS method takes a straightforward approach for solving this problem by time synchronizing the tag transmitter and anchor receivers, ensuring that each anchor will receive the message with the same time base as the tag. Implementing time synchronization can be challenging at best, and simply impractical in RTLS applications where wireless tags are moving about.

Another method, TDOA, synchronizes only the anchors, eliminating the difficultly associated with synchronizing mobile tags. To determine location, the RTLS application uses the differences between arrival times of a tag signal measured across multiple anchors. For example, consider the earlier example of three anchors (A1, A2, and A3) arranged equidistantly about a tag. After the tag moves, if TDOA for each anchor is found to be 0, 1 nanosecond (ns), 0, respectively, it means the tag has moved in a direct line away from anchor A2 for about 30 centimeters (cm) (assuming RF propagation at the speed of light). TDOA’s requirement for anchor synchronization is a significantly easier problem than attempting to synchronize anchors and tags. Even so, the accuracy of this approach depends on very precise synchronization. Even a nanosecond difference in synchronization can translate to centimeters difference in location measurement.

Two-way ranging

Two-way ranging RTLS methods entirely eliminate the need for precise time synchronization, but do introduce a requirement for transmission capability in the tag. This approach avoids the uncertainty of different time bases by enabling the tag and anchors to exchange timing information with each other. Instead of synchronizing their time bases, the tag and anchors use a short bi-directional messaging protocol that allows precise determination of time-of-flight and accurate calculation of tag location.

With this approach, a tag transmits a brief identification signal to announce itself to surrounding anchors. Each anchor that receives the tag’s initial identification message then engages the tag in a short bi-directional data exchange used to determine time-of-flight despite differences in time bases across the anchors and the tag itself.

In its two-ranging RTLS protocol, Decawave defines this process in terms of a discovery phase and ranging phase (Figure 1). During discovery, a tag periodically transmits a brief identification signal, or blink, and waits for a response from an anchor. After the tag and anchor recognize each other, the paired tag and anchor use a brief two-way exchange of messages containing information needed to calculate range.

Diagram of Decawave’s two-way ranging protocol

Figure 1: In Decawave’s two-way ranging protocol, tags and anchors trade a series of messages to complete discovery and provide ranging information. (Image source: Decawave)

For developers, the challenges associated with implementing these precisely choreographed message exchange protocols and their underlying UWB radio subsystems can be daunting. Using the Decawave DWM1001 module, however, developers can quickly add precision RTLS capabilities to their applications with little additional effort.

Integrated RTLS module

The Decawave DWM1001 module provides a complete RTLS implementation, integrating the Decawave DW1000 UWB transceiver with a Nordic Semiconductor NRF52832 wireless MCU and an STMicroelectronics LIS2DH12 3-axis motion sensor. While the DW1000 provides IEEE 802.15.4-2011-compliant RF signaling, the NRF52832 MCU executes its embedded firmware for RTLS applications. The LIS2DH12 sensor plays an important role in power management.

In any sophisticated RF application, RF design typically brings some of the greatest challenges, particularly in mobile applications that require minimal footprint and power consumption. The DWM1001 module addresses these concerns by taking full advantage of the integrated RF design provided by the DW1000 transceiver (Figure 2).

Diagram of Decawave DW1000 transceiver

Figure 2: The Decawave DW1000 transceiver integrates radio signal paths and digital control logic to provide a complete IEEE802.15.4-2011-compliant system. (Image source: Decawave)

The DW1000 provides a complete UWB transceiver that integrates an RF front end able to support six IEEE802.15.4-2011 channels from 3.5 GHz to 6.5 GHz at standard bit rates of 110 Kbits/s, 850 Kbits/s, and 6.81 Mbits/s. The device’s integrated digital control subsystem manages the transceiver, and supports both two-way ranging and TDOA RTLS systems with location precision of 10 cm. An integrated one-time programmable memory (OTP) lets developers store data used for calibration and error correction, while the device’s configurable always-on memory (AON) retains configuration data during the device’s low-power states described below.

In operation, the device transmits and receives standard IEEE802.15.4-2011 frames comprising a synchronization header (SHR), a physical layer header (PHR), and up to 127 bytes of data making up the overall PHY Service Data Unit (PSDU). Besides the standard frame, the device also supports a proprietary frame format that provides up to 1023 data bytes for applications that need to send larger data payloads and do not require compliance with IEEE802.15.4-2011.

For compliant applications, developers can choose from a range of operating modes with preset combinations of data rate, payload size, and preamble length preconfigured to meet specific use cases for two-way ranging and TDOA operations. For example, modes intended for long-range applications combine low data rate with long preambles that facilitate discovery and ranging amidst interference or weak signals. Conversely, modes with high data rates and short preambles support short-range applications. Other modes support these long and short-range characteristics with different size data payloads.

Power minimization

In practice, developers will opt for operating modes with the shortest possible frame size to minimize overall power consumption and return the device rapidly to a low-power state. The DW1000 offers a number of low-power modes. During inactive periods, the device can be placed in idle mode, which consumes only 19 milliamps (mA). For periods of extended inactivity, developers can place the device in a low-power sleep mode that consumes only about 1 microamp (μA), and a deep sleep mode that consumes 100 nanoamps (nA) max (50 nA typical).

As with any RF design, however, power consumption rises significantly during transceiver operation. To transmit an IEEE802.15.4-2011-compliant frame, for example, longer frame components such as the synchronization header and data packet are responsible for most power consumption (Figure 3).

Diagram of transmission of an RTLS frame with the Decawave DW1000

Figure 3: Transmission of an RTLS frame with the Decawave DW1000 results in significant increases in power consumption for each component of the frame, prompting developers to seek operating modes with the shortest useful synchronization header and data payload. (Image source: Decawave)

A further challenge for power-limited designs comes with the even greater power consumption associated with receiver operations (Figure 4). Developers can program the DW1000 to return to one of the low-power states following transmit or receive. Even so, the nature of the standard protocol and frame leave few options for reducing power during frame operations.

Diagram of receiving a frame imposes even higher power requirements than transmission

Figure 4: Receiving a frame imposes even higher power requirements than transmission largely due to the extended duration of the preamble hunt phase. (Image source: Decawave)

The DW1000 does provide a unique power-saving feature to reduce power during the preamble RX phase. Rather than keep the receiver operating, developers can program the device with a special preamble sniff mode. Here, the DW1000 periodically powers the receiver, looks for the preamble, and returns to the idle state if the preamble is not found (Figure 5).

Diagram of Decawave DW1000’s sniff feature alternates between idle mode and active receiver mode

Figure 5: Developers can reduce power consumption associated with receiver operations by using the DW1000’s sniff feature, which alternates between idle mode and active receiver mode. (Image source: Decawave)

Features such as preamble sniff are particularly important for battery-powered tags. Developers can apply a variety of methods for reducing power during RTLS operations. One approach takes advantage of different known delays that exist in the two-way ranging protocol shown in Figure 1.

For example, the anchor’s Ranging Init reply to a tag’s blink during the discovery phase will occur after some delay. Developers can estimate this delay based on frame rate and other parameters, measure its actual value in their anchor designs, or even build a specific response-delay time into their anchor designs. The developer can then safely keep the tag’s receiver turned off for the expected delay time, turn it on to look for a response, and turn it off again if the Ranging Init reply fails to arrive within a reasonable window.

Similarly, developers can take steps to limit the time the radio needs to be turned on during the ranging process. For example, developers can preload the device with all required data and use direct memory access to speed data transfer between the DW1000 and host memory.

While these low-level optimizations can provide incremental power savings, developers can achieve even greater results by dynamically changing the location update rate. After a tag has stopped moving, there is no advantage in proceeding with energy consuming discovery and ranging phases. The tag could safely enter a low-power sleep state, and wake to resume updates at the nominal rate when it begins moving.

The DWM1001 module supports dynamic rate adjustment with its integrated LIS2DH12 motion sensor and support for two motion related operating modes: low-power and responsive. Developers can configure the module to operate the DW1000 transceiver in low-power mode when the LIS2DH12 senses that the module is stationary. When the LIS2DH12 detects movement, the transceiver can return to responsive mode where the DW1000 transceiver resumes its normal update rate.

Developers can further optimize their RTLS applications to control update rate based on the object’s velocity and acceleration. For example, a slow moving tag might only require infrequent updates to maintain required positional accuracy. As the tag speeds up, the application could respond by increasing the location update rate.

RTLS development

Beyond its ability to support RTLS features such as dynamic update rates, the module offers a fundamental advantage for RTLS development. For example, the DW1000 transceiver levies a number of specific interface requirements for supply decoupling, antenna network matching, reference oscillator, and others (Figure 6). Similarly, the NRF52832 wireless MCU and LIS2DH12 motion sensor present their own demands for interface design.

Diagram of Decawave DW1000 transceiver (click to enlarge)

Figure 6: The Decawave DW1000 transceiver imposes strict interface requirements for ensuring reliable power, RF, and timing signals. (Image source: Decawave)

Although advanced devices such as these have greatly simplified design, developers nevertheless can face a significant challenge in optimizing their integration in designs that require maximum performance at minimum power. The DWM1001 module reduces integration requirements to a few connections for power, ground, and digital interfaces (Figure 7).

Diagram of Decawave DWM1001 module simplifies RTLS development

Figure 7: The Decawave DWM1001 module simplifies RTLS development by providing a fully integrated design that integrates the DW1000 transceiver with a wireless MCU and motion sensor. (Image source: Decawave)

Software model

Similarly, the module dramatically simplifies software development and integration with its preloaded firmware for Decawave’s positioning and networking stack (PANS) library. Built on the MCU’s on-chip Bluetooth low energy (BLE) stack, the PANS library includes the open-source eCos real-time operating system (RTOS), a network layer, and application layers that support BLE services, RTLS management services, and the two-way ranging (TWR) location engine (Figure 8).

Image of Decawave positioning and networking stack (PANS) library

Figure 8: The Decawave positioning and networking stack (PANS) library provides a rich platform for RTLS applications with its combination of a Bluetooth stack, RTOS, networking layer, and application service layer. (Image source: Decawave)

In building firmware applications to run on the DWM1001’s MCU, developers access the PANS library through a comprehensive application programming interface (API) that provides appropriate entry points to each PANS module for configuring and controlling the module. The PANS API comprises a number of API sets for separate modules including developer C code, serial interface libraries (CPI and UART), and the BLE library (Figure 9).

Applications work directly with these four higher level APIs, which in turn access the PANS library through a generic API parser that converts those calls into generic API calls to the PANS library. In this role, the generic layer provides a common interface to the PANS library.

Image of Decawave exposes the PANS library through extensive APIs

Figure 9: Decawave exposes the PANS library through extensive APIs, each providing simple access to the underlying threaded execution model. (Image source: Decawave)

Threaded architecture

Within this architecture, the DWM1001 firmware software uses a threaded model, providing essentially a separate thread for each module and library in the stack. Threads for each of the four modules at the top of the stack pass requests for parsing to the generic API parser thread, which validates each request and calls the PANS library to generate an appropriate response. The generic API thread in turn uses a callback function provided in the originating call to return the result back to the calling module at the top of the stack.

Despite the apparent complexity of this multilayered system, the developer’s view of the programming model is relatively simple. The use of API calls with callbacks to independent threads helps optimize resource utilization and overall application performance.

At the same time, the underlying complexity is masked by a series of APIs that translate higher level application-oriented calls to the specific optimized threaded operations interacting with DWM1001 hardware. The DWM1001 programming model further simplifies developer’s interaction with this system. Rather than interacting with multiple threads and APIs, developers use a dedicated user application thread built into the system.

As illustrated in Listing 1, developers invoke the user application thread with a simple API call (dwm_thread_create), which registers 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: With the Decawave thread model, developers register and start their user application thread with a simple pair of calls to the API. (Code source: Decawave)

Decawave provides sample code for a user application thread and callback. The sample code comes bundled in a virtual machine image for Oracle Virtual Box, which includes a complete tool chain, libraries, and the simple sample application. Designed to work with the Decawave DWM1001-DEV development board connected to a Windows PC, the software package offers a framework for creating custom RTLS application software.

Included in the software package, sample code demonstrates key design patterns for the user thread function (Listing 2). In this sample, the user thread function (app_thread_entry) sets application specific configuration parameters such as update rate and registers its callback using the API function dwm_evt_cb_register with the name of its callback function (on_dwm_evt). After registering the callback, the sample thread enters its main loop – in this case a series of calls to a delay function used 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 snippet from the Decawave firmware development package, sample code illustrates basic design patterns for registering the callback and executing the main loop in the user application thread routine. (Code source: Decawave)

The sample callback function (on_dwm_evt) demonstrates a basic event handler that is invoked when an event occurs (Listing 3). In this code sample, the only valid event is the availability of new position information (DWM_EVT_NEW_LOC_DATA). Within the handler for that event, the code demonstrates the simple set of calls needed to retrieve location data generated by available anchors. After completing its event processing tasks, the callback simply sleeps.

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("\nT:%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("\n");

    break;

 

  default:

    break;

  }

 

  /* Indicate the application has finished the tasks and can now */

  dwm_sleep();

}

Listing 3: This snippet from the Decawave sample application demonstrates a callback that provides a basic event handler for accessing new location data. (Code source: Decawave)

In a complete RTLS application for the Internet of Things (IoT), for example, tags and anchors would communicate through routing anchors linked to an Internet connected gateway system. Decawave is readying a second release of its firmware package that will include gateway support through a Linux-based software package using familiar IoT messaging protocols including HTTP, WebSockets, MQTT, and AMQP.

Conclusion

RTLS plays an increasingly important role in a broad range of applications. Although RTLS methods are based on relatively simple principles, implementation of these methods requires sophisticated RF/analog design, system design, and software development to ensure maximum accuracy with minimal power consumption.

The Decawave DWM1001 module provides a complete RTLS system that combines Decawave’s integrated DW1000 UWB transceiver with a wireless MCU and motion sensor. Using this module and accompanying software package, developers can rapidly implement highly accurate battery-powered RTLS systems.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this publisher

Digi-Key's North American Editors