DWM3000 Collison avoidance on low power anchor system

Wireless Connectivity Ultra-Wideband
1

Hi All

We are currently using the DWM3000 modules on our rover and anchor products and have run into some issues when multiple rovers attempt to range to an anchor.

For our system the anchor periodically (~500ms) broadcasts a poll message to start a ranging transaction with all rovers in reception range. The anchor receiver is then turned on for a fixed period of time (this time encompasses a fixed number of timeslots). Rovers then choose a randomly selected timeslot and send a reply to the anchor. The anchor then collects all responses during reception and then broadcasts a final ranging message that anchors use to compute the distance to the anchor. Thus pretty standard three way ranging I believe.

The issue we have found stems from the fact that it appears from testing that when two (or more) rovers attempt to select the same timeslot to send a reply to the initial anchor poll message. What we have observed from testing is that when two rovers select the same timeslot, one of the rovers generally is able to perform a successful ranging transaction, HOWEVER the range computed is often inaccurate. The inaccuracy is sadly not large enough to simply identify and discard due to the slower polling rate but big enough to require significant filtering to smooth out. Therefore gathering enough data points for sufficient smoothing renders the response time of the system near unusable.

The simple conclusion would have been to simply increase the polling rate to have enough samples for smoothing, however this is not feasible as the anchors are battery powered and need to last a set amount of time (thus the 500ms polling time was required).

A collision detection mechanism would be preferred as discarding a measurement taken with a collision present then would work rather well in our case.

A last resort could also be to use a different form of wireless communication (we do have another available) to pre-emptively assign timeslots to rovers. This implementation is something we would actively try to avoid though.

Any thoughts or suggestions would be much appreciated!

2

This is a known phenomenon and is hard to avoid with only Ipatov preambles as is the case with DWM3000. (If STS TOF was used then this problem would be much less).

Using STS will minimise the overlap – you may use STS timestamp, or have a comparison between STS and Ipatov and if not < 3ns then either ignore or perhaps just use the STS. Even if you enable SDC codes (which means you don’t need STS KEY/IV) the performance will be better than with just Ipatov.

1 Like
3

You could potentially borrow an idea from RFID systems. The way that polling works is the base sends a poll and waits for replies. It then sends a poll ack listing all the IDs it received a reply from. Any units that see this message and aren’t listed in it reply again, units that were acknowledged remain silent. This is repeated until nothing new replies.
This system involves more transmissions but since collisions are not now a significant issue it allows you to significantly reduce the number of timeslots and so speed up the polling cycle.

Whether this approach is worth it depends a lot on the number of units involved and how sure you want to be that you get everything.

5

Thank you for the suggestions!