DW1000 TWR Multi-TAG

Hi,
I’m attempting to apply TWR strategy to 2+ TAGS simultaneously. In my idea, when first TAG blinks, it inhibits the other TAGs to perform ranging, and once the ranging is finished it emits a blink message to enable other TAGs. Other than difficulty in the implementation, more the TAGs in the system more the update rate of every TAG will decrease.
I suppose TWR protocol might be not suitable for this task, any idea?
Thank you

Your battery life for the tags will be dreadful because the tags will always be listening to hear other tags claiming air time.

What happens if a tag hears an air time claim and then doesn’t hear the release?

A tag may not hear the claim packet and still step on the transmission of others.

Once a tag broadcasts a release, other tags then will try to claim air time and they are now synchronized by the first claim, so you get a pile up. The standard treatment is that every tag implements a random backoff, but this isn’t much better than just being random.

If your air time load is under 20%, consider just doing straight Aloha access (tags randomly broadcast with jittered intervals). This works pretty well if you can tolerate the occasional air time collision.

The best you can do is some sort of self organizing system that specifically schedules everybody into slots. This is a major effort to accomplish without a central resource.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408

One addition to mciholas post.

There is a slight cheat you can use to help in this situation. If you know the maximum number of tags and each tag has a number programmed into it between 1 and that maximum then as soon as a tag hears any other tag transmit it can work out how long it is until its turn. In effect the centralized resource organizing things is done statically at setup rather than dynamically.
This is far from perfect, it’s got no flexibility, it requires either reasonable clock accuracies or large inefficient time windows, and you still need to do a reasonable amount of listening to ensure everything stays in sync.
But it does allow a higher utilization than just random transmission if you can live with the limitations.

That’s a pretty good idea but it has a few complexities.

You would have to allocate fixed time intervals for the ranging so everybody can compute the proper times to transmit. This is not generally a problem since one can measure what a range operation should take.

There is a problem of how to get it started. A simple idea would be tag #1 always starts, but it could be out of range of others when that happens, or it is off. This makes the network fragile to tag #1 behavior.

If you allow any tag to start, then you can get a mess if two try to do it at the same time. You could end up with multiple interspersed tag clusters on different timing.

There are algorithms for “leader selection” processes among a network of peers. This could be used to not only nominate an active leader, but also to number out the units dynamically. This is research paper type stuff, particularly when the connectivity graph is sparse.

If the tags can separate into two or more groups out of range of each other, then things get wanky as groups drift apart. If they come into contact again, could be some chaos to get it all back in sync. Complicating that is the likely situation that the two groups synchronously stomp on each other for a while since they are using the same timing, but now have a skew.

We’ve worked with various concepts like the above (and for swarm robotics which has similar self organizing issues). They are maddening to implement because the resultant behavior is often unpredictable and counter intuitive, and it can be very difficult to debug given dynamic state is distributed among all the nodes.

If you are under 20% air time, go with Aloha. Simple.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408

1 Like

We’ve used this system well with our system and get good performance out of it. We can easily hit a total ranging rate that is over 80% of the theoretical maximum for the protocol used.
However we are a non-standard use case for UWB, we’re plugged into a car and so don’t care about power usage and can listen all the time and only have a few units we need to sync between.
On start up each system listens for a full repeat cycle, if it doesn’t hear anything it starts up based on it’s own arbitrary timing. Outside of its time it is always listening and will sync to any packets it picks up. Worst case if two systems come into range of each other you a brief period of conflict before things sort themselves out but normally they will hear the anchor replies to the other system and sync up before the two tags get within range of each other.

But as with most things there is no universal best solution, it depends a lot on your use case. This works well for us and was simple to implement. Whether that is true for gab93 is a different matter.

Thank you for your replies,
finally I opted for random ranging between TAGs and anchors. The reason rely on my current circumstances: TAGs are not colliding every time, most of the time they are quite far, other times they might collide. It resulted hard for me temporize them only when they collide!
The main problem in random ranging is that after a certain amount of time (more the TAGs less the time), they “get stuck”, and are not anymore able to receive ANY message. I think this is related on fact that TAG messages go in conflict with anchor messages a TAG receives. I thought something related to frame filtering to avoid TAGs receive other TAG messages, but I don’t think it is possible. Some suggestion?
Thank you

Gabriele