Would it be possible to implement this scheme using the DWM1000 (instead of starting with the DW1000 from scratch)? In other words, could I bypass the DWM1000 clock and drive the EXTCLK pin on the DW1000 (pin 3 on the DW1000 in the DWM1000) with my own clock signal AND could I also use the SYNC pin (pin 4 on the DWM1000)?
None of the Decawave modules, DWM1000, DWM1001, DWM1004, pin out the 38.4 MHz clock signal. They all have on module crystals whose signals are not available on the module pins.
To do what you want, you would have to electrically modify the modules to tap into the XTAL1 pin and remove the crystal. Further, you would have to find a way to isolate VDDBATT due to a noise issue when using external clock signals.
In brief, there’s no practical way to use the DWM modules to do what you want. Providing an external clock to a DW1000 is not for the faint of heart, either, many ways for that to go badly.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
I thought this might be the case. Is there anything serious I should know about externally clocking the DW1000 chips? We are following the link in the original post closely.
We will be transmitting to anchors that are roughly 2 metres from a central clock unit using cat5e. We will be using diff amps for noise and jitter cleaners for any clock jitter introduced.
Yes, there are a lot of subtle ways to get it wrong. You can very easily make what looks like a circuit that should work and it doesn’t. Any sort of noise or jitter in the clock edges causes problems with the DW1000. The best way to detect this is to observe the transmit spectrum when you put the DW1000 into CW mode. You should get a sharp peak at carrier and spurs should be at least 15 dB down, preferably 20 dB. You will see spurs at +/- 38.4 MHz from carrier, and also +/- your power supply frequencies. As long as those aren’t too big, things work.
That may work. I would be careful with the jitter “cleaners” since that implies a PLL of some sort and that PLL can introduce phase noise that the DW1000 can’t handle. What part are you considering for that purpose?
Considering the short distance, you might consider using coax cable for the clock instead of network cable.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
We’re following the document in the original post closely. This document suggested the Si5317 jitter cleaner (https://www.silabs.com/documents/public/data-sheets/Si5317.pdf). We were considering using cat5e as this would allow us to use differential signalling to mitigate any extra noise. Would coax be a better alternative?
Everything you introduce between the clock source and the DW1000 is a potential source of error. This error can manifest itself in jitter, noise, and delay variation.
The Si5317, for example, has a phase noise rating of -106 dB/Hz at 1 KHz offset, the DW1000 specifies -132 dB/Hz at 1 KHz offset as the minimum spec. Now the Si5317 spec is at 622 MHz versus 38.4 MHz, but even considering that, the part doesn’t appear to meet the DW1000 datasheet target. This may manifest itself as error in your measurements.
You should also be aware that everything in the clock signal path can introduce delay variation with temperature. The Si5317 spec is 500 ps variation over its temperature range, which is 15 cm of error potentially introduced. Note that the Si5317 operates at significant power, so self heating will be present, meaning there is at least some sort of start up delay variation until thermal equilibrium is achieved. This means your system may have errors on startup until it has been operating for a while.
The temperature issue affects the cable. As temperature changes, the cable delay changes due to change in conductor spacing, change in insulation dielectric, and changes in length. These changes can be significant. Twisted pair cable seems more sensitive to this than good coax in our experience. Flexing of the cable also introduces delay changes as well.
I’ve observed a number of projects try to use a distributed clock and it has always been troublesome. Be very diligent in your design and be prepared to debug the clock stability. Trying to achieve picosecond level cable synchronization is quite hard.
The best way to distribute precise time to spatially separated nodes is by sending a UWB packet to all of them from a common source and then mathematically modeling the clock errors to the node’s local clocks. This method corrects for all sorts of errors a clock cable system can’t, including antenna delay variation with temperature. It does require the extra node to transmit periodic time packets, and it requires some mathematical coding to get right, so not a trivial exercise to accomplish.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
Thanks for the advice, we’ll take this on board. We’ve found a number of fan-out buffers that meet the amplitude, phase noise, and output to output skew requirements of the system. We have decided to use coax over cat5e.
Though we are still struggling to find a jitter cleaner (for the receiving end) that meets the phase noise requirement. The Si5317 itself is from the Decawave document itself so its strange this doesn’t meet requirements when it is what they have successfully used and recommended.
Is a jitter cleaner on the receiving end even necessary?
Further, for the input to the SYNC pin, we believe we can use a similar clock buffer with an input from a central raspberry pi GPIO pin that will send a pulse (through coax again) to the 4 anchors when needed. Would it be a good idea to also use a jitter cleaner for this pulse on the receiving end? Also, since this pulse is asynchronous to the 38.4MHz central clock, we understand that the pulse width should be large enough to account for any unlucky sync timing issues (the pulse not landing on a rising edge or without sufficient setup/hold times). How long should we aim to make this pulse?
For a well design system, I don’t believe so. Quality coax and connectors shouldn’t need it. The APS007 document uses the Si5317 mostly to recover signal amplitude lost in cable attenuation. Given your short cables, that’s likely not an issue for you.
Also, consider the PL133 buffer for something that can take in a lower amplitude clock and create a clean logic level clock. I suggest operating it at 1.8 volts since over driving the XTAL1 input can cause problems and 3.3 volts is a bit too strong. The PL133 is not a jitter cleaner with a PLL inside, but a precise clock buffer which adds very little jitter. Vastly lower cost and power than the Si5317, too.
Match cable lengths to minimize cable induced errors, such as delay variation with temperature. Use identical cables for each connection (same brand, part number, even from same spool if you can).
Jitter cleaners can’t work on single pulses, they can only work on steady clock signals.
The SYNC pulse must be synchronized to the 38.4 MHz clock for it to work. If it isn’t, then each device might synchronize to a different 38.4 MHz pulse edge. This leads to devices being perhaps 26 ns different in timing if they vary in setup and hold time tolerances. To solve this issue, you need a means to retime the SYNC pulse to the 38.4 MHz clock.
Note that the setup and hold times Decawave specifies for SYNC are quite difficult to assure in actual practice. See Figure 9 and Table 3 in APS007. They specify 10 ns setup and 10 ns hold, which is 20 ns out of a 26 ns period. So you have only a 6 ns window in which to change SYNC state. Building a retiming circuit which actually assures hitting the 6 ns change window 10 ns after the clock edge is ridiculously hard when considering part, temperature, and voltage variations, so the SYNC pin timing requirements basically make using it impractical if you actually want to meet specified timing.
We have built such circuits and here is an example:
SYNC-CLK is 38.4 MHz. DW-SYNC is a GPIO from the processor, which goes through a 3 stage retiming to avoid metastability. U2 then picks out the leading edge and that gets distributed to multiple DW1000 via one more flop stage. R6 and C2 are a tunable RC delay to adjust the SYNC edge to, as much as possible, fall inside the 6 ns window Decawave requires. Even with that, we can’t assure the timing is meet over all variations, but operationally, it works. Basically tune RC until the SYNC pulse edges fall in the center of the 6 ns window and call it good. We are convinced the Decawave setup and hold numbers are gratuitously large and could be specified with tighter numbers.
We have built systems with asynchronous SYNC pulse (GPIO from microcontroller like you describe, no retiming circuit). In those cases, you optimistically toggle the SYNC line, and then you check the devices all used the same edge (for example, by all devices hearing the same packet and checking no device is ~26 ns off). If the devices are askew, which happens about less than 5% of the time in our experience with asynchronous SYNC, then you simply repeat the SYNC pulse until all device did use the same edge. This is a once per startup issue, so not an operational problem once accomplished. It is best if the GPIO source (Pi or MCU) is not using a 38.4 MHz clock of any kind since you could get stuck in a loop where you constantly fail timing over and over again. This is usually not a problem in practice.
Consider not using SYNC at all. Since all nodes are within a small radius of each other, they are less than one clock cycle at 38.4 MHz apart at the speed of light, so you can tell what the offset is between any two nodes and mathematically correct for that. This is what we do for any common clock designs we make now since that is less hardware complexity. There’s no operational advantage to having nodes match exactly on the upper bits of SYS_TIME if they are locked on the 38.4 MHz clock edges. Every 38.4 MHz clock is 1664 SYS_TIME ticks (1664 = 13 * 128).
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
