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

[Bob Camp]

Hi

What is the source of your “10 MHz”?

If it’s a typical microprocessor clock, it’s going to drift all over the place and do so fairly rapidly. That’s going to mess up a “look at the bins” approach. 

If it’s something like a Cs standard then indeed, you can look at bins for a pretty long time and draw conclusions.

Bob

> On Jul 25, 2024, at 8:51 AM, David Cureton via time-nuts <time-nuts at lists.febo.com> wrote:
> 
> Thanks for your response Hal. My initial example was to illustrate the aliasing of the signals. 
> 
> I would hope for maybe 10 periods of 10,000,000 counts followed by a 10,000,001 with a 10Mhz reference. Therefore the ambiguity in the relative phase of the reference clock and the PPS would be much more constrained at the point were the 10,000,001 count was obtained by virtual of 10 million + 1  rising clock edges to fit between the consicutive PPS pulses. 
> 
> Yes, I would only know this relative phase every 10 seconds but the system should be stable enough that knowing the relative phase of the signals every 10 seconds would be sufficient allow the tracking of the alignemnet of the reference clock's phase alignment to the PPS. 
> 
> Naturally the stability of the hardware may allow that application of adjustments to the control signal to be extended to ensure that the system is working close to the Allan intercept.  
> 
> Understood that the PPS and the reference clock are not syncronised, this is the point of the excercise to make the system a PLL rather than an FLL using just a microporcessor timer/counter.  In an FFL the 10Mhz reference clock has an arbitary phase relationship to the PPS. 
> 
> I need to get some experimental results to test the feasability of the idea as I am using very idealised numbers for my samples counts. To be honest I expect the jitter of the PPS signal to be the dominant noise in the system and the actual relative phase measuerement will only become evident after some statistitical analysis of multiple sample periods.
> 
> 
> Regards,
> David
> 
> ----- Original Message -----
> From: "Hal Murray" <halmurray at sonic.net>
> To: "Discussion of precise time and frequency measurement" <time-nuts at lists.febo.com>
> Cc: "David Cureton" <david.cureton at ceos.com.au>, "Hal Murray" <halmurray at sonic.net>
> Sent: Thursday, 25 July, 2024 4:38:08 PM
> Subject: Re: [time-nuts] Using aliasing of reference clock to PPS to  determine phase offset.
> 
>> counter running at 10Mhz
>> would have 10e6 counts on each capture
>> around 1uS based
> 
> Looks like you dropped/added a 0 in there.  My guess would be you started 
> at 1 MHz and missed a few edits with you changed to 10 MHz.
> 
> 
>> 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  
> 
> I think that approach is a wild goose chase.
> Basically, what you are doing is counting over a longer period of time.
> Looking for a pattern of 0 0 0 0 1 in the bottom bit rather than 0 0 0 0 0 
> just moves the target frequency up a bit.
> 
> What you want is the Allan Intercept.  You want to average as long as you can but not so long that you can't follow things like temperature changes.
> 
> Note that the PPS signal is not synchronous with your clock.  If the PPS happens to be in phase with your clock there is a race condition.  You might get 9,999,999 followed by 10,000,001 or the reverse.
> 
> 
> If I had the hardware for that sort of setup, I would write some test code that drove the DAC by hand and printed the counts between PPS pulses.  The idea is to figure out how big a step the bottom bit of the DAC makes and how stable things are in your lab.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> -- 
> 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/28jcsmlgiC/67aaNPNa1LuZp7J9iGgsdV/-0.1
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com