Hey all, I wanted to create a system that optimizes anchor battery life at the expense of tag life. Another focus would be on minimal anchor deployment so the anchors would not necessarily be within range of each other. The tag only needs acouple hours of battery life meanwhile the anchors ideally need 1month to 1yr of battery life. My question is, does this seem possible with the DWM1001 and if so which software stack / example should I use as a basis?
I envision the system as:
Tag is always listening (high power)
System would only support a limited number of tags (16?)
Anchors would/could be out of range of each other. Placed 100M apart for example w/ the DWM1001 hardware(presumed 60M range LOS)
Anchors would periodically initiate a double-sided TWR exchange with the tag always listening tag(s). TDMA would be used to support multiple tags.
Anchors have no network access to each other or an external network
Tag would utilize parts of the 2-sided TWR exchange to calculate its distance to the anchor
Tag only needs the 1 range measurement of 1 anchor to triangulate its position
Given that the tag can know its distance to the anchor(s) over time that its within range of would be enough for my application. Tag would be recharged daily where as the anchors would be in harder to maintenance / feed-power-to locations. If anyone has advice on where to start software wise or if this is a bad idea in general i’m all ears.
This is the key to the system design. Without this feature, you need a complex timing protocol to have both sides power down and up at the right times to communicate. This is very hard to get started. With one side always on, that goes away and makes it much simpler.
This is where the complexity comes in if you support more than one tag.
The issue comes about when an anchor beacons and which tags should respond, and in what sequence. If each tag responds right after hearing the anchor, then they all collide and mess up their ranging. So there needs to be some coordination among the tags to decide who responds when to what anchor. This starts to get pretty hard if the tags are not necessarily in range of each other.
We developed a system like this for machine proximity. It works by having the anchors control which tags respond.
The initiator (what you call an anchor) sleeps most of the time but wakes up and sends out a query packet. The query packet explicitly addresses a list of responders (what you call tags). The query packet also contains an announce probability parameter which we will get into later.
The addressed responders answer back in a timed sequence based on their position in the list. At the end of the list is a probabilistic announce window. Any responder which was NOT addressed replies back in the announce slot with a probability given by the query packet.
At the end of this, the initiator sends back a final packet with the times necessary to compute two way range.
The over the air format is thus:
T1A A1 A2 A3 A4 PAW T1B
T1A: Packet from initiator to anchors, contains addressed list and announce probability
A1: Answer from responder first on list.
A2: Answer from responder second on list.
A3: Answer from responder third on list.
A4: Answer from responder fourth on list.
PAW: Probabilistic announce window where unaddressed responders can reply.
T1B: Second packet from initiator with timestamps for computing TWR.
In this way, the initiator can be in sleep, power up, perform the exchange, and go to sleep. This saves its batteries. The TWR timestamps allows computation of range to each initiator by each responder.
At the start, if their are no responders in range, the initiator packet is an empty list and a high probability. This is low power since the listen window is short, only one slot, which is what you want during periods of idleness. You can also back off the beacon rate when there are no responders around, further saving power.
As responders show up, they get added to the addressed list and the list grows. It can reach some max value (say 8) and then the initiator can start a second packet if it so wishes. If a responder fails to send for some amount of time, then it is dropped from the list. Responders are simple in that they only need to know if they are addressed, then answer back in the slot, or not, then roll the dice on the probability for the announce window.
An improvement is if the responders send back their distance to the initiator (remembered from a previous interaction) which helps the initiator make good decisions about who to keep in the list. Responders can also send hints like some value that this initiator has to their location geometry. In any case, the basic idea is that the initiator controls who it speaks to so that the responders don’t collide. The irony is that the low power side controls the protocol, but that’s the best way to save power and prevent collisions.
If there are a lot of new responders in an area, then the probability is dialed back for the announce window. This helps all responders get heard eventually. If it was set to 100%, then everybody will collide and nothing will get figured out. If set to 1%, it will take too long to find new responders. Somewhere in the 25% to 50% is a good value for running condition, 10% for a start up condition, depends on responder density. This can be dynamically adjusted based on network size and load.
That was a requirement for our system, no initiator to initiator coordination due to excessive range between them (they are on different machines which drive apart), and to keep initiator power usage low (they are on people).
When you add TDMA requirements, then it becomes really hard with dispersed anchors. How do you coordinate them for slotting?
The simplest approach to scheduling is an Aloha style system (periodic with random jitter to avoid synchronous collisions). Typically, you can get about 25% network load with such a system and it is simple to implement without requiring complex protocols and timing.
You didn’t say what update rate you need on your system, but assuming, say, 16 anchors and 16 tags, and tags have half the anchors in range, you are looking at an exchange taking about 2.5 ms. That’s 400 slots per second, or about 100 slots per second for a 25% Aloha load. With 16 anchors, that’s about 5 Hz max rate. Seems doable unless you need more speed, but then I question the 1 year battery goal, so I suspect a system closer to 1 Hz requirement than faster.
That all fits with what I described. The responders are the side that knows the ranges. With known initiator locations, a location can be computed using typical triangulation techniques.
Definitely not a bad idea, we’ve done it and it works pretty well.
I am not well versed in what can be done with publicly available software, but I don’t think what you want can be done with any of choices. You can send me email to discuss whether you would like to discuss how our system could be made available to you.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
what you are doing is very good support to newbies, i have seen several answers of yours in this forum, you are doing really good and i really appreciate it,
i have question with communication addressing method used in DW1000,i have tried searching my level best but not get much clear about it, as anchor and tag , for example as bluetooth and wi-fi devices have unique MAC address to differentiate from each other and using the same mac address they communicate with each other, so in DW1000 they have something like “node_id” and i dont know if that is what similar to mac id as bluetooth.
basically what i want to know is there a preinstalled any address? or we have to give address in firmware?
really appreciate your answer on this, thanks a lot,