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