Ranging errors with multiple anchors/tags

Hi all,

We are developing firmware for the dwm1000 modules to be able to conduct TWR from a number of tags (<20) to a number of anchors (=<6).
We have encountered a strange issue that gives us spurious “bad” ranges when we turn more tags on.

Example of a good set of range messages (Tag side)

Anchor 1 : 3.5432m Anchor 2 : 1.8463m Anchor 3 : 1.9480m Anchor 4 : 2.9230m Anchor 5 : 5.3439m Anchor 6 : 8.3390m

With the tag stationary, we sometimes see range messages like below (Anchor 5). This problem gets more frequent the more tags/anchors we turn on.

Anchor 1 : 3.6272m Anchor 2 : 1.9451m Anchor 3 : 1.9210m Anchor 4 : 2.8430m Anchor 5 : -33.1019m Anchor 6 : 8.2310m

This issue happens randomly across all Anchors giving range messages of the region of -50 to + 50m. We observe that this happens for frequently the more tags we have on the network. The network seems relatively stable with 3 tags and 6 anchors.

What we did notice was that these errors coincide with PHY /Receive errors flagged up by the dwm1000. Looking at the datasheet we found this snippet that could account for our problem.

We have followed the soft reset instructions which helped a bit but the anomalous ranges still occur. Are the symptoms that we are seeing the ones related to the above paragraph? Or are we seeing something completely different?

Any comments + guidance is appreciated.

Some technical info about our setup.

MCU - STM32F10
Medium access control - ALOHA random access
Channel - 4
Preamble - 1024
Pulse Freq - 64Mhz
Data Rate - 850Kbs
Preamble code - 18
Speed - Tags ranging at 5Hz

No doublebuffering
Frame Filtering on[/code]

Can tag/anchors transmissions overlap? If DWs transmit at the same time (overlapping preambles) then the unit receiving will receive both (if their clock offset/xtal is very small) and the resultant CIR will have both FPs, thus the RX timestamp will be form an earlier FP, and the received message data from either device, so you can have timestamp corresponding to one device and message from the other.

Please use TDMA (will remove these collisions) or add filtering based on e.g. FP index (not as good).

1 Like

Thanks for getting back to us!

Tag/Anchor transmissions can overlap as we are not using the TDMA scheme. Our assumption was that should two transmit at the same time we would encounter a collision and that would be detected by the various CRC checking that the DWM1000 employs.

Is the CRC not that strong? Is there the possibility that they are getting past those checks and we are therefore seeing previous timestamps?

Could you elaborate on how we would filter by the FP Index?

No, CRC is correct :slight_smile: as you have received the correct frame from one of the devices. However the CIR is from both preambles… as the clocks/carrier freq. of both overlapping devices are very close (e.g. couple of ppms) then both preambles will accumulate in the CIR, so the receiver is basically receiving both transmissions and reflections from both transmission etc., depending how these accumulate you may get two strong peaks, or just one, etc… the FP will be triggered on the 1st peak after noise region.

If you read the FP index, you may discover that in bad cases e.g. the FP is < 600, but in good cases it is always > e.g. 650 … so you could use this rough estimate to remove errors…

It will not always be the case but may work in majority of your tests… as I have said the best way to remove interference is to have only one unit transmitting at any one time.

Thank you for your help, I think we see where the problem is now.

In terms of the FP index, what would be the reason for there to be a pattern to it? Should’nt we expect this to be completely random?

In terms of implementing TDMA, do you know if decawave has any example code around implementing this?


The DW1000 receiver is designed to place max energy around index of 730, thus the FP is generally around/near that.

TREK1000 kit, available from e.g. digikey uses TDMA (it is just a demo application SW stack is open), DWM1001 SW (fully scalable system) also uses it but the SW stack is closed.