Hello
Can you recommend a suitable off-the-shelf module for using as a TDoA anchor? I would like to avoid designing a board for the DW1000 IC and what I need is a module with exposed clock and sync pins for external synchronization.
Thanks
To my knowledge, there are no commercially available DW1000 based modules which expose the clock pins. They all contain a 38.4 MHz crystal and don’t pin out the XTAL pins. Without exposed XTAL pins, the SYNC pin has no viable use.
You have two options:
Design your own board or module which takes in an external clock and SYNC signal. That is what we did for our modules used in our products but they aren’t available for general sale. The reason we did this is to enable building antenna arrays for phase measurements to give precise angle of arrival.
Or
Use modeling of the various clocks to mathematically synchronize them to a common time. That is what we do with our MultiTime (TDoA like) algorithm for our anchors since distributing a central clock is not feasible for general applications. This is a complex distributed algorithm that will never be as precise as hardware sync.
Providing an external clock to the DW1000 chip is a bit tricky to do well, but if you get it right, you can keep multiple DW1000 chips sync’ed up to ridiculously small time margins. In our phased array antenna setups, we are measuring phase differences to a standard deviation of 1.3 ps, which is 0.4 mm at the speed of light, or 4 sheets of office paper thickness. Measuring the speed of light across a few thickness of paper is just crazy precise. The DW1000 is an amazing chip.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
1 Like
I don’t want to hijack this topic, but I’m currently in the process of deciding whether I really need a distributed central clock or whether a solution like your MultiTime would be usable.
What kind of precision can one expect from a well-executed MultiTime like algorithm?
Electrically distributing a common clock to multiple nodes is a major challenge and should be avoided if possible. Even if you get it to work electrically, the fact you are sending a pure clock signal around creates EMC issues. At some network size, it simply doesn’t scale any more as well. You still have to compensate for an offset between nodes due to delay in sending the clock to each node. A tricky issue here is that cables vary in electrical delay with temperature and other affects so this offset is not a one time calibration.
Each node having its own independent clock source is much easier electrically, but much more complex mathematically. A side benefit is that such modeling can also correct for variations in antenna delay at each node since that is modeled out as an offset, and it can track temperature changes if they occur slowly enough.
That depends almost entirely on the stability of the local clock sources at each node.
If those clock sources are perfectly stable, that is, they don’t drift in frequency, then the mathematical clock modeling can be essentially perfect. The stability depends not only on the clock itself but also the environment around it such as temperature, voltage, and nearby electrical noise.
Doing this work, we have learned a lot about TCXOs and found some ugly behavior in some of them. Here’s a good paper on those subtle issues, particularly “micro jumps”:
In one notable case, we had a TCXO that, at a certain temperature, would jump 7 Hz, go from say 38,400,000 Hz to 38,400,007 Hz. That’s only 0.18 ppm change, so within “spec” for the TCXO, but that jump made that anchor node go way off in timing (180 ppm off in 1 second is 60 meters, clearly a problem). We added code to our synchronizing algorithm to specifically detect when this occurs and map out anchors that have this happen until they settle back down again. Fortunately, this issue seems to have affected only a particular batch of a particular brand of TCXOs, so it isn’t common and most TCXOs behave better.
Our MultiTime network typically operates on a 10 Hz cadence, that is, each anchor emits a packet every 100 ms. The exact local time it is transmitted at the anchor and the exact local times it is received at neighboring anchors is then put through a modeling algorithm to create slope and offset numbers for each node to some common idea of time. At 10 Hz, with commodity grade TCXOs, and good design, we are tracking time to well within 100 ps, or about 30 mm of distance at each anchor. When a tag beacon arrives at an array of anchors, they can all precisely time that arrival in their local time domain (that’s the job of the Decawave chip) and then we can mathematically transform that into a common network time (that’s the job of our algorithm). Once everything is in a common time, we can then run the location algorithm based on those arrival times.
The most stable local clocks are OCXO (oven controlled crystal oscillator). They heat the crystal to a fixed temperature so it remains at a stable frequency. Most commercially viable UWB systems can’t afford the cost, size, or power of an OCXO, however.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
1 Like
Thank you for the extensive answer! It then seems best for us not to use a distributed central clock.
I had indeed read about your findings with TCXO’s in a previous forum post, really interesting stuff. (Altough I’m glad I wasn’t the one having to hunt down that glitch.)
I might be overreaching, but would you mind sharing which TCXO model (or brand?) is to be avoided (or which are to be used)?
It was 3 years ago, a certain batch of TXC 7Q series had this issue. Not all had this issue, and if you are doing ranging, you would never notice the issue because it would affect at most one range and then only if the shift occurred in the middle of ranging, which would be rare. It was only with TDoA style system were clock modeling is used for each anchor did the problem manifest itself, and that affects all tags heard by that anchor for a while.
In discussions with their engineers, it appears to have been a calibration glitch during manufacture. The way modern TCXOs work is that they contain a calibration table that converts temperature to a pull voltage via a factory programmed memory array. Apparently, the process of doing that had a glitch and there was occasionally one bad entry at one particular temperature.
We’ve never seen this issue on TXC 7Z parts, nor on any other TCXOs (but we have not tried them all necessarily). TXC 7Z parts are what we currently use in production.
The TCXO we’d prefer to use is the Epson TG2016 series as they have great specs, low power, fast starting, and Epson makes quality parts. But Epson seems to have an availability problem and we have a hard time getting them.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
1 Like
Thanks for the background information and for sharing your preferences when it comes to TXCO’s.
I’ll definitely keep it in mind if we are to once venture into the TXCO territory.