As delivered the ranging system operates at 100kbps. Presumably that’s the symbol rate. At the other end of the scale it works at 6.8Mbps. I tried both speeds and it seems like the effective range is a little longer at the slower data rate.
The ranging protocol relies upon the peers taking a known, and fixed amount of time to respond to a ranging request. The code indicates that this is 150ms! Unless the peers can sleep, that’s a long time to have to remain awake every range event. When the EVB1000 is connected to a PC, the turnaround time is set to 750ms! Yup 3/4 second. Since there are two fixed period turnarounds, the total ranging time is in excess of 1.5s.
Fortunately, a feature of the DW chip is it’s ability to schedule transmissions, and receptions for some time in the future, and to sleep while waiting (or is it to let the processor sleep while it waits?) Without that, I reckon the power budget would be horrendous. Nevertheless, it means that to perform the four one-shot range operations required to locate yourself in 3D, it would take 150*2*4 ms = 1.2 seconds. A moving person could travel 6-10 feet in that time, so there would be a much higher probability of trying to do trilateration (is it really quadlateration) with a degenerate set of coordinates. (i.e. the ranges don’t intersect, so can’t specify an area, let alone a single point). My experiments so far, show that one-shot ranges are way off, and that it isn’t until the second try that it get’s reasonable.
The DW code claims to have some options to allow “fast ranging”. I think they are assuming that the two peers are using identical processors and software, and that the turnaround delay is proportional to the time it takes to transmit the ranging packet.
The question they are trying to answer is, “If radio A sends a ranging packet to radio B, how briefly can radio A sleep for before expecting to hear back from radio B”. This is puzzling. Radio A must stay awake until the last bit of the packet is sent. Assuming that the processor attached to radio B takes minimal time to turn the packet round and have the radio send it out, then why would radio A need to sleep for more than a trice before it has to wake up to catch the first bits of the return packet. This doesn’t seem like a big win.
Of course they might be trying to let processor A sleep as soon as it has handed over it’s packet to the DW, and not be awoken until the return packet has been received. In that case the delay until being awoken should be about the time it takes to send two ranging packets.
Looking through the code it appears they try to calculate the minimum fixed delay time based on the time it takes transmit a range packet. I don’t understand the calculations, but they have parameters that measure the length of the fixed, and variable parts of a ranging packet under different transmission modes. At 110Kbps the delay appears to be much longer than at 6.8Mbps, but doing their math in my head doesn’t produce the result I expect. There are a bunch of fudge factors, and these seem to be significant.
Anyhow, the final calculation seems to result in a number that is less than 600us which is more appetizing. With that you could quadlaterate in < 5ms (200Hz) which is very respectable. Of course there are actual legal restrictions on how much UWB traffic you put into the ether, so there may be other limitations.
However, and much more importantly, I can’t get the “fast ranging” to work. Comments in the code indicate that it only works at 6.8Mb, but all my attempts to configure it as suggested fail, and the two nodes can’t find each other.