This works
clock source -> N way splitter -> cable A -> iADC input A
-> cable B -> iADC input B
Cables A and B must have the same electrical delay for the clock
signal to be distributed.
This is pretty easy to do if use same cable type and physical
length and routing (bends and such) for each of the different
ADC clock inputs.
RG-174U can be used (when complete set) but it is pretty low end cable.
Times Microwave LMR-100A is pretty nice cable.
better by ~ 12dB/100ft @ 1 GHz
better shielding
100% vas 88%
and spec > 90dB vs not specified.
etc.
Not blessed; just advised.
On Thu, 4 Mar 2010, David MacMahon wrote:
Thanks, Matt,
Just to be clear, if a different observatory used RG-174U only then could
this same problem be caused by some mistakenly installed Times Microwave
LMR-100A?
I wouldn't want the take away from this thread to be that one kind of cable
is "evil" and another kind of cable is "blessed" (unless that is in fact
true).
Thanks again,
Dave
On Mar 4, 2010, at 15:52 , Matt Dexter wrote:
yes it was 2 cable types.
we use Times Microwave LMR-100A only.
The problem Billy found and fixed was due to some mistakenly
installed RG-174U.
(see the same email discussion of 2007jul18)
On Thu, 4 Mar 2010, David MacMahon wrote:
Hi, Jason,
On Mar 4, 2010, at 14:32 , Jason Manley wrote:
On 04 Mar 2010, at 13:49, Dan Werthimer wrote:
the code resets one of the adc's until the two adc clocks are lined up
in phase.
For future reference, this code gives up trying to sync after a while. I
can demonstrate systems where it doesn't succeed before the timeout and
then gives up. It occurs at PAPER-GB8 regularly.
We've seen this problem at the ATA, too. In our case it turned out to be
due to differences in the ADC clock cables, but not physical length so
much as cable materials (presumably resulting is propagation delay or
phase differences). It turns out that the "phase alignment test" in the
ibob software imposes a fairly stringent requirement on the phase
alignment of the two ADC input clocks. Here's an excerpt from a 2.5 year
old message about this (from the ATA where Fs is 838.8608 MHz)...
On Jul 18, 2007, at 0:09 , David MacMahon wrote:
Here are the details on the ADC clock phase-up process ("Fs" is sampling
frequency, i.e. 100*2^23 Hz == 838.8608 MHz)...
The adc initialization software measures the relative phase of the two
incoming clocks (Fs/4). This is a rather complicated process that I
would rather not explain the inner working of here. Apparently this
measurement is made with +/- 5% precision. If the measured relative
phase is greater/less than +/- 20 degrees (at the FPGA clock frequency,
Fs/4), then the clocks are deemed to be "out of phase", the ADCs are
reset, and the measurement process starts again. If the two clocks are
never deemed to be "in phase", i.e. within +/- 21 degrees (20 degrees
plus 5% == 21 degrees) after 50 attempts, the software finally gives up.
20 degrees at Fs/4 is 80 degrees at Fs, so if the two ADC clocks are more
than 80 degrees (at Fs) apart (give or take a few degrees), then I think
they will never "phase up". 80 degrees at Fs is only 265 ps!
The problem at the ATA was tracked down by Billy Barrott...
On Jul 18, 2007, at 14:03 , William Barott wrote:
I have traced the problem to the cables themselves. Three different
stocks of cables were used in the construction of the RFCB 800 MHz clock
feed lines: The bulk is LMR-100A from the same spool. We also have
"RG-174U" and "High-Quality RG-174A/U."
The RG-174A/U (1 found in system) measures about 35 degrees out of phase
with the LMR-100A.
The RG-174/U (4 found in system) measures about 110 degrees out of phase
with the LMR-100A. It was these RG-174/U cables that were associated
with wildly-off phases and non-syncing iBobs in both chassis.
In another message, Billy reported that all these cables were length
matched to within 1 cm. I believe (but am not 100% sure) that the problem
was using mismatched cable types for an ibob's two ADC clocks rather than
one cable type being unusable.
Back to the present...
On Mar 4, 2010, at 14:32 , Jason Manley wrote:
I think Paul's on the right track: since you cannot calibrate off the
sky, injecting a reference for the calibration is their most reliable
option.
Agreed.
Dave
