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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
