You are asking about what we call “mesh ranging”, computing the set of distances between peer nodes on a regular basis. We’ve built a system that works somewhat like this and it is deployed for a customer in their product.
The system works by each tag having a scheduled time to transmit. Say we have 5 tags, A, B, C, D, E. They will transmit in a schedule in sequence. Each packet will contain the serial number of the transmit packet, the local Decawave Time (DT) of the transmit, and a list of other nodes serial numbers and receive DT.
For example, when A transmits, the packet will contain A transmit time, and then B, C, D, E receive times, if they were heard. Then B will do the same, then C, D, and E. At whatever the repeat rate is set to, A will start over again.
A range can be computed between any two nodes knowing 6 timestamps (3 transmit, 3 receive). This takes two cycles of A and one of B to get enough data for B to compute the range A to B. It takes one more cycle for A to compute the range. Also, any other node, say C, can compute the distance between A and B just by listening to the packets exchanged between A and B. By keeping the cycle going, what was the third packet in a range computation one cycle now becomes the first packet for the next cycle. So each cycle produces a new set of range outputs.
The system has a present day capacity of about 300 Hz-tags. That means you can, for example, have 10 tags that cycle through at 30 Hz, or 30 tags that cycle through at 10 Hz, give or take. One issue is that as the number of tags grow, the size of the tag packets grow (more data being received). One effect is that transmit power gets reduced for larger packets and they become less reliable, so this can limit network diameter. Another is that your air time schedule has to allow for large packets. A further consequence is that the largest packet can only hold about 40 tag receptions in it.
Because tags have to keep their DT running, we can’t go below IDLE mode between UWB activity, so this lowers battery life on the tags. Also, since we are receiving a lot of the time, this hurts battery life as well. So mesh ranging tag battery life is not great and is not good for long lived tags. If the tags are fitted to mobile devices like robots or machinery, this is not an issue, or if the tags are used for relatively short duration events, then that isn’t a problem, either.
The system is not stand alone at present. There is one anchor which serves no locating purpose (though it can be mesh ranged to the tags). The anchor serves as the controller of the network, to send out tag configurations, and to keep network time the tags synchronize to for time slotting. The anchor also collects all the received packets and sends them to the back end server via Ethernet, which then does the range computations. The single anchor imposes a limitation that all tags need to be in range of the one anchor to operate. This particular architecture served the client’s needs well and made for an easy to manage and debug system. So in this respect, it doesn’t match your desired system architecture.
The system has obvious directions of improvement. One, we can improve air time efficiency which is presently under 50%, so doubling the capacity is possible. Two, we can define response packets which don’t need a slot for every tag and provide a selection process for which tags are sent back. This will shorten packet lengths, improve air time, and improve packet reception range. Three, allow more than one anchor to grow network physical size. Lastly, making a system that is fully anchorless would be possible, but introduces some complex distributed timing and control requirements that have to be solved, particularly if the nodes are distributed more than one network diameter apart.
The fundamental aspect of any mesh ranging system is that it takes a lot of data exchanged between nodes to do it. This necessarily limits capacity, uses up air time, and drives up battery usage. If you want to do this at 5 Hz for hundreds of tags, you have a problem if they are all in one area. If you have hundreds of tags so far spread out that any one node only sees a few others, then it might work using some sort of Aloha style system, but it will be low capacity.
If GPS or RTK GPS is an option, that wins hands down for outdoor swarm localization. I know it seems like cheating, but there’s no better way to get lots of locations than that. Then each node can broadcast it’s coordinates every so often and everybody knows where everybody is. Not every outdoor application is GPS compatible, of course, but something to consider.
That is potentially useful depending on your application. It would allow you to compute bearing for any packet being received. To be really useful, it needs to work 360 degrees, not just ~90-120 degree wedge the PDoA system currently does, which is something we are working on in our lab and should have out end of the year or early next. You would need only one short packet from every node to compute bearing to them, but that still doesn’t give you range until the packet grows and contains all the timestamps you need for that, so you still have the air time capacity issue even with bearing.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408