I am planning on building a RTLS with Decawaves UWB-products.
Instead of creating an anchor-network and locating movable nodes, I want to use a specific property of my application for my advantage. Any of my Objects I want to track only move in one Axis, x or y.
So I would like to use Two-Way-Ranging between many Devices and transmit all distance Information to a gateway.
This Setup would work like a daisy-chain in some way, I made a s chematic to clarify the matter.
Is this possible with the UWB Chips or the development board? Devices would have to act as anchors/tags as the same time, initiating a TWR and responding to a TWR.
It is possible to build such a network ,you will have to develop a fully custom RTLS stack but it is definitely possible. It is up to you to architecture the system to your need.
Note that as you need TWR, you most likely will need a TDMA layer that will ensure two devices are not emitting simultaneously. (Each device must have dedicated slot to transmit.)
Regarding the hardware, I’d say the dwm1001-dev could be a good starting point for prototyping and proof of concept.
I love these special applications. We develop all sorts of things like this for peculiar use cases. You’ve left out a lot of information about how you want it to work, so it is hard to judge what would best work here.
Is the topology fixed?
Your description implies that the configuration of the devices is well known, that is, the topology of the network, who can hear who, is relatively fixed, perhaps even hard configurable as part of the setup. This will likely make the solution far simpler than a general case where the topology is unknown or even dynamic during operation.
UWB relay backhaul required?
The other implication is that there is no viable way to have a single node hear all the other nodes. That is, you are chaining the result back to the gateway due to no viable place to put the gateway within radio range of all the nodes in play. So you need relay backhaul of data to the gateway. This means a lot of data is collecting in the network that has to be passed up the chain. This also has implications for reliable data delivery (need to not lose data as it hops multiple times) and for radio range (larger packets have to be sent at lower power). Maybe you have another way to bring the data back?
Measurement capacity and rate?
You didn’t specify how often you need measurements and the maximal number of measurements you need to make. If your diagram is meant to be complete, only 7 nodes, then you have a small network. If your measurement rate is low, then you have a small capacity. Having a small capacity can lead to certain simplifications in the protocol. If you need every microsecond of air time to do your work, then it gets harder. So how many measurements per second do you need?
Batteries involved?
Do you nodes need to run on batteries or do they have local power? Having local power greatly simplifies things when it comes to energy management and protocol development. You can leave everybody in receive and avoid some complex timing protocol to have everybody wakeup and sleep at the same times.
Just UWB TWR?
You did state that all you needed was certain distances measured, TWR between pairs of nodes, perhaps knowable in advance. Since TWR is an understand method, this project is really not about UWB per se, but mostly about the protocol and network management aspects. Do you also want things like the accelerometer data?
Yes, it is possible. The physics and electronics support it, I don’t know of any software that will do it right out of the box and it doesn’t seem like a trivial exercise to get it done, particularly if you have more than trivial capacity and reliability requirements.
The absolute simplest system would be something like this:
You have a hard coded topology. Each node knows who is its upstream neighbor through configuration.
Each leaf node (end of chain) starts a TWR with its upstream neighbor. The neighbor responds, and the TWR finishes with a final packet.
Each intermediate node starts a TWR with it upstream neighbor (which could be a gateway). The neighbor responds, and the TWR finishes with a final packet. If any TWR from a downstream node has happened, report those results upstream as part of the TWR operation (add more payload to one or both of the upstream packets).
The gateway works like an intermediate node except it reports results out some local interface to whatever your application is.
The system is unsynchronized, each node sends at some random interval with jitter, so it is an aloha system, not slotted. To build a slotted system will take a much more complex protocol. You can get timing data, however, due to all the timestamps in the network so you can reconstruct the exact time of ranging relative to each node.
This system also implies always on receiving by nodes, battery life will be poor. As the results become concentrated near the top of the tree, they take more and more air time. The system has no reliable delivery mechanism, a lost packet is lost data.
Given it is an aloha system, packets may collide, be aware that colliding packets can upset the LDE algorithm inside the DW1000 and produce somewhat erroneous range measurements when that occurs. Some filtering and detection is warranted if your application can’t tolerate that. This is another benefit of a slotted system if the complexity is warranted.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
