Joe,
Joe Gwinn wrote:
Magnus,
At 1:00 AM +0000 7/26/09, [email protected] wrote:
Message: 4
Date: Sun, 26 Jul 2009 03:00:28 +0200
From: Magnus Danielson <[email protected]>
Subject: Re: [time-nuts] Measuring phase shift between 1 Hz DMTD
signals by I+Q processing
To: Discussion of precise time and frequency measurement
<[email protected]>
Joe Gwinn wrote:
Magnus,
At 4:01 PM +0000 7/25/09, [email protected] wrote:
It would be nice, but I need to think about this. I'm not sure that
you
don't have to use a real physical delay out in the analog hardware.
If you play the vector/phasor game you know that while you shift
frequency, you don't shift phase, so whatever phase-change you want to
apply to the carrier level (10 MHz) you can apply to the mixed down case.
I haven't had time to play the math gain, but I suspect that you are right.
You really should, as it is the basis for the DMTD to start with.
Let X(t) and Y(t) be the the first and second channel input signals to
the DMTD system. Let Z(t) be the transfer oscillator signal.
X(t) = A_x * exp(phi_x(t) + i*2*pi*f_x*t)
Y(t) = A_y * exp(phi_y(t) + i*2*pi*f_y*t)
Z(t) = A_z * exp(phi_z(t) + i*2*pi*f_z*t)
Now, we mix down to the beat signals U(t) and V(t)
U(t) = X(t) * Z(t)*
V(t) = Y(t) * Z(t)*
Notice that Z(t) is complex conjugate (i.e. imaginary term inverted) and
that exp(a)* = exp(-a) so...
U(t) = A_x * A_z * exp(phi_x(t) - phi_z(t) + i*2*pi*(f_x - f_z)*t)
V(t) = A_y * A_z * exp(phi_y(t) - phi_z(t) + i*2*pi*(f_y - f_z)*t)
If f_x and f_y is close in frequency and f_z is selected to be close,
the f_x - f_z can be made a low frequency. Notice how the phase remains
unchanged, but if we convert phase into time for the two systems, a
degree of phase would take a considerable amount of time in the beat
note, which is the gain of the beat frequency method.
Now, to cancel the transfer oscillator we do
W(t) = U(t) * V(t)*
W(t) = A_x * A_y * A_z^2 * exp(phi_x(t) - phi_y(t) + i*2*pi*(f_x - f_y)*t)
Thus only the amplitude remains of the transfer oscillator (and thus
amplitude noise).
If the last correlation is done with TI-counter, then part of the
transfer oscillator phase noise will fail to cancel properly.
Recall, the problem with not full cancelation of the transfer oscillator
is due to the time-difference of the beat notes and that the ZCD
detectors by design adapts to what it percieves to be 0 degree and that
the the time occurence of this is different between the two beat note
channels.
Now, if we phase shift at the beat note frequency we can make that
channels beat-note time occurance in the ZCD to be come arbitrarilly
shifted and thus close the time-difference considerably until they occur
too close in which case we get unwanted degradation due to cross-talk.
Phase-shifting at the carrier frequency is just to achieve the same
thing, infact that is doing it one step away from where it is expected
to occur. If we do this in stable digital domain, there is less
stability issues.
It should be noted that such shifting needs to be continously monitored
and adjusted as the carrier frequencies drift appart. Any adjustments
needs to be compensated or otherwise phase-steps will be introduced into
the datastream. A carefull correction actually compensate for both gain
and phase shifts.
I would set up a tracking loop to keep the two 1 Hz signals coincident,
and the loop implementation would report how much shift war required to
achieve this coincidence.
Exactly.
>> The postprocessing would then slowly tune the I/Q phase and keep a
phase
adjustment track such that post-correlation could turn it back for
proper phase-trace.
But, unlike ZCD-triggered counters, there is no disadvantage or
difficulty if the phase difference is adjusted exactly to zero, where
the two 1 Hz sinewaves coincide.
Depends on your post-processing. If you attempt to emulate ZCD in
firmware, then you get that result. If you rather do the
phase-subtraction processing no phase-shifting is needed as it is done
sample-for-sample and the issue is gone and you have a clear
phase-difference record that builds.
Yes.
>> An alternative approach is to use the Costas tracking loop as Bruce
suggested.
A Costas loop is far more complex, but they do work well. Given near
constant phase delay, don't know if a Costas loop is worth the trouble.
The Costas loop will not by itself solve the problem of
transfer-oscillator noise.
Costas loops isn't that expensive these days, rather they are hidden
away in all kinds of places. If you do that processing in digital
domain, you can with proper pre-staging even do advanced phase
detectors such as arctan(y/x) in real time and get away with it.
Yes. My reaction to Costas Loops is simply that they may be overkill
for this application, and will no doubt bring their own set of issues to
be solved. But it's a tradeoff for sure.
Nothing we can't handle.
>> Regardless this first stage of digital processing can be done in a
FPGA
frontend and bring the resulting signal bandwidth into very reasonable
rates, just as for a GPS receiver.
Yes. Is 0.01 Hz slow enough?
That is probably too slow actually.
How fast will the phase offset between 1 Hz signals change? I was
thinking of a 100-second loop constant, but 10 seconds would also work.
Need to think about it.
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.
