HM
Hal Murray
Thu, Jul 25, 2024 6:38 AM
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.
> 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.
DC
David Cureton
Thu, Jul 25, 2024 12:51 PM
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@sonic.net
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "David Cureton" david.cureton@ceos.com.au, "Hal Murray" halmurray@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
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@sonic.net>
To: "Discussion of precise time and frequency measurement" <time-nuts@lists.febo.com>
Cc: "David Cureton" <david.cureton@ceos.com.au>, "Hal Murray" <halmurray@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
BC
Bob Camp
Thu, Jul 25, 2024 1:22 PM
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@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@sonic.net
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "David Cureton" david.cureton@ceos.com.au, "Hal Murray" halmurray@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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@sonic.net>
> To: "Discussion of precise time and frequency measurement" <time-nuts@lists.febo.com>
> Cc: "David Cureton" <david.cureton@ceos.com.au>, "Hal Murray" <halmurray@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@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
DC
David Cureton
Thu, Jul 25, 2024 1:53 PM
Hi Bob,
Planning on using a CTI-OSC5AB02 which is a ovenised crystal oscillator with short term stability of allegedly less that 0.05ppb/s. No Cs but hopefully good enough.
Regards,
David
----- Original Message -----
From: "Bob Camp via time-nuts" time-nuts@lists.febo.com
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "Bob Camp" kb8tq@n1k.org
Sent: Thursday, 25 July, 2024 11:22:44 PM
Subject: [time-nuts] Re: Using aliasing of reference clock to PPS to determine phase offset.
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@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@sonic.net
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "David Cureton" david.cureton@ceos.com.au, "Hal Murray" halmurray@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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi Bob,
Planning on using a CTI-OSC5AB02 which is a ovenised crystal oscillator with short term stability of allegedly less that 0.05ppb/s. No Cs but hopefully good enough.
Regards,
David
----- Original Message -----
From: "Bob Camp via time-nuts" <time-nuts@lists.febo.com>
To: "Discussion of precise time and frequency measurement" <time-nuts@lists.febo.com>
Cc: "Bob Camp" <kb8tq@n1k.org>
Sent: Thursday, 25 July, 2024 11:22:44 PM
Subject: [time-nuts] Re: Using aliasing of reference clock to PPS to determine phase offset.
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@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@sonic.net>
> To: "Discussion of precise time and frequency measurement" <time-nuts@lists.febo.com>
> Cc: "David Cureton" <david.cureton@ceos.com.au>, "Hal Murray" <halmurray@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@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
BC
Bob Camp
Thu, Jul 25, 2024 2:08 PM
Hi
Since you only get one sample each second, any “count buckets” approach quickly gets you into many seconds. Even with an OCXO, the likely cumulative drift over hundreds or thousands of seconds is going to be an issue. It’s not just aging that matters, those little OCXO’s are very temperature / draft sensitive ….
Bob
On Jul 25, 2024, at 9:53 AM, David Cureton david.cureton@ceos.com.au wrote:
Hi Bob,
Planning on using a CTI-OSC5AB02 which is a ovenised crystal oscillator with short term stability of allegedly less that 0.05ppb/s. No Cs but hopefully good enough.
Regards,
David
----- Original Message -----
From: "Bob Camp via time-nuts" time-nuts@lists.febo.com
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "Bob Camp" kb8tq@n1k.org
Sent: Thursday, 25 July, 2024 11:22:44 PM
Subject: [time-nuts] Re: Using aliasing of reference clock to PPS to determine phase offset.
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@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@sonic.net
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "David Cureton" david.cureton@ceos.com.au, "Hal Murray" halmurray@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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi
Since you only get one sample each second, any “count buckets” approach quickly gets you into many seconds. Even with an OCXO, the likely cumulative drift over hundreds or thousands of seconds is going to be an issue. It’s not just aging that matters, those little OCXO’s are very temperature / draft sensitive ….
Bob
> On Jul 25, 2024, at 9:53 AM, David Cureton <david.cureton@ceos.com.au> wrote:
>
>
> Hi Bob,
>
> Planning on using a CTI-OSC5AB02 which is a ovenised crystal oscillator with short term stability of allegedly less that 0.05ppb/s. No Cs but hopefully good enough.
>
>
> Regards,
>
> David
>
> ----- Original Message -----
> From: "Bob Camp via time-nuts" <time-nuts@lists.febo.com>
> To: "Discussion of precise time and frequency measurement" <time-nuts@lists.febo.com>
> Cc: "Bob Camp" <kb8tq@n1k.org>
> Sent: Thursday, 25 July, 2024 11:22:44 PM
> Subject: [time-nuts] Re: Using aliasing of reference clock to PPS to determine phase offset.
>
> 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@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@sonic.net>
>> To: "Discussion of precise time and frequency measurement" <time-nuts@lists.febo.com>
>> Cc: "David Cureton" <david.cureton@ceos.com.au>, "Hal Murray" <halmurray@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@lists.febo.com
>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
