Hello!
I am currently working on my bachelors thesis about indoor localization. For that purpose i ordered a few DWM3000EVBs with the recomended Nordic DKs.
I am implementing a TWR localization with 4 anchors and 1 tag for now. But i would like to use more tags after i get this first prototype up and running.
I have the issue that i cannot use multiple anchors successfully though. I only get correct measurements from my anchor(s) if I only use one tag and one achor. So i cannot get the position, but only the distance between one tag and one anchor.
How can i fix this? I am thinking that this is probably an issue with interfering UWB signals?
My program is based on the example code for double sided TWR. I would really appreciate any help I can get!
When you have two anchors switched on how do you control which one replies to a range request from the tag? It sounds almost as if you have exactly the same code and settings in all the tags and so they are all replying at exactly the same time.
You need to give each one a unique ID and then include the ID you wish to range to in the message from the tag. That way your tag can measure to each anchor in turn without multiple devices transmitting on top of each other. This does mean that each range is measured at a slightly different time but unless you are moving quickly that’s not normally an issue.
Thank you very much for your help! I did indeed not give each anchor a unique id.
Is it also possible to send out a first, generic message from the tag to which every anchor can respond? The responses would have the unique anchor ids and the tag could then send out the final message to those anchors? That way the tag would not have to know the Anchor ids beforehand.
Yes but with caveats. You need to ensure they don’t all talk at the same time which means you need to have some why of setting which anchor will reply when. So how do you do that?
To give you an example my system has two different types of tag to multi-anchor message.
The first is known as roll call. Each anchor waits its ID multiplied by 1ms before replying. The system has a maximum of 256 devices which means this command takes over 1/4 of a second to complete (long enough that ranging accuracy using it would be terrible due to clock differences) but is guaranteed to give a full list of devices in range.
The second is when I want to measure the range to a set of anchors. For that message the tag includes a list of the IDs that it wants to reply in the message, each anchor then replies after a delay based on where it was in the list. This allows for far tighter time control but requires you to know which anchors are available.
In your situation you probably don’t need much flexibility. If you were to assume that 1) you will only ever have a small number of tags (say under 8) and 2) most of the time most of your anchors are in range then you can simplify greatly. Set them to always reply after a delay fixed by their IDs similar to my roll call. If you know the maximum ID then that multiplied by the time taken to send each reply plus a small amount of turnaround time gives you your maximum range start rate.
I have tried to implement this as you suggested with the anchors waiting for their anchor id ms. In the TWR example I found the initiator to only take the first response and then initiate another poll tx message. To prevent this from happening i simply loop after the poll tx for a few times to get all responses and to calculate the distance to all the anchors in range. However i found that no matter how long I wait for the responses I only ever get the first anchors response. Is it possible that the UWB chip does not buffer incoming messages while the µc is processing the first ranging request? Then again, according to my calculations 1ms should be enough for the tag to handle the first anchor.
I don’t understand, why the tag only processes the first anchor response and does not even seem to receive the ones after that. All anchors in range reply to the initial tx poll from the tag, but those replies seem to get lost. What am I doing wrong?
Without looking at the code you’re using it’s hard to be sure but you may need to use some lower level functions to re-enable the receive logic on the chip. Simply checking for new data without re-enabling the receive first isn’t going to find anything.
In the default mode the DW will not receive a second packet until the first packet has been read and the receiver re-enabled. Enabling the receive will reset a number of the registers and so shouldn’t be done until you have finished reading the data out.
There is a feature called the swing buffer set that defaults to disabled. This enables a second set of receive buffers so that you can re-enable receive and have the data be stored in the second buffers while reading the previous packet out from the first set. But even in this mode you still need to re-enable receive after the first packet has arrived.
When I have my system running at it’s highest rate I will have anchors sending their replies with 330 us gaps between each transmit. Each packet takes around 160 us to send so my tag has about 160 us to react to the interrupt, read the all the data and re-enable Rx on the radio. I manage to do that that just fine without using the double buffering system. I am running the SPI bus to the radio chip up at 20 MHz, cranking that speed up has a massive impact on how fast you can turn things around assuming the hardware can take it.
Dear Andy, What would you recommend for being able to use multiple tags? My system works fine with one tag, but when there are multiple tags, the system gets stuck and freezes. How can I prevent this?
That comes down to the message structure and radio protocol.
Only one device can be transmitting at the same time or communication becomes unreliable. How you ensure that condition is met is up to you.
Generally this requires two things - 1) a method for each device to know whether the message is for it or a different tag/anchor and 2) a way to ensure two devices don’t initiate a communication at the same time.
For 1) you need to modify all the messages you are sending to include the ID for the device you wish to talk to. While doing this you probably want to also add the ID of the device sending the message so that replies can be correctly addressed.
There are lots of ways to handle 2). You can have some central coordination system assign times to each device. Or you can have devices listen and take turns (with lots of different ways to decide when it’s your turn). Or you can go for the really simple solution of make each device wait a fairly long random period between range attempts, if each individual device is quiet 95% of the time and waits a random amount of time between transmits the chances of two of them picking the same time are slim and the random delay means the chances of them conflicting multiple times in a row is even smaller. It’s not robust and it doesn’t scale well but it is simple.