Hello Guys. recently I have bought 4 DW1000 modules for my project.
I wanted to connect them to ESP32 module for its micro controller and sent distance to Main Server over WIFI.
I found thotro’s library that is programmed for my hardware and work.
This: https://github.com/thotro/arduino-dw1000
I tested it with 3 Anchors and 1 tag, it seems to work great.
after testing I run it with more tags. but it sucks. as I research about dw1000 Two ranging protocol and its limitation, I found out there is a multi-stage session in a popular way.
someone said that:
Anchor receives two BLINKs from TAG1 and TAG2
Anchor sends one Ranging_INIT to both of them (broadcast)
Anchor receives two Poll messages from each of Tags
Anchor sends one PollAck message (broadcast to all Tags)
Anchor receives first Range(from TAG1 for example) msg and calculates the distance
Anchor receives second Range(from TAG2 for example) msg and calculates the distance
Measurement starts from third point.
in this lib there is a limitation for receiving and timing and syncing. as i know each anchor can be received data or Poll at a time.
for doing this with many anchors, for example 12 Anchors (maybe more needed) and 5 Tags we faced to many complexity. i saw a decawave product mdek1001 and I realized there is limitation about scenario(tags+anchors numbers) if anchors/tags numbers are changed our library and algorithm must be changed. it is totally dynamic. can’t be done once for any scenario.
We want to implement indoor positioning for a place about 4000 meter. 40x100.
and I guess we need implementation from zero? writing a library ? is there a simple way or a ready development tool for my goal and related to my hardware?
There are lots of ways to do this but generally they come down to three options:
Using DWM1001 hardware or some variation on that and run the PANS firmware that is supplied.
Write your own system to control all of the radio communications and calculate positions.
Hire some other company to do option 2 for you, ideally one who has DW1000 experience and already has most of the building blocks and expertise.
Option 1) is by far the best option if the system can do what you need. 2) is more flexible and can give better performance for your specific application but is a lot more work. 3) is faster and easier but will be expensive.
I went with option 2 and can get accuracies of a few cm over a 40x700m indoor area with a 100Hz output rate. But it took years to get to that point.
Yes you can do that with any of the modules. The DWM1000 gives you more choice of processor since it’s just the radio while the DWM1001 and MDEK give you all the required hardware. If large areas you can either build one of the modules into your own system that adds any power supply or IO requirements you have or go fully custom. Fully custom hardware gives you control over the antenna and so more flexibility but is a more complicated task.
By your own system I mean creating your own radio protocol to measure ranges, your own smoothing and filtering logic and your own position calculation method. You will also need to create configuration and setup tools and data display and output tools.
As I said, a lot more work.
Also for any commercial system unless you are using DMW1001 hardware running PANS you are going to need to perform FCC/IC/EC conformity testing to certify it for whichever countries you wish to legally sell it in. This will be in the 10’s of thousands of dollars.
Hello. You need to assign a different ID to each anchor, and you also need to use a different ID for the tag. Then, you can use ranging to find the distance between each anchor and the tag.
You mean how do you assign IDs to each unit and avoid two tags being active at the same time?
This comes down to the basics of how you design your system. It’s not something you can just hack together as you go, you need to design how it’s going to work before you do anything else.
The way I did it (there are lots of other ways):
IDs - you need some way to set these. For me each unit is given a unique ID stored in the OTP memory of the UWB chip. The system configuration file then contains a mapping between these unique IDs (which are going to end up being large non-sequential numbers) and in system IDs (which are sequential and start at 1, and ID of 0 is used to indicate broadcast).
All radio packets sent start with the same 3 fields, packet type, sending ID, and destination ID. Receiving devices look at these 3 fields and if addressed to them process and respond to the remaing data within the packet based on the packet type.
Time sharing between tags is the tricky part.
I didn’t require a lot of flexibility and so went with a system where each tag knew how many other tags there are and where it was in the sequence (I did this via the IDs with anchor IDs going from 1 up and tag IDs going from the maximum for tag1 down). So if a tag has an ID of 254 and that there are 3 tags it knows it’s the second tag of 3. It also knows how long each tag gets before moving on to the next one. So if ID 254 sees a transmission from ID 253 it knows the 3rd tag is active and that one time period later it will be ID 255s turn followed by it’s turn.
On startup each tag listens and trys to work out when it’s turn is. If it doesn’t hear anything it starts running anyway. This logic keeps running the whole time with tags constantly listening to work out when their next time will be. This way tags automatically organise themselves. The down side is that it’s not flexible to changing the number of tags in the system and the constant listening is a power hog. Not issues for me but could be for other applications.
Other options include some form of central coordination to to allocate time between tags (fairly efficent and flexible but requires that central node which then adds complexities when trying to scale it), an aloha style system where each tag runs independently but with a semi-random update period (simple and effective for very low duty cycle/slow update systems, terrible for high density/update rates), or a listen and transmit type system, either an aloha system or some loose time coordination but then listen before transmitting and back off for a random time if you hear something to reduce the risk of collisions.