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

[Magnus Danielson]

Joe Gwinn wrote:
> Magnus,
> 
> At 4:01 PM +0000 7/25/09, time-nuts-request at febo.com wrote:
>>
>> Message: 5
>> Date: Sat, 25 Jul 2009 16:38:23 +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:
>>>  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.

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 will phase-steps be introduced into 
the datastream. A carefull correction actually compensate for both gain 
and phase shifts.

>> 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.

>> 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 propper pre-staging even do advanced phase 
detectors such as arctan(y/x) in real time and get away with it.

>> 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.

Cheers,
Magnus