After almost two weeks of doing other stuff I have finally got back to looking at TS. Today I took a cursory look at the DecaWave code. It certainly looks daunting.
The good news is that they have a carefully worked, and documented example of the ranging process. The bad news is that it looks very complicated, and I fear for the ARM M0.
The thing I am trying to figure out right now is whether it is how easy it is to change role from tag to anchor. It’s almost a requirement for our architecture to be able to do that dynamically, but I fear the power-overhead of doing that might be large.
I started reading the Source Code Guide. I found a couple of very interesting paragraphs.
- In a microprocessor system the TRSP time is best reduced to complete the ranging as quickly as possible. This improves the accuracy of the result as it minimises the difference in TRSP due to the different local clock rates at each end. A time should be chosen that is a little greater than the worst case response latency possible, so that the command to do a delayed TX is not issued after that time has gone past, which would essentially delay TX until the sys clock wraps around to the specified TXtime again. A status bit is provided to warn of this “delayed TX more than half a clock period away” event indicating the TX start was late. If this late error occurs frequently then it would probably be a good idea to use a longer delay, but if this was a very rare event it may be better to keep the specified period and just recover from the error when it occurs. This is a system design choice.
- Where two peer mobile devices are ranging between each other (e.g. in a separation alarm say) then for battery conservation it is not practical for either device to have to listen for long periods. Therefore the devices have to operate in a more synchronised fashion, turning on the receiver only when the message from the peer device is expected, (i.e. long enough before the expected message and for a period long enough to detect it, given the maximum possible timing drifts between the two devices clocks). In such a scheme initial pairing will probably be initiated by some manual means like coordinated button pressing on both devices, or perhaps by employing low-powered listening, a technique that samples for preamble occasionally (e.g. once per second) looking for a wakeup sequence sent for the whole second.