[time-nuts] Distributed DDS

[Magnus Danielson]

On 27/01/11 11:15, Javier Serrano wrote:
> Dear nuts,
>
> Triggered by Ulrich's very interesting thread on nasty DDS features, I would
> like to submit for comments an idea for an application of DDS technology
> which hopefully does not suffer from them. We have a need at CERN to
> distribute RF signals (those used for driving particle-accelerating
> cavities) over long distances (several km) in a phase-compensated way. We
> can already have a phase-compensated fixed 125 MHz clock everywhere thanks
> to the White Rabbit (WR) network (see
> http://www.ohwr.org/projects/white-rabbit/wiki). The nodes in the WR network
> will be made with FMC carrier boards in several formats, e.g. this PCIe card
> with on-board DDS and PLL chips:
> http://www.ohwr.org/projects/fmc-pci-carrier/wiki. The idea to transmit an
> arbitrary RF signal from one node to another is the following:
>
> - Feed the reference RF to one of the nodes (equipped with a suitable
> interfacing FMC) and have the DDS take the place of the usual VCO in a PLL
> configuration, i.e. have the DDS track the incoming RF signal by suitably
> modifying its control word in real time. Of course, the RF must be a
> relatively stable signal. In this configuration I expect to have the low
> frequency noise of the RF reference at the output of this PLL, not the
> artifacts described in the nasty DDS features thread. The DDS is clocked
> with the WR 125 MHz clock or a clock derived from it. All WR nodes have easy
> access to this clock.

I assume that we can treat the 125 MHz clock as essentially being the 
same clock, with the variations in delay mostly compensated and 
variation in added jitter which was not suppressed.

I assume that a PPS was generated out of it in a similarly 
delay-compensated maner.

> - Time-tag all correction words sent to the DDS in this "PLL node" with a
> good WR UTC tag.
>
> - Broadcast these correction words with their associated UTC tags to all
> interested nodes, with enough time in advance so that everybody gets them by
> some suitable UTC "execution time". Typical delays through a WR network are
> in the 10-100 us area and upper-bounded so one can do worst-case design.
>
> - Have all receiving nodes replay these control words at the same UTC times
> everywhere.

Rationalize this by creating a stable sample-rate (say 1 kHz) for which 
these corrections is being sent. The correction packet is real-time 
traffic so why not take the full blow?

You want the DDS states to be synchronised in a similar fashion, or else 
the DDS artifacts will have arbitrary offsets. You should be able to 
bring those time-offsets to within the PPS errors.

> This Distributed DDS (D3S) scheme should result in good (as good as the
> UTC-distribution capabilities of WR) RF signal re-generation everywhere,
> with a constant delay with respect to the original signal which is not a
> problem for us. It also has the potential of sending more than one RF signal
> through the same link quite naturally. As this is a new application for us,
> I was wondering if some among you have been confronted with such problems in
> the past or have tried to do something similar to this D3S idea.

I think that a key difference between this system and many others is 
that the transported RF frequency is not sourced from within the system 
and its internal clock. This is actually not far from what telecom 
systems needs to do for user signals, but they do not require quite the 
same characteristics, but overall it is common that you convert the 
difference in phase/frequency of the user clock vs. system clock into 
some form of difference-stream and transport that. For instance the SDH 
system uses a mechanism called pointer justification which handles the 
phase difference and adjust the pointer to where in the stream the 
signal starts. The SDH pointer system is a very clumsy system but 
achieves part of the goal.

Doing what you proposes with timely updates of DDS frequency as comes 
out of a PLL loop will work nicely if only the phase is coordinated. 
However, what happens if a node or number of nodes experience a short 
break? They will be phase-shifted so phase-alignment will be lost.
This is the danger of frequency updates only. You need to figure out a 
method to overcome that, and one is to provide phase-difference to the 
PPS (or a higher rate clock to reduce time) such that phase may be 
restored with a local control-loop which makes local tweaks to overcome 
local errors.

You need to understand the error conditions and how to mitigate them.

Cheers,
Magnus