[time-nuts] Re: Using aliasing of reference clock to PPS to determine phase offset.

[David Cureton]

Hi Magnus,  Thank you very much for such a considered reponse.  

Opps, thank you for the correction. 

I was intending to run the system in FFL mode first get the 10Mhz reference frequency very close before switching to this PLL mode constraining the frequency error to within 1Hz before phase tracking. This is similar to dividing down the 10Mhz to the 50khz to make sure I am doing a comparison of the correct edges. Appoliges I should have outlined the course frequency correction prior to switching to phase tracking. 

I wasn't aware of the TAPR TIC. I am reading the manual now to glean ideas from it and freshining up on the Lars TIC.  I guess my challenge is to see if I can get the relative phase information from the system entirly in the digital domain and learn a bit along the way. 

Understood re sawtooth error based on GPS core clock. That will have the effect of biasing and smearing out any corrlation of relative phase measurements based on where in the sawtooth error period I sample. 

There will be a lot of learing on my behalf and finding out where the limits are and if this is at all possible. Once again thank you for the feedback, you have given me food for thought. 
   
Regards,
David

----- Original Message -----
From: "Magnus Danielson via time-nuts" <time-nuts at lists.febo.com>
To: "David Cureton via time-nuts" <time-nuts at lists.febo.com>
Cc: "Magnus Danielson" <magnus at rubidium.se>
Sent: Thursday, 25 July, 2024 9:36:34 PM
Subject: [time-nuts] Re: Using aliasing of reference clock to PPS to determine phase offset.

Hi David,

On 2024-07-25 06:29, David Cureton via time-nuts wrote:
> Hi Time-nuts
>
> I have been considering building a GPS-DSO by running a microprocessor off a 10Mhz OCXO and using the GPS PPS from capture the timer counter running at 10Mhz.
>
> In a perfectly timed world each counter capture would have 10e6 counts on each capture of the timer which gives me frequency lock by I have no idea about phase of the reference clock with respect to the PPS.
>
> So I would have ambiguity of synchronisation of around 1uS based on a 10Mhz reference.

With 10 MHz you get 100 ns steps. 10e6 is really 1e7, so you get 1e-7 
for period, thus 100 ns.

The trouble you will have is that if you have an 10 MHz oscillator of 
say +/- 10 ppm, then you have +/- 100 Hz and you will not know which of 
those 1 Hz bins you ended up with just sampling it like that. However, 
there is a fairly simple remedy for this. By dividing the 10 MHz by say 
200, the +/- 10 ppm on that now 50 kHz ends up having a +/- 0.5 Hz which 
is within the propper capture range of the PPS. As side-consequence of 
phase-locking those, the 50 kHz is now PPS aligned.

If you then chooses to revert to the 10 MHz for further locking, that's 
fine as you coarse-tuned it, but I don't think you will need to do that 
as you get the same edge-sensitivity in practice.

>
> Two options I can see are:
>
> 1) increase the counter clock to 100Mhz to reduce the ambiguity by 10
You could use TIC-chips or other interpolation solutions to get even 
higher time-stamp accuracies. See TAPR TICC for instance.
> 2) Discipline the reference clock to be a non-integer multiple of the PPS and use aliasing to determine the phase of the reference clock with respect to the phase of the GPS pps signal .
>
> i.e if I discipline the reference clock to be 10.0000005Mhz (10Mhz plus 0.5Hz) then the count of each clock should alternate
>
>
> 10,000,000
> 10,000,001
>
> if I discipline my reference clock to 10.0000001 (10Mhz plus 0.1hz) then the sample counts should be
>
> 10,000,000
> 10,000,000
> 10,000,000
> 10,000,000
> 10,000,000
> 10,000,000
> 10,000,000
> 10,000,000
> 10,000,000
> 10,000,001
>
> Therefore on the 10th sample that has a solitary extra 1 pulse I know that the phase of the reference clock and the PPS signal are very close to each other conveying a10 times increate in the knowledge of the relative phase of each signal.
>
> The software disciplining can ensure that the system remain phase locked by expecting every 10th sample to have an extra count and accumulating and gently slew the reference to maintain this.
>
> On other GPSDO projects they go to some length to have a phase comparator to do this work, however I think this achieves the same provided the application can handle a clock that is not exactly 10Mhz
>
> Maybe this approach would all be swamped by phase noise of the reference oscillator and/or PPS signal.
>
> Any thoughts on this before I commit to testing this in hardware?

You can do interpolation using frequency offset, sure you can. However, 
that interpolation method, which actually get somewhat better by the 
other noise and systematic effects, get's even better when using an 
interpolator for time, that is TIC. Noise and existing systematics help 
that solution too. You can look at the simple interpolator solution of 
Lars that have been used by several, or that of TIC chips or similar.

Also consider using the correction of "saw tooth error", which is the 
GPS/GNSS modules output of the truncation error of where it wanted to 
put the PPS and where it could put the PPS. Within a GNSS module, you 
have a PPS generator operating in a core clock, but even when the 
solution has higher resolution than the clock period, the PPS is output 
on a selected edge of the core clock. So, there will be a truncation 
error, and many receivers output that. This allows you to correct for 
that error on each pulse, and your time-interval measure get's corrected 
to remove that systematic mechanism (driven by systematic errors and noise).

Lars made a very minimalistic interpolator for his GPSDOs. It achieved 
about 1 ns resolution for essentially no exclusive components at all.

I hope you have received some useful hints and tricks that you may not 
have considered. Do not feel like you should not attempt what you feel 
like and learn from, but hopefully you learn a few more things to think 
about.

Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- time-nuts at lists.febo.com
To unsubscribe send an email to time-nuts-leave at lists.febo.com
-- 
Message  protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.https://www.mailguard.com.au/mg
Click here to report this message as spam:
https://console.mailguard.com.au/ras/28jiewYZ5N/2KBvwboyFxuMDUhoppD6n8/0.1