Need some guidance on this as what will be a best practice
System requirement:
tracking 3000 items in a confined large area, near real time location of the item ( 1Hz is good enough, or maybe even slower update rate).
a couple of design questions
can 1 anchor track hundreds of tags assuming slow update rate is okay.
do I need to use TWR in this case ? since tags does not need to know how far it is to the anchor, but anchor need to know the distance to the tag
anchor may need to send message to the tag from time to time (simple/short msg). can the tag still receive message if it is in 1hz or even 0.1hz update mode ? (tag has dwm3000 + a mcu, mcu is sleeping most of the time, but wake up by DW3000 when dw3000 receive a msg , so it can process the msg). can this be done ?
in this case, can I just set the tag in receiver mode, and every 1seconds , dwm3000 will check with nearby anchor to see if there is any msg, and let the anchor measure the distance to the tag ?
For that sort of system a TDoA approach is generally better. That then only requires a single short packet from the tag and the tag never needs to go into receive mode.
Less transmissions per tag means you can run more tags and gives you a better tag battery life. The down side is the in building infrastructure is more complex but when you’re talking at most a dozen anchors Vs 3000 tags that’s where you want the complexity.
Getting the tag to pick up a message is a little harder assuming you want to minimise it’s power usage. But you could make it listen at a very low duty cycle and have it include when it’ll next be listening and when it last received something as part of it’s message, that way the system will know when to transmit for maximum change of reception and get confirmation so that it knows it doesn’t need to try transmitting again.
Hi @zjustin06
I would like to add that the TDOA/TWR approach heavily depends on area type. Like for open halls the TDOA can be better for a such big quantity. But if it is like hospital - tons of rooms then TWR will provide much better performance. As there are many rooms then you will have only limited amount of nodes on one place.
I would also expect that those 3000 nodes are on in the same spot but they are spread across the factory so you need to figure out on how many nodes can be in one area.
For example in PANS you can have 15 nodes at 10Hz in one area or 150 nodes in one area with 1Hz update and so on.
there is less restrictions on the number of anchors, I am planning to have about 20-40 anchors (more can be done if needed). what’s the potential power consumption difference in TDoA vs TWR ? (TDoA : TWR = 1:2 approximately ?) I can slow down the update to 1hz or less if needed.
in TDoA, can I set it the tag wake up at 1hz rate to send a msg, then wait for x period to see if there is a response ? or it will be just send and forget ?
in TWR, can the tag only trigger the interrupt to wake up MCU when there is additional payload from the anchor ? or it will trigger the interrupt at even just receiving the standard TWR msg ? I am trying to avoid waking up the entire device unless there is a real msg to the tag, but not at every TWR process .
yes the 3000 tags are spread out in a large confined area, but there could be cases that 200-300 are in the same anchor coverage area. The area is mostly open, but there are some walls/pillar or even stacked racks which can be blocking some signals. TDoA is probably workable for this, but I am more concerned about the communication, as mentioned in the other reply, my tag need to receive a trigger msg from time to time to wake up MCU to perform certain actions.
You can perform a single sided TWR with a single transmit and receive per device. This could be initiated by either the tag or the anchor. But that will give you a single range. If you play some games with the radio protocol you can measure n ranges with n+1 radio transmissions plus maybe some data message (one from the tag and one from each anchor and then something (UWB or other radio) to get the results back from the tag).
For TDoA you need a single transmission from the tag to measure the range to all anchors in sight. So same number of transmissions for the tag but far less total transmissions which means far less time per tag and so a higher overall update rate is possible.
In terms of power draw receiving is higher power than transmitting (at least it was on the DW1000, I haven’t double checked the DW3000). The chip supports optional receive timeout and auto acknowledgment mode which will automatically arm the receiver after a transmission and then disable it again after a fixed time if nothing is received.
The application notes include information about how to implement low duty cycle listening systems but you may be able to improve upon that if you can control when you know you may need to listen. If you can design your radio protocol to keep the receiver off as much as possible and only listen at known times then that will help.
There are hardware filters that in theory would allow you to filter out packets addressed to other devices without waking the CPU. I’ve never used them and so can’t comment on how beneficial these could be. But to be honest if the chip is in receive mode a lot of the time then the power saved by putting the processor to sleep until an interrupt occurs probably isn’t too important.