[time-nuts] Distributed DDS
magnus at rubidium.dyndns.org
Mon Jan 31 17:38:01 UTC 2011
On 31/01/11 09:45, Javier Serrano wrote:
> On Sun, Jan 30, 2011 at 3:37 PM, Magnus Danielson<
> magnus at rubidium.dyndns.org> wrote:
>> 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.
> My naive view of the DDS would be a DDS core inside the FPGA and a DAC. In
> this simple scheme, a broadcast of the value of the states of the DDS core
> (including data out to the DAC) with an associated UTC time at with they
> should be applied would get everybody synchronized. This scheme is also
> robust wrt link failure, in the sense that things will go back to nominal
> once the link is re-established (you can't do better than that).
If your transmission includes phase, then you can achieve this. Doing
the DDS in a FPGA gives you a more transparent design as you can make
sure that phase-state transfer can be done.
I don't think time-stamping to UTC is very helpful. Concentrate on a
stable state sample-rate and means to align it to some common reference,
such as PPS. The other bits of the time-stamp doesn't bring in anything
you need. Within miliseconds all your nodes have the samples so it is
only a matter of ensuring they make their updates aligned. You would
only need a few bits of data to locate it in time.
Key point here is that this is a sample-series which is synchronous to
the 125 MHz clock being distributed and phase-aligned to the PPS using
the already established methods.
> As you say, broadcasting the complete state is the key, thanks for
> the tip.
You are welcome. I'm happy to see that you caught that ball, since it
was the most important one among my comments.
> Going from the FPGA solution, in which you have all freedom, to an
> AD9910 should be a matter of carefully studying the datasheet and
> coming up with a way of guaranteeing coherent states everywhere.
> I will look into it.
It would be possible, consider the control-loops that I proposed.
But also consider that maybe a FPGA-based solution may be a better match
for this particular problem.
More information about the time-nuts