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

[Joe Gwinn]

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

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