Hello. I am new to decawave and have used dw3000 to create an item tracking system with 3 anchors and 1 tag using two-way ranging. I took help from the DW3000 library on github. Now I have to increase the number of tags and anchors in the system as desired by the user. How can that be done? Any suggestions would be appreciated.
The short answer is that it’s not simple.
Each tag needs a unique ID so that an anchor can reply to a specific tag. That’s fairly simple and a relatively minor change if you have already added support for addressing specific anchors.
And you need some method of sharing airtime between tags.That gets trickier.
If you have a low number of tags or a very low update rate you may be able to get away with an aloha style method, tags measure their locations independently with a semi-random delay between attempts. As long as the percentage of time that something is active is low this works well. But as you increase the number of tags or the required update rate it can quickly hit a point where it starts to drop off and fail. At that point you need some form of coordination between tags, the best way to do this is very application specific.
Thanks for the prompt reply. But I am stuck in the step of introducing multiple tags/anchors in the system. What should the system design for this initial communication be like? Do I need a master tag/anchor for checking new devices, or should all devices be constantly polling? Also currently the IDs of anchors are hardcoded, how can I do so without hardcoding them. Is it possible?
What should the system design for this initial communication be like?
It depends on how you want to design your system. If you want a TWR based system then each tag needs to measure to at least 3, ideally more, anchors. Each range is 2 or more radio packets, these packets probably need a source and destination address, some sort of type indicator and a minimal amount of data. Only one device should be transmitting at a time. Beyond that it’s entirely up to you how you design the system and the communications.
Do I need a master tag/anchor for checking new devices, or should all devices be constantly polling?
No and probably not. A master device allocating times and IDs simplifies some things but what if something is out of range of that master? You don’t need one but in some situations having one makes things easier. All devices constantly polling would result in a lot of packet collisions unless they do it at a very low rate. You can base a system around that idea but unless you have a very low update rate it isn’t going to scale well.
Also currently the IDs of anchors are hardcoded, how can I do so without hardcoding them. Is it possible?
Yes. The ID is just the value of a variable in your code. That could be hard coded, it could be loaded from a configuration file or it could be received over the radio.
The first thing you need to decide is how you want to control the system and what are the compromises you are willing to make. Will you have a central coordinator node? (this may limit ranges or where you can start units up). Will units automatically configure themselves or does the user need to do that? If the user is configuring things can new devices be added without re-configuring the old ones? Once everything is set up how will the tags know when it’s their turn to be active?
It is a big collection of trade offs and compromises. Everything happening automatically is easiest for the user and most flexible but more complex to implement and less efficient (you need to dedicate more radio time to system configuration and maintenance messages). Everything being fixed based on a user configuration file is simpler to implement but less flexible.
Generally the answer to any reasonable “Can I do …?” type question is going to be “Yes, if you design the system to work that way.”
I am using a dw3000 device as coordinator which receives requests from new anchors to join the system.
void checkForNewAnchors(){
//responder loop part
Serial.println("Searching for workers...\n");
/* Activate reception immediately. */
dwt_rxenable(DWT_START_RX_IMMEDIATE);
/* Poll for reception of a frame or error/timeout. See NOTE 6 below. */
while (!((status_reg = dwt_read32bitreg(SYS_STATUS_ID)) & (SYS_STATUS_RXFCG_BIT_MASK | SYS_STATUS_ALL_RX_ERR)))
{ };
/* Once a frame has been received read the payload and decrypt*/
if (status_reg & SYS_STATUS_RXFCG_BIT_MASK)
{// do remaining tash here}
But it seems like the loop is stuck, I cant get into the if block even if another anchor is sending for the request. What could the problem be here?
Can you make it so that the while loop prints out the value of the status register, or even better prints it when it changes, that will give you some indication as to what is happening and why you are never exiting the loop.
Off hand the most likely possibilities are that either receive is timing out or failing and ending for some other reason you’re not checking for, or that it’s simply not seeing the incoming radio packet which would imply a configuration mismatch between the two radios.
It was apprantly a problem in setup(). I’ve solved that and made the system have a master anchor that coordinates with multiple anchor. But I have confusion in one part. Generally it is suggested to use tags as initiators and anchors as responders, but why is that so? What is the problem with doing the opposite? Also, what would be best if I am to implement a double-sided TWR with 3 messages? And will having multiple tags cause complications in either setup?
There is no reason why you can’t do it the other way around. Either system has similar complications and limitations. You still need the same number of measurements and you need to share time as efficiently as possible to make those measurements without risking conflicts.
Generally there are less tags and you want all the measurements for a tag to be as close together in time as possible to reduce errors caused by the tag moving. This means it’s often easier for each tag to take turns. But you could get anchors to coordinate and so get the same end result if you wanted to.
It also depends where you want the final data to end up and who is doing the position calculation. If possible you want all the data to be available where it is needed without having to add extra messages to pass results around.