[time-nuts] Measuring phase shift between 1 Hz DMTD signals by I+Q processing

[Magnus Danielson]

Joe,

Joe Gwinn wrote:
> Magnus,
> 
> At 1:00 AM +0000 7/26/09, time-nuts-request at febo.com wrote:
>> Message: 4
>> Date: Sun, 26 Jul 2009 03:00:28 +0200
>> From: Magnus Danielson <magnus at 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 at febo.com>
>>
>> Joe Gwinn wrote:
>>>  Magnus,
>>>
>>>  At 4:01 PM +0000 7/25/09, time-nuts-request at febo.com 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