DWM1000 Sync Pin and EXTCLK Access

I am currently looking at building a TDoA system that has wired synchronisation between anchors (from https://www.decawave.com/wp-content/uploads/2018/10/APS007_Wired-Sync-RTLS-With-The-DW1000_v1.10.pdf).

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
[email protected]
+1 812 962 9408

Thanks for the response, I’ll take those points into account.

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
[email protected]
+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
[email protected]
+1 812 962 9408