We are developing a positioning solution for tracking vehicles. In this solution, there is no Anchor/Tag concept. Here each node can communicate with any other node in the vicinity. We may have a maximum of 16 DW1000 devices present at any time that can range each other. We have a ranging interval of 100 - 500 ms. Each node start ranging with another node in this interval. So if 16 nodes are present, Node 1 will range with Node 2 to Node 16 periodically with the above interval. Here the problem is since there is no master node, the ranging is uncontrolled. We can’t assign time slots for the nodes. We have added some random delay to the ranging interval and also used pseudo-CCA for collision detection. But the ranging success rate is very less when the number node increases. We are getting a high packet error rate when the number of nodes increases. How to manage this issue? Is there a way to increase the ranging success rate in this solution.
Hi Shijo, while I do not have an answer to your question yet, I am also in the early stages of researching a solution which is mobile and does not use any anchors. I would be interested in discussing your experiences doing this so far! Let me know if you’re willing: kristo.jorgenson [at] gmail.com
Thanks very much and best of luck with your issue!
if the nodes access the air-time randomly, then the real successful transmission rate would be defined by the Aloha (~18.4 %), see https://en.wikipedia.org/wiki/ALOHAnet. For the TWR which requires successive response the rate would drop further.
I think a kind of chaining TDMA can work well. No need to have any master but the nodes need to keep in sync with its surrounding nodes. Someone starts and the others just join and try to avoid collision. In case the collision would happen there should be some mechanism to solve that.
You are doing what we call “mesh ranging”, producing a mesh of all distances to all nodes in range.
I’m going to surmise this application is vehicle proximity detection, a very popular use of UWB. We’ve done a number of these projects with varying requirements.
Here the problem is since there is no master node, the ranging is uncontrolled. We can’t assign time slots for the nodes. We have added some random delay to the ranging interval and also used pseudo-CCA for collision detection. But the ranging success rate is very less when the number node increases. We are getting a high packet error rate when the number of nodes increases. How to manage this issue? Is there a way to increase the ranging success rate in this solution.
You are discovering the main issue with mesh ranging, it does not scale well if done straightforwardly. It grows O(N^2).
You need to develop a clever protocol to overcome your issues. We’ve done a few different methods to make this work, the right one will depend on the power and performance you require. They are not easy to implement since they are distributed and hard to debug.
One can infer from your use case, vehicles, that you have no power constraints, that is no battery to protect, if you are vehicle powered. That will help a LOT in designing your protocol since it can allow the nodes to remain in receive mode generally all the time.
Here is a simple approach that MAY work for you:
Each node is generally in receive mode when not transmitting, hence the requirement you have vehicle power. Any packet received is time stamped and stored in an array. If there is already an entry in the array for this sender, replace it with the newer data.
Each node broadcasts at an interval that jitters +/- 10% say. The jitter is to keep two nodes from synchronously stomping each other for a long period of time.
The node broadcasts the following data:
TX serial number or ID
TX time of packet sent
Array of
RX serial number or ID
RX time received
RX quality
The array contains data on any packets heard in the last interval, and then is emptied to build up receptions in the next interval.
If the node hears a lot of packets, it adjusts its interval to longer, a kind of load back off in heavy use cases, while giving faster response in the more typical light load case.
A node can compute their range from another node if it has heard two packets from that node and the second packet reports one packet from the first node. This is basic two way ranging, but with asymmetric intervals.
Each packet sent will have 15 receive entries and 1 transmit entry, so let’s say that is 24 bytes per entry, 384 bytes total packet length, or about 500 us per packet at 6.8 Mbps bit rate.
There will be 16 packets per interval, 2 Hz, means 32 packets flying about per second. That’s 16 ms of air time per second, or only 1.6 % air time loading, well within aloha realm of operation (anything under 20% generally works). Thus you can go much faster, say 5 Hz, 4 % air time loading, and still be mostly okay. There will be some packet collisions and loss, but your system has to tolerate that in any case.
The secret is to make multiple use of each packet to serve ranging to all nodes it hears.
One side effect of this system is that node A can compute the distance between nodes B and C if it hears the packets from B and C.
Designing custom protocols like the above to suit each application is something we do all the time. It gets really hairy when you need to conserve power, say for a battery. In those cases, you really do need very scheduled events (so receiving can be kept to a minimum) and that creates a pretty complex distributed scheduling system.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
Yes, you should not interrupt any receive in progress. At best, nobody will hear your packet as they are tracking the one already being sent. At worst, you will corrupt the one already being sent and ruin both packets.
Once the receive completes, you should NOT immediately send a transmit packet because that increases the chance of collision with another node doing the same. Instead, perform a random backoff delay so that other nodes are unlikely to collide with you.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
Hi,I wrote a piece of code as you suggested，i have a ranging intervert of 100ms, But I found that the error is large because the reply time is too long. please help to reduce the error. Thank you.
The more accurately you can track the clock differences between the devices the longer the time periods you can cope with. Any individual rate measurement will be subject to noise and errors but the values should on average be correct. If instead of using an instantaneous value you smooth or average the clock rate differences over time you should be able to improve the accuracy of this correction and so maintain accuracy over longer periods of time. This will only work if the clock rates don’t change very quickly but that is normally a reasonable assumption.