We are looking at the DWM1001 devices for this application : In a large building with many rooms per floor, we will have a single anchor at a fixed location in each room. People who work in the building will be wearing tags and the goal is to be able to detect when these tags are in close proximity to the anchor in each room. These tags can go into any room on any floor. We do not really need to do the real time tracking of the tags. We looked at other technologies, but UWB seems like it would work the best for our application. The station with the anchor will have another device that will read the range of the tag (we also want to be able to read multiple tags if several people walk into the room at the same time and within the proximity of the anchor. We plan to have a threshold of maybe 1-2m that will indicate they are near, and will ignore the readings of tags that are further away, say someone walking down the hallway). Do I still need to use the PANS software stack for this and have every anchor and tag part of a UWB network? I am not sure how this will work since these tags can go into any room on any floor and there could be several hundred devices in the building. Perhaps I can add every device to the same network, but just make sure that there are not more than 30 anchors that are in range of each other?
Ideally I would like to be able to get the range information of the tags from the fixed anchor ( via UART, SPI, etc from another device) but I have seen some conflicting information on if I can do this. One post I saw said I can only get the range information from the tag. If this is the case, what would be the best solution? Bluetooth from the tag, putting an extra device in each room to act as a listener? Would having the fixed devices in each room configured as tags and the mobile units as anchors be a possibility?
You certainly donāt need to use PANS for this, your system doesnāt need most of the features it supports and itās not a good fit for your use case. The problem is that if you donāt use PANS then you need to do a lot more firmware work yourself.
Iām assuming you only need a relatively low update rate and that power draw for the fixed anchors is not an issue since they donāt need to run from a small portable battery.
Given those assumptions the way Iād structure this that each user tag spends most of the time in low power sleep mode while the anchors are always on and listening. Once every few seconds each tag wakes up and transmits a āwhoās out there messageā. Any anchors that see this reply with their ID (it should only be a couple, if itās more than 3 then you can probably turn the transmit power down). The tag then sends a message in turn to each anchor instructing it to measure itās range. This way the anchors get the range measurements but the tag coordinates them in order to avoid two anchors trying to talk at the same time.
Itās a far simpler network structure than PANS but should do everything you need while avoiding some of the size limitations that PANS has.
Andy, thank you very much!! You answered my questions perfectly!! I am new to UWB and these modules/chips, so I am only in the research phase to see if it would be possible to use the DW1000 for our deployment and use. The only eval boards available at the time were the MDEK1001 boards with the DWM1001 modules on them. (Which have the PANS firmware and are designed for the real time tracking) Luckily the EVK1000 are now in stock and we have some coming early next week. Looks like these boards have an ST uC that has their āDecarangeā firmware on it. We are just wanting to use these eval boards for the prototype but eventually will need to create our own PCB with the DW1000 on them. I think the EVK1000 are designed to perform TWR with just 2 devices. We would want to test our prototype with 1 anchor and several tags so would need to see what modifications we would need for that. If we use these EVK1000 for our prototype product, I guess I will have to modify the Decarange firmware on the ST chip. You can also disable the ST microcontroller and use an āexternalā microcontroller to talk to the DW1000 chip over SPI. So I think these are a better choice than the MDEK 1001 board for our simpler deployment and application. Just need to see if it would be better to modify their DecaRange firmware ( I assume this will probably be the case), or create some from scratch. I will have to dig into that DecaRange code as well as look at the specs for the DW1000 to figure out all the commands and operations I would need to send /receive for our deployment scenario.
The actual commands to the decawave chip/module are over SPI so most code should be fairly portable between difference processor families with only minor changes.
The route we went was DWM1000 first for firmware development before moving to the DW1000 chip directly. The DWM1000 is basically a DW1000 with all the RF parts and board layout done for you, a bit like the EVK1000 in external controller mode. And then when we had confidence in the firmware we moved to our own board design with the chip.
And for future reference, when you do make your own board be very careful on the layout, especially on the RF feed, the two power pins right next to it and also the clock source. If you look through this forum there are lots of examples of people who have made their own board and have had issues with this, the chip is very sensitive to power supply and clock noise.
Thanks for the info!! Turns out the EVK1000 boards arenāt available so we may have to go with the DWM1000 boards too. If we go with this UWB solution, we will be extra diligent about the layout. We are also looking at using BLE beacon for this scenario, but I feel trying to use the RSSI to get proximity will not be ideal. Even though we will only want to know if a tag/beacon is within 1-2 m. I ran some tests and the RSSI floats around a lot, and has a noticeable decrease if a person is between the BLE peripheral/server.
To be honest if all you want is to know which room someone is in then a Class 3 Gen2 RFID based solution may be a better fit.
You put one reader in each room near the door (or you can get readers that support multiple antennas if layout/cabling makes that an option) and read the tags as they go through the door. Range isnāt an issue, this isnāt the 1-2 cm range RFID that most people are used to. It can easily read a tag 20m away.
Reader cost would be higher than for UWB but the tags would be cheaper and wouldnāt need batteries.
Both approaches have their pros and cons so it may or may not work for you but I would recommend taking a quick look at if you havenāt already.
I wrote an application that does peer-to-peer and along the way I created basically what your describes.
Having dedicated intiators and responders are MUCH easier to implement than P2P.
Also, there are some challenges when you have a lot of units within RF range since you have to respond to see if something is in range so you have to process everything (in range or not).
There are also lots of commercial products that can do this and availability is really limited for the DWM1001. If you still want to DIY it, the MDEK1001 is the easiest way to get started.
Note that we started out on this as a DIY back in May when there werenāt many commercial options out there; now there are tons and we donāt have to volume to get the price/unit to compete with what we can just buy. Standard Engineering Make v. Buy decision.
We have the MDEK1001 kit and have used it with the app. The problem here is it is running the PANS firmware and more geared towards real time positioning. I think what we need is much more basic than that. We just need an anchor inside each room (there could be hundreds of rooms in a building, on different floors, etc) and the tags will be wearable. As people walk into the room, the āanchorsā will be able to detect that the tag is in close proximity. (Of course this may be a case of the tag initiating the two way ranging, but it will use the fixed anchor in that room. I still need to see how all this works). So anchors will be fixed and the tags will be mobile. So we could know which device would be an initiator or responder. The other evaluation boards are in very limited supply so I think we are stuck with the MDEK1001 or getting the DWM1001 boards. My main question was is it possible to use our deployment scenario and functionality with the Decawave chipā¦I think the answer to this is yes. The other part is figuring out the best way to go about it and how much work will be involved. I think right now the plan is to use the MDEK1001 and modify the firmware to do what we want OR use an external micro with the DW1001 boards.
If you created something similar to mine, which route did you go and did you use one of their eval boards with a micro on it?
Sascha,
Yes, UWB should work for your case; but as AndyA mentioned RFID could be simpler. The main thing UWB will bring is distance measurement which the RFID canāt.
Here is the basics of how it works. Each chip contains a precision clock that can identify the timestamp for when a message was received and schedule when a message is transmitted down the the ns level. For reference, letās name one unit the āInitiatorā and label the timestamps it records as TS-Ix and the name the other unit the āResponderā and label the timestamps it records as TS-Rx.
To make a measurement the āInitiatorā schedules an message at time TS-Ii. That message takes td time to get to the Responder where td=c*d (speed of light times the distance). The āResponderā then receives it at time TS-Ri and determines a response time = TS-Rr and includes both numbers TS-Ri and TS-Rr and the ID of the āResponderā in the packet and schedules it to go at TS-Rr. That message takes td time to get to the Initiator. The āInitiatorā then records the response time as TS-Ir and unpacks TS-Ri and TS-Rr and the ID of the āResponderā from the message. It can then calculate td = [ (TS-Ir - TS-Ii) - (TS-Rr - TS-Ri) ] / 2 them get the distance to the āResponderā as d = td / c.
The code base at https://github.com/Decawave/dwm1001-examples has a simple implementation of this. The code is not the best in the world but it works and is a good starting point. Note that there are two different builds - one for the āInitiatorā and one for the āResponderā. The initiator is the one that starts the request and gets to know the distances. If the āResponderā needs to know too then your need to add an extra message to send that information to it.
Also note the the code at https://github.com/Decawave/dwm1001-examples does not work with never versions of the Segger Embedded studio. See the pull request from RogerK that fixes those or just use his Fork.
Note that as the number of messages travelling around goes up, so does the processor time. Also note that the DM1000 is single duplex so it can not receive and transmit at the same time and design accordingly. Also note that in the sample code, the Initiator blocks when waiting on the response and then does another initiation so it only processes the first (closest) response. Like I said, the code is not the best in the world; but it will get you started.
Wow thanks for the responses! Yeah, we looked at RFID but I think the readers are pretty expensive and big. But we might double check that. I would like to have the fixed anchor in each room be the initiator and the tags be the responders, but have the last message sent to the anchor. This seems to work for single sided two way ranging scheme that you described. The datasheet describes other schemes like double sided ranging, but I donāt think that would work with the anchor initiating the measurement ( the last message would always be sent to the tag.). But you mention that I could send an extra message for this so the anchor gets the ālast messageā?
The ID you mentionā¦is that the PAN ID? One thing I would like is to be able to have each tag have some kind of ID where we could correlate that to a person. Perhaps we could use the PAN ID or just create some other ID to include in the data field of the message?
Yeah I saw those examples on github. I will def look at them more. I think you are rightā¦that might be the best place to start since I already have the MDEK1001 kit / DW1001 modules.
The ID we used was 16 bits of the DeviceID stored in the FICR (Factory Information Config Register) of the nRF52832. We then just checked our prototypes to make sure none had the same ID. We never went beyond 5 units before the project was put on hold.
I got the github examples working. It was pretty simple just using one initiator and one responder. (Just compiled the code and flashed it). Now I guess the challenge is modifying the code to be able to have multiple responders and be able to differentiate between them. I guess I will have to have something in the data stream to be able to identify each responder/tag and then can hopefully get the distances for each one and print them out. In these tests I will just hardcode it or maybe use a config/id register like you did.
How does it work if my initiator sends out a frame and it is received by 3 responders and they all send frames back at the same time (or very close to one another)? Can the responder still receive these frames ok? I saw something about double buffering the receive frames, so maybe that might be a good idea.
No, but if they are all simultaneous and of similar amplitude, it could distort the signal enough that it might not be able to be decoded. In most cases, if the packets are small, it is unlikely for this to happen. Note that since the receive-send time is encoded in the return packet it is arbitrary. If we continued with the project, I was thinking of adding some randomness to this so that if things are slow moving, some packets would still separate even if they were at the same distance. Also, if you have a return packet, you could use the lack of that to trigger a retry. These sorts of games are approaches that are used in other packet communication systems where packets can collide.
As @maskshancock indicated there are lots of standard ways to solve this problem. The standard methods can get quite complex in order to maximize efficiency. If you can live with some compromises and can take advantage of some aspect of your system design then you may be able to simplify things a lot.
e.g. When expecting an unknown number of replies from an unknown set of devices Iāve fallen back to the simple method that each one takes its ID within the site (a number between 1 and 255), and sends its reply after that many milliseconds.
Itās a little slow (255 ms) but very simple. I could reduce that time and speed things up but it works and isnāt ever used in a situation where performance is critical so I left it where it was.
Obviously if I had a 16 bit ID rather than 8 it wouldnāt work and Iād need to look at some other method (e.g. use a hash of the ID number and accept a small risk of collisions) or send acknowledges back and if one isnāt received resend after a random time delay (using the ID as the random seed).
But thatās all adding complexity, depending on the performance you need and the details of your system implementation you may be able to come up with a similarly simple solution.
Thanks guys for your responses!! I think the maximum number we will have in range at the same time will be < 5 so maybe this wonāt be an issue. I can do some testing and see how it goes. And if we do have issues, it seems there should be ways to work around it from your comments. Hopefully in the next few days I will be able to get 3 responders working at the same time. Just trying to get up to speed on the DW1000 user manual and how the example code works. Thanks again!! Will let you know how it goes.
I might have misread your reply. When you started it out with āNoā, did you mean I could not have my initiator send out a frame and get the reply from 3 responders successfully? What I am seeing now is I get just the closest one and that is it. I am thinking that I could be getting the other responses while I am processing the response for the first one. I basically have edited the example code. What I do is start a transmission and then start a 2 second timer. I then loop checking for responses for those 2 seconds. After the timer expires I then send out the next transmission. I tried to take out the actual calculation code and just leave in all the register reads/writes for each reception but still the same behavior. I am going to add different delays to the delayed transmission of each responder/tag and see if that worksā¦something that should leave plenty of time to process each reception. I need to read up more on the filtering but my other thought is to use that to ignore tags I have already āreadā, but I would have to start a transmission each time for that.
Edit: I did add some delays to each unit and am able to get all 3 now. For the first one I kept it at 1.1ms, then I did 3.1ms and 5.1ms for the other two. I am not sure I could use this method for the actual product so will have to figure out another way. But looks like I was getting the other responses while processing the 1st response closest to the initiator and couldnāt get through the processing before getting ready for the next response, right?