Creating an RTLS system with UWB, Nordic and Zephyr OS

Creating an RTLS system with UWB, Nordic and Zephyr OS

#RTLS, #UWB, #ZephyrRTOS, #Nordicsemiconductor, #embeddedsystems, #tips

With our second RTLS project based on UWB, we want to share our experience with the community and give away some hints on how to speed up the development with Nordic and Zephyr OS.

The first project where we have created human locating system was a Maritime project done for DimeQ AS. You can find a short description of that project in our portfolio – Maritime RT human positioning system – Embevity.

The second one, which we are doing now is a project where we need to define a real time location of sports equipment, specifically a football in the game field. This project comes from our Client – AIRTLS.

Executive conclusions and takeaways

1. Out of all RTLS technologies, UWB is a very ‘accurate’ choice;
2. To speed up your development and save power, we recommend using Nordic and Zephyr OS;
3. nRF’s PPI will improve your time critical performance;
4. The generic hardware interface may need to be optimized to speed up performance (example below).

L as Location

Let us start with a summary of available positioning technologies. The first thing that comes to my mind when thinking about providing an exact item or person’s location is GPS. It is now integrated into most wearables and smart devices, being the essential part of navigation and tracking systems. We would all probably settle here and stop searching for alternative approaches if those widely known constraints of the GPS did not exist:

• It consumes lots of power due to constant satellite signal search and reception,
• Its accuracy could be better and can be easily affected by environmental conditions,
• And finally – it does not work in the case of indoor locations.

Let us concentrate on the third one – the indoor systems. The natural approach was attempting to create positioning services based on WiFi and Bluetooth due to their popularity for basic communication purposes. The concept here is that by observing RSSI (Received Signal Strength) and radio packet propagation time, we should be able to determine the item’s position. However, due to the characteristics of radio frequency used, many various obstacles the signal faces on its travel path and overall air congestion caused by existing 2.4GHz systems, the resulting accuracy is almost always far below expectations. It is maybe safer to classify those as proximity detection technologies, just like “the item you are looking for should be somewhere here”. Also, they can drain small batteries fast.

The newest technology mostly used for positioning purposes is the UWB – Ultra Wideband. With high bandwidth, multiple frequency ranges in GHz range and pulse transmission characteristic it is believed to be more resilient for different environment influence. What is more important, signal propagation time metrics got far more reliable, making it a great direct input to well-known multilateration algorithms. Using UWB it is physically possible to achieve location accuracy in the range of single tens of centimeters. Combined with the nowadays offered data throughput of up to 27Mbit/s it might also be worth considering the technology for basic wireless communication systems. What about power consumption? It depends on how the positioning is performed, but more on that in the next chapter.

More information about UWB technology can be obtained from commercial radio manufacturers like Qorvo or NXP. Actually, the UWB radio could travel with you for some time if you selected Apple mobiles or wearables.

S as the System

There are two basic positioning techniques that can be used with UWB technology to create a working system:

• Two Way Ranging (TWR)
• Time Difference of Arrival (TDOA)

TWR is based on exchanging messages between two devices, requiring precise send and receive actions timestamping, to estimate packet Time of Flight (TOF). The TOF value can be easily converted to the distance if we assume that bits fly with the speed of light. If we collect enough measurements between nodes with known and unknown locations, the latter ones can be found.  The best thing in this approach is that the devices do not have to be synchronized, meaning no common clock is required.

TDOA in contrary does not require two-way data exchange. It is sufficient for the object that needs to be located to periodically send a single packet that is received by multiple listeners, each having a known position. The location can be estimated by comparing the exact time the packet was recorded between nodes. Although it may seem a preferable and simpler solution it generates one severe problem when compared with TWR: to compare reception timestamps we need a common time reference. It gets even harder when we realize that the timestamps are gathered in picoseconds units which naturally means the synchronized clock model must have similar accuracy or the position estimates will be useless.

Regardless of the technique used, there is another important design decision to be made: how are we going to guarantee exclusive air access for the transmitting party? The UWB radio, at least the one we worked with, lacks any media access control meaning that without proper precautions we can cause air traffic collisions and loss of information.

The simplest solution could be just to accept the risk of collisions but limit its probability by randomizing transmission time and keeping worst case possible congestion much below available network capacity. That is closely following ALOHA protocol standard. It is the best we can do to maximize battery life of a device being located, as it might only use the radio to transmit for a very short time and even never enter reception mode, thus saving lots of energy.

An alternative approach to the problem might be making the decision to implement TDMA – Time-Division Multiple Access in UWB domain. Here we divide air time into slots and allocate each active network device one from the pool. That potentially allows using full available air capacity for transferring data removing severe constraints from maximum system scale. The complexity here is that each device must be able to precisely trace and synchronize to the network operation, which requires radio working partially in reception mode and some good local clock synchronization algorithm.

RT as Real-Time

Now the theory finally meets practice. At Embevity we were given the task to design and implement RTLS based on UWB positioning in two different projects. Based on the specific requirements, quite different for each of them, we had an opportunity to create both TDoA and TWR systems, including ALOHA and TDMA medium access schemes.

It also happened that both of them are based on Nordic Semiconductor microcontrollers controlled by the firmware running under Zephyr OS. In order to guarantee real-time, deterministic data flow required to fill available network capacity it is crucial to select the right tools early in the design process. Here we would like to share a small part of our experience.

1. Reliable RTOS

As already discussed, creating RTLS system is a complex task. There are so many time critical dependencies between actions that must be completed on time that building whole application at event loop, single thread concept is going to block you at some point of the development. Especially that the device being located for certain has much more functionality to handle, e.g. sensors measurement, data processing or even UI to control. RTOS, such as mentioned Zephyr, allows you to properly prioritize CPU work, and guarantee that time deadlines are met. For example, in TDMA scheme the CPU must push out the packet in an assigned slot not to disturb network operation and it would be a treble thing if we would have to wait for some UI control to render on the display first.

2. Low-power MCU optimized for performance

The Nordic Semiconductor is for sure one of the market leaders in providing Bluetooth Low Energy components including the nRF microcontrollers line. While we all wait for the recently announced nRF54, the flag product for today is still nRF5340. It is a dual core Cortex-M33 design running at 128MHz clock and able to drop power consumption to microamperes range in a sleep mode. The crucial advantage of 53 when compared to nRF52 family is that all time critical radio handling can be delegated to the network core, making program execution in the application core easier and far more predictable. Otherwise, there is always a conflict in meeting time deadlines between the wireless stack (e.g. BLE) and application, which is always resolved in favor of the former due to SDK and library architecture. And chances are that if you selected Nordic MCU, at some point you are probably planning to use its internal 2.4GHz radio.

There is one unique hardware feature available on nRF MCUs called PPI – Programmable Peripheral Interconnect, that might greatly help you with time critical processing. It is your gate into extending hardware capabilities beyond manual firmware register control to build and automate peripheral state machines. The concept is extensively used for radio control both by Nordic and Zephyr BLE stack version – the reserved PPI channel pool can go past 20 in some configurations. The PPI channel creates a bridge between one’s peripheral event and another’s trigger task. For example, you can connect hardware timer (timeout event) with SPI controller (start transmission task) in order to synchronize the exact moment of the transfer beginning. In that way you no longer must completely rely on OS scheduling or worry about interrupts being delayed by locks or nested preemptions.

3. Libraries and drivers

To build your own RTLS you are going to need a good development starting point, just not to be stuck for too long in a stage where you must prepare BSP for your custom board or write that LED driver for the 5^th time this year. There are still hours of work needed before you reach positioning proof of concept so better manage your time and resources wisely. Zephyr, as not just an OS, but rather a full development ecosystem can give you the advantage. As highlighted in our previous blog entry, there is lots of code already prepared to be integrated in the final application including device drivers, sensors subsystems or wireless stacks.

However, here is one thing you need to remember about: Zephyr is developed for multiple platforms and therefore needs to cooperate with different architectures and peripherals. Such generic hardware access interface flexibility never comes without any cost. And in some cases, the overhead of all those intermediate layers and compatibility code before actual registers operations are performed can be a real blocker for the project.

At Embevity, we found ourselves in that position by working with stock SPI driver for nRF chips. We needed to repeatedly perform a series of short transactions to setup UWB radio for transmission and just by looking at the logic analyzer traces it could be clearly seen that lots of cycles are being consumed, or more brutally wasted, between consecutive transfers.

Figure 1. Logic analyzer capture of the Zephyr stock SPI driver performing transfers on nRF53.

A short online check also showed that we were not the first one to find this part of Zephyr implementation problematic (for example discussion here and here). As in our case it was a bottleneck, we decided to exchange the stock driver and write something custom, but heavily optimized for nRF53. In the result, we reduced the overall transfer series duration by half, and such performance allowed us to meet project requirements.

Figure 2. Logic analyzer capture of the custom SPI driver developed by Embevity performing transfers on nRF53.

‘RT’+’L’+’S’+ Embevity = Real-Time Location System

Creating RTLS system is a challenging and for sure rewarding task that requires both engineering knowledge and experience. Our team is extremely excited to see our clients now reaching the market with ready products, which thanks to UWB technology selection, can perform positioning with high accuracy and reliability.

Figure 3. RTLS software locating people in the elevator in our HQ.

Congrats and thanks

Congratulations to our PM and developers for reaching the goals – Anna Tyczka, Krzysztof Bartnicki and Daniel Dyringer.

We also thank Zephyr Project and Nordic for their tools and support. And of course we thank our Client AIRTLS for giving us the opportunity to work on this challenging project.