[time-nuts] Distributed DDS

[Magnus Danielson]

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.

Cheers,
Magnus