Empathy List Archives

DC

David Cureton

Thu, Jul 25, 2024 4:29 AM

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.

Two options I can see are:

increase the counter clock to 100Mhz to reduce the ambiguity by 10
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?

Regards,
David

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. Two options I can see are: 1) increase the counter clock to 100Mhz to reduce the ambiguity by 10 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? Regards, David

MD

Magnus Danielson

Thu, Jul 25, 2024 11:36 AM

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:

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.

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

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

EK

Erik Kaashoek

Thu, Jul 25, 2024 1:12 PM

David,

With tools like Octave it is doable to create a correct simulation of a
GPSDO that includes PPS jitter, oscillator instability , DAC resolution,
PPS time measurement resolution, PI parameters and other system
limitations.
This allows you to very quickly test different HW designs.
For a GPSDO I build I measured the oscillator instability and the PPS
jitter during a 6 hours period and used that for the simulation.
Attached the output of this simulated GPSDO including Kalman filter

You can also find a complete implementation of such a simulation at
http://www.leapsecond.com/pages/gpsdo-sim/
The page includes actual measured PPS and oscillator data so you don't
even have to measure something to start with your HW design.

Some practical data
Without sawtooth correction and a cheap GPS module you can expect around
20 ns jitter on the PPS.
Modern MCU with 200 MHz internal clock and fast timers allow measuring
the PPS event with 5 ns resolution.
In practice, adding an interpolator (TDC or Lars analog variant) when
using a cheap GPS without sawtooth correction won't make any difference.
Erik.

On 25-7-2024 13:36, Magnus Danielson via time-nuts wrote:

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:

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.

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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com

David, With tools like Octave it is doable to create a correct simulation of a GPSDO that includes PPS jitter, oscillator instability , DAC resolution, PPS time measurement resolution, PI parameters and other system limitations. This allows you to very quickly test different HW designs. For a GPSDO I build I measured the oscillator instability and the PPS jitter during a 6 hours period and used that for the simulation. Attached the output of this simulated GPSDO including Kalman filter You can also find a complete implementation of such a simulation at http://www.leapsecond.com/pages/gpsdo-sim/ The page includes actual measured PPS and oscillator data so you don't even have to measure something to start with your HW design. Some practical data Without sawtooth correction and a cheap GPS module you can expect around 20 ns jitter on the PPS. Modern MCU with 200 MHz internal clock and fast timers allow measuring the PPS event with 5 ns resolution. In practice, adding an interpolator (TDC or Lars analog variant) when using a cheap GPS without sawtooth correction won't make any difference. Erik. On 25-7-2024 13:36, Magnus Danielson via time-nuts wrote: > 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@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

DC

David Cureton

Thu, Jul 25, 2024 1:41 PM

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@lists.febo.com
To: "David Cureton via time-nuts" time-nuts@lists.febo.com
Cc: "Magnus Danielson" magnus@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:

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.

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 .