Re: [time-nuts] Measuring phase shift between 1 Hz DMTD signals by I+Q processing
Magnus,
At 1:00 AM +0000 7/26/09, time-nuts-request@febo.com wrote:
Message: 4
Date: Sun, 26 Jul 2009 03:00:28 +0200
From: Magnus Danielson magnus@rubidium.dyndns.org
Subject: Re: [time-nuts] Measuring phase shift between 1 Hz DMTD
signals by I+Q processing
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Joe Gwinn wrote:
Magnus,
At 4:01 PM +0000 7/25/09, time-nuts-request@febo.com wrote:
Message: 5
Date: Sat, 25 Jul 2009 16:38:23 +0200
From: Magnus Danielson magnus@rubidium.dyndns.org
Subject: Re: [time-nuts] Measuring phase shift between 1 Hz DMTD
signals by I+Q processing
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Joe Gwinn wrote:
It occurs to me that there is a possible alternative to the ZCD-chain
approach typical in DMTDs, if one is willing to provide two mixers and
two ADCs per channel, with a 90 degree phase offset between LO signals
provided to the mixers of a channel. The output of the four ADCs will
be a pair of I+Q signals, one pair per DMTD channel.
The key observation is that if one has two signals, one being a time
delayed replica of the other, if one multiplies one signal by the
complex [conjugate] of the other signal, the result is Exp[j(phase
difference)]. This is true whatever the waveform of the signal, so long
as the only difference in signals is a delay. The mathematical
argument function of this exponential is the desired phase.
In practice, one will sample far faster than 1 Hz, say 1 MHz, and will
heavily average the resulting stream of products.
Now I have not gone through the math to estimate performance
compared to
the traditional ZCD approach, but the complex multiply and average
approach should be quite robust against noise, and is easily
implemented in a DSP or FPGA.
The time-difference between the two sampling points could be minimized
in such an approach as the phase could be shifted arbitrarily in the
post-processing such that the effective phase difference between the two
chains reduces to near zero and hence the correlation between the
channels for the transfer oscillator would be better in phase and cancel
the transfer oscillator out better.
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.
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.
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.
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.
Joe Gwinn
Joe,
Joe Gwinn wrote:
Magnus,
At 1:00 AM +0000 7/26/09, time-nuts-request@febo.com wrote:
Message: 4
Date: Sun, 26 Jul 2009 03:00:28 +0200
From: Magnus Danielson magnus@rubidium.dyndns.org
Subject: Re: [time-nuts] Measuring phase shift between 1 Hz DMTD
signals by I+Q processing
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Joe Gwinn 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) + i2pif_xt)
Y(t) = A_y * exp(phi_y(t) + i2pif_yt)
Z(t) = A_z * exp(phi_z(t) + i2pif_zt)
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) + i2pi*(f_x - f_z)t)
V(t) = A_y * A_z * exp(phi_y(t) - phi_z(t) + i2pi(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) + i2pi*(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