Hi, in the double-sided example code given on the github repo, after the exchange is completed, the distance value is calculated on the Responder-side. Is it possible to get the distance on the initiator side, like ss-twr, but with the accuracy of double sided? Like send an additional packet containing range info back to initiator, or even send another message with timestamp info to get a more accurate range? Essentially, I just want the initiator to receive a range measurement.
Yes.
A simple way is to send a fourth packet with the answer back to the initiator. Then both sides know what the 3 packet DS-TWR results are.
A more elegant way is to ping pong packets between two nodes and then take the data from the last three packets and compute distance. Once this gets started, each time a node receives a packet, it can compute a new distance from the other node.
To illustrate:
Packet 1: A to B
Packet 2: B to A
Packet 3: A to B
B can now compute distance A to B using packets 1-3. This is normal DS-TWR.
Packet 4: B to A
A can now compute distance B to A using packets 2-4. This is DS-TWR using a different set of 3 packets that A knows.
Packet 5: A to B
B can now compute distance A to B using packets 3-5. Note the reuse of packet 3.
Packet 6: B to A
A can now compute distance B to A using packets 4-6. Note the reuse of packet 4.
And so on. As each packet is sent, a new distance value can be computed by the receiving node. Each packet has to contain at least the TX node ID, the TX_TIME, the RX node ID, the RX_TIME. If you are doing ranging to more than one node, the packet can contain an array of (RX node ID, RX_TIME) values and you can compute the set of distances.
The big negative to the ping pong method is that the DW1000 high speed clock, specifically SYS_TIME, has to be kept running between packets (IDLE state or higher, no INIT, SLEEP, or DEEPSLEEP states). This limits the power savings possible in such a system as IDLE is about 50 mW. If the nodes don’t run on battery, not a problem. But if they do, and the battery is small, you probably can’t do ping pong DS-TWR.
As an aside, I have suggested to Decawave there be a 38.4 MHz counter than can be left operating all the time, even during some sort of near SLEEP mode (SNOOZE? It would probably be under 5 mW). Once you wake up, the counter value can then be used to compute a SYS_TIME accurate interval without having it operating since SYS_TIME is mathematically locked to the 38.4 MHz clock. This gets you precise timing and low power intervals. Alas, this does not yet exist.
The first method, the fourth packet answer back, does take more air time, but once the fourth packet is sent, both sides can then power down until the next interval, saving battery The fourth packet can contain the computed answer, or better yet, the initiator can form its own set of 3 packets to compute range (packets 2-4) and then that can be averaged with the packets 1-3 results being reported by the responder. This means the initiator gets a more accurate answer, which often suits the application.
Hope this was helpful and not too confusing.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
1 Like