GPSDO phase between PPS and clock

[Matth32]

Hello,

I'm interesting by GPSDO design and after reading a lot of documentation about that, I asking myself about one thing but I'm not able to answer myself.

On a GPSDO using a 10MHz clock, is the delay between the rising edge of the PPS and the rising edge of the 10MHz important? Let says, if I have a fixed delay (20 ns for example) between the two edge, is it OK?
Is the goal to have the minimum delay possible or any value at +/- 50 ns (because of the 10 Mhz) is OK (even if it's sliding)?

Could anyone help me?

[capt bullshot]

With a GPSDO it's about a stable frequency, not a defined phase from GPS PPS to 10MHz clock.
Indeed, the phase will vary over time for some +/- tens to hundreds of ns, depending on the particular GPS receive. GPS provides good long term stability, but rather poor short term, so the main purpose of the oscillator part of a GPSDO is to provide a short term stable frequency, that is long term locked to the GPS PPS reference.
Figure the 10MHz divided down to a PPS - ideally this PPS should have a phase of +/- single digit ns to the GPS reference PPS. You'd achieve this by once synchronizing your PPS to the GPS, e.g. by resetting the divider chain, and then running some PLL to keep your oscillator in track to the GPS PPS. There's no need for a particular phase relationship of the one relevant raw 10MHz edge to the GPS PPS - it depends on your particular method to generate the local PPS.

[Matth32]

Thanks for your answer.
My first idea was indeed to use a VC-TCXO of 10 MHz and use an MCU with the PPS connected in input. The MCU count the number of 10MHz pulse between two (or more to average) PPS and so adjust the frequency.

Using a PLL to track the PPS, I need one with a very low BW but perhaps, performance will be better?

[capt bullshot]

A common way is to implement the PLL or some other kind of loop that controls the frequency on the microcontroller as software. No need for a hardware PLL.

[David Hess]

For a GPSDO, the frequency is locked to the pulse per second output, and the phase does matter.  The problem is that errors in the the GPS timing solution vary over a 12 or 24 hour period, so when a stable oscillator is used, the phase of the PPS output will shift in comparison to the stable oscillator.

This means that oscillator stability should be considered over at least a 12 to 24 hour period so that the integrated phase comparison between the GPS and oscillator is valid over that same period.

[nctnico]

The biggest trick though is to get both a stable 10MHz and accurate 1 PPS from a GPSDO. Ideally the 1PPS would be divided down from the 10MHz but this will also need a high resolution phase shifter.

[David Hess]

The biggest trick though is to get both a stable 10MHz and accurate 1 PPS from a GPSDO. Ideally the 1PPS would be divided down from the 10MHz but this will also need a high resolution phase shifter.

If the phase locked loop is working correctly, then the 1 PPS output can be derived from the 10 MHz oscillator in exactly that way.  Then both outputs can be "retimed" with an additional set of latches to match phase exactly.  The extra delay does not matter because the GPS already has provisions to shift the phase of its 1 PPS output to compensate for antenna cable length.

[Matth32]

Thanks for your help.

So, a good way could be to create a PPS inside the MCU from the 10 MHz, this way, phase would be OK by "retiming". And I use the PPS from the GNSS receiver to adjust the 10 MHz frequency so the internal PPS should be OK also, right?

[RoV]

Keep in mind a couple things:
1) most GPS receivers can be configured to set the PPS output at an higher frequency like 1 or 10 kHz. Some can even be set at 10 MHz. A moderately high frequency like 1-10 kHz simplifies the design of the PLL, specially if analog;
2) since the GPS timing is not so accurate in the short period, the performance with a VCXO or a TCXO is only an average one. You'd need a high quality OCXO (or even Rubidium) to get a good stability. Loop bandwidth shall be extremely low.

[Wallace Gasiewicz]

Some old, no longer available GPS units had a ten KHz output.
You could divide down your 10 MHz Xtal Oscillator and compare the two signals.
There is info available on how to do this but I don't know how practical this is today,
You would have to get a ten KHz signal from the GPS unit.

[nctnico]

The biggest trick though is to get both a stable 10MHz and accurate 1 PPS from a GPSDO. Ideally the 1PPS would be divided down from the 10MHz but this will also need a high resolution phase shifter.

If the phase locked loop is working correctly, then the 1 PPS output can be derived from the 10 MHz oscillator in exactly that way.  Then both outputs can be "retimed" with an additional set of latches to match phase exactly.  The extra delay does not matter because the GPS already has provisions to shift the phase of its 1 PPS output to compensate for antenna cable length.

It is not that simple. What I've seen in the wild is that some of the higher end GPSDOs have a seperate PLL to steer the 1 PPS output OR that the 1PPS output is derived from the 10MHz. The first method allows to shift the 1PPS without disturbing the 10MHz clock. The latter requires speeding up / slowing down the 10MHz in order to shift the 1PPS output.

Both methods have upsides / downsides depending on what kind of system is being synchronised to the GPSDO. For example: some systems do a 1 time synchronisation and run from the 10MHz clock. So shifting the 1PPS only and keeping the 10MHz stable means that such systems are not getting a time shift at all.

[radar_macgyver]

I had a discussion with Said Jackson (Jackson Labs) after I used one of their older GPSDOs to do both reference frequency generation, and for generating a PPS timestamping signal. I had noticed the PPS had a somewhat random jitter (most pulses were equally spaced, but every 20th or so pulse had an extra delay of maybe 50-60 ns, and the next pulse would correct it by having the same delay but with a flipped sign). I had wondered why they don't generate the PPS signal by dividing down the 10 MHz, now I know.

The Jackson Labs ULN-1100 GPSDO was meant as a lower-cost and smaller size replacement for a rack-mount Endrun Meridian II GPSDO, whose 1PPS output did not exhibit the jitter I had seen from the ULN-1100. Later models from Jackson Labs do implement the divided-down PPS output.

[David Hess]

So, a good way could be to create a PPS inside the MCU from the 10 MHz, this way, phase would be OK by "retiming". And I use the PPS from the GNSS receiver to adjust the 10 MHz frequency so the internal PPS should be OK also, right?

That might be a good way to do it, and I have considering doing it in exactly that way.  Deriving the MCU clock from the phase locked 10 MHz clock can simplify things.  For whatever reason, most or all GPS timing receivers do not do this.

1) most GPS receivers can be configured to set the PPS output at an higher frequency like 1 or 10 kHz. Some can even be set at 10 MHz. A moderately high frequency like 1-10 kHz simplifies the design of the PLL, specially if analog;

Be real careful about that.  Many of the recent timing GPS receivers have an adjustable output frequency, however the timing solution still only updates once per second or not much faster.  This means that the frequency output is only updated that quickly and *no extra information is available*.  The phase locked loop still needs a bandwidth suitable for the timing solution update rate so the difficulty is still the same.  The higher frequency makes phase locking easier, but if you take advantage of it, it will steer your oscillator to follow the drifting GPS oscillator instead of the timing solution.

2) since the GPS timing is not so accurate in the short period, the performance with a VCXO or a TCXO is only an average one. You'd need a high quality OCXO (or even Rubidium) to get a good stability. Loop bandwidth shall be extremely low.

I agree.  The stability of the TCXO, OCXO, or Rubidium source determines the crossover point between the GPS timing signal and the local oscillator, and a local oscillator with a suitable stability of 10s of hours to days is required.  Note that provisions should be made to hasten the PLL settling time as much as possible, by for instance "jamming" the output of the counter for the local pulse per second output.

The biggest trick though is to get both a stable 10MHz and accurate 1 PPS from a GPSDO. Ideally the 1PPS would be divided down from the 10MHz but this will also need a high resolution phase shifter.

If the phase locked loop is working correctly, then the 1 PPS output can be derived from the 10 MHz oscillator in exactly that way.  Then both outputs can be "retimed" with an additional set of latches to match phase exactly.  The extra delay does not matter because the GPS already has provisions to shift the phase of its 1 PPS output to compensate for antenna cable length.

It is not that simple. What I've seen in the wild is that some of the higher end GPSDOs have a seperate PLL to steer the 1 PPS output OR that the 1PPS output is derived from the 10MHz. The first method allows to shift the 1PPS without disturbing the 10MHz clock. The latter requires speeding up / slowing down the 10MHz in order to shift the 1PPS output.

Both methods have upsides / downsides depending on what kind of system is being synchronised to the GPSDO. For example: some systems do a 1 time synchronisation and run from the 10MHz clock. So shifting the 1PPS only and keeping the 10MHz stable means that such systems are not getting a time shift at all.

I am sorry if that was not clear.  I mean deriving a local pulse per second output from the local reference oscillator instead of using the raw pulse per second output from the timing receiver will produce signals with no phase drift.

Some timing receivers in the past did this internally to produce a jitter free pulse per second output, but offhand I do not know of any now which do this.  Some of these even supported using an external higher performance reference oscillator.  Most often timing receivers now offer a "correction" specifying the difference between the true pulse per second output and the provided signal because of limited resolution.  Using the correction is optional since the PPS jitter is insignificant over long time scales.

[lyxmoo]

A GPSDO it's about a stable frequency, absulately correct;  but phase lock to 10MHz clock is very important to long-distance GPSDOs.

[Matth32]

I had a discussion with Said Jackson (Jackson Labs) after I used one of their older GPSDOs to do both reference frequency generation, and for generating a PPS timestamping signal. I had noticed the PPS had a somewhat random jitter (most pulses were equally spaced, but every 20th or so pulse had an extra delay of maybe 50-60 ns, and the next pulse would correct it by having the same delay but with a flipped sign). I had wondered why they don't generate the PPS signal by dividing down the 10 MHz, now I know.

Perhpas I miss something but what was the reason why they don't generate PPS by dividing the 10 MHz? Long time stability?

By the way, it seems there is a lot of different options to disciplined the 10 MHz on the input PPS. I think I need to make a deeper study to see all upsides / downsides of each method because I was not able to find this kind of study over Internet. 

[David Hess]

By the way, it seems there is a lot of different options to disciplined the 10 MHz on the input PPS. I think I need to make a deeper study to see all upsides / downsides of each method because I was not able to find this kind of study over Internet.

There are different ways to do it, but they all rely on phase locking a reference oscillator to the GPS timing solution which is provided through a pulse per second output or similar.

[radar_macgyver]

Perhpas I miss something but what was the reason why they don't generate PPS by dividing the 10 MHz? Long time stability?

Answer was given by nctnico above, the relevant part quoted below:

... The latter requires speeding up / slowing down the 10MHz in order to shift the 1PPS output.

If you are generating the 1PPS by dividing the 10 MHz down, to affect a phase shift on the PPS signal would require the 10 MHz to have a slight frequency error. In applications which cannot tolerate this (for example, using the 10 MHz as a reference to generate a 95 GHz LO), even small frequency errors will be quite noticeable.

[David Hess]

If you are generating the 1PPS by dividing the 10 MHz down, to affect a phase shift on the PPS signal would require the 10 MHz to have a slight frequency error. In applications which cannot tolerate this (for example, using the 10 MHz as a reference to generate a 95 GHz LO), even small frequency errors will be quite noticeable.

That is what "jamming" is for during the initial lock.  While locking, the counter which generates the PPS output is "jammed" to align the reference PPS output with the GPS timing solution.

GPSDOs which compare a divided reference with the PPS have to jam the counter anyway to prevent excessive lock times as they shift the phase of the divided reference.

[radar_macgyver]

True, but what about after the initial lock? Without altering the 10 MHz oscillator's frequency to affect the phase change, the only way to do it would be with a programmable delay line, right?

[David Hess]

True, but what about after the initial lock? Without altering the 10 MHz oscillator's frequency to affect the phase change, the only way to do it would be with a programmable delay line, right?

Why would there be a phase change?  Once locked, the 10 MHz GPSDO is phase locked to the GPS timing solution, and the pulse per second output generated from the 10 MHz GPSDO is also.

The programmable delay line is needed to produce an accurate pulse per second output from the GPS receiver's pulse per second output when it is asynchronous to the GPS receiver's clock.  Very few or no GPS timing receivers do this, instead issuing a correction for each pulse per second output before it happens.  A GPSDO might do this when an analog PLL is used.  A PLL implemented in a controller can apply the correction internally without a programmable delay line.

[nctnico]

True, but what about after the initial lock? Without altering the 10 MHz oscillator's frequency to affect the phase change, the only way to do it would be with a programmable delay line, right?

Why would there be a phase change?  Once locked, the 10 MHz GPSDO is phase locked to the GPS timing solution, and the pulse per second output generated from the 10 MHz GPSDO is also.

That is only true if timing of the 1PPS pulse doesn't need to be shifted. But in many cases it can be handy to have that feature and/or needing a finer grained control than the 10MHz edges (think about cable length calibration for downstream devices down to the picosecond level).

Also, if generating a 1PPS from the 10MHz is simple, then all low cost GPSDOs would do this... but they don't. It really is more complicately than that. Typically the 1PPS wanders around several tens of ns with respect to the 10MHz output on the GPSDOs you find on Ebay. For 3G/4G cell towers that is good enough. If you want to keep the 10MHz stable, then you'd need an external PLL (which could be VCXO based relative to the 10MHz output from the OCXO / Rb) to create an accurate (picosecond level compared to 10MHz reference) 1PPS that is a long term average of the 1PPS output of the GPS receiver.

[radar_macgyver]

There are also other effects that could in theory be corrected with a PLL such as the 2-g turn (g-forces acting on the crystal), temperature and crystal aging. However, the time constant of the PLL must be quite long for stability; if one expects these changes to occur more frequently (such as in a high acceleration environment), then relying on only the PLL would result in a phase shift of the PPS output until the PLL 'caught up'. Sophisticated GPSDOs have open-loop corrections applied for these effects so that the response time is improved, and also so the initial lock happens quickly.

For metrology applications (implying a benign environment), this may not be as significant, so the tendency is to let the PLL do the work, as implemented in an Endrun or Symmetricom GPSDO.

[Johnny B Good]

Some old, no longer available GPS units had a ten KHz output.
You could divide down your 10 MHz Xtal Oscillator and compare the two signals.
There is info available on how to do this but I don't know how practical this is today,
You would have to get a ten KHz signal from the GPS unit.

 Not a problem with a U-blox M8T (or M7N or M8N or a LEA6T). Unlike the ancient Jupiter-T (used in the venerable G3RUH design which only offers a fixed 10KHz synced to the 1PPS), you have a choice, in 1Hz steps, going all the way to their 16Mz limit.

 This a rather handy feature since you easily create "A Simple GPSDO" using one less 74390 dual divide by ten (/5 with /2 stages) based on the original G3RUH design using any one those U-blox modules (preferably a 'T' version or better yet a ZED9T if you can afford its price premium).

 My own DIY GPSDO is based on this design using an M8T with an ex-Symmetricom OCXO, running the PLL at 100KHz which seemed a more optimal choice at the time, a design choice I'm now having some doubts about, largely due to the issue of dielectric absorption (DA) in the 470 and 47 uF caps in the 1000s TC LPF which may (or may not) be imposing a biassing effect on the phase offset between the PPS and the 10MHz OCXO output due to variations in ambient temperature.

 I can't decide whether this imagined effect is significant enough for me to use PP foil capacitors for their 2 orders of magnitude less DA (and, unfortunately less capacitance) replacing the 220k and 2M resistors with 2 and 20M resistors to create an LPF with a 60s TC and take advantage of the 100 fold slower response of a 1KHz PLL, accepting the downside of an ever more glacial lock up time.

 Since I've now added a protected LiPo pouch cell to my GPSDO to remove the curse of the "Shoot first, ask questions later" startup control algorithm of the OCXO's oven controller every time it reboots after even a 10ms interruption of supply voltage that destabilises its frequency for some 10 to 15 minutes every time, the hours long lock up time will be of little consequence for a piece of kit that's intended to be permanently powered up anyway and will never ever be routinely switched off (indeed, there is no off switch).

 However, I'm now considering an MCU based design to discipline my rubidium frequency reference to eliminate dielectric absorption issues in long time constant analogue LPFs, hence my interest in this topic thread which raised the issue of significant diurnal phase shifts in the GPS time pulses.

 Can there really be as much as 30 to 50ns diurnal variation? If this is true, it would neatly explain why I've been banging my head against a brick wall over the past couple of months in my attempts to eliminate a diurnal chill factor effect on my temperature stabilised (and barometrically compensated) rubidium frequency standard (RFS) project.

 Whilst there is undoubtedly a "Chill Factor" effect seemingly observable with large temperature swings (25 deg down to as low as 11 deg), it may not be as large a problem as I thought since I might be conflating my test results with a diurnal GPS timing issue. With a 24 hour holdover wander of 25 to 30 ns, it may already be stable enough to chuck an M8T into the mix. My problem now is in deciding on the best way to 'discipline' (auto-recalibrate in reality) from a GPS timing module. Any ideas or suggestions?

[nctnico]

However, I'm now considering an MCU based design to discipline my rubidium frequency reference to eliminate dielectric absorption issues in long time constant analogue LPFs, hence my interest in this topic thread which raised the issue of significant diurnal phase shifts in the GPS time pulses.

 Can there really be as much as 30 to 50ns diurnal variation?

Yes. I don't remember the exact numbers but you can expect such drifts over a 24 hour period from a GPSDO. I have done some testing between GPSDOs and a Cesium clock that show drifts in the tens of ns over a 48 hour period. I don't know the URL but it is possible to get data that provides you with the GPS time offsets that tell you the error in your GPS receiver. If you combine these with the adjustments you did in the oscillator, you can characterise your oscillator and with enough data, you might be able to do pre-emptive adjustments or use longer time averaging time intervals. This all depends on the stability of the oscillator but based on worst case specs even a Rb oscillator is likely to drift more than several tens of ns in 24 hours.

[Johnny B Good]

However, I'm now considering an MCU based design to discipline my rubidium frequency reference to eliminate dielectric absorption issues in long time constant analogue LPFs, hence my interest in this topic thread which raised the issue of significant diurnal phase shifts in the GPS time pulses.

 Can there really be as much as 30 to 50ns diurnal variation?

Yes. I don't remember the exact numbers but you can expect such drifts over a 24 hour period from a GPSDO. I have done some testing between GPSDOs and a Cesium clock that show drifts in the tens of ns over a 48 hour period. I don't know the URL but it is possible to get data that provides you with the GPS time offsets that tell you the error in your GPS receiver. If you combine these with the adjustments you did in the oscillator, you can characterise your oscillator and with enough data, you might be able to do pre-emptive adjustments or use longer time averaging time intervals. This all depends on the stability of the oscillator but based on worst case specs even a Rb oscillator is likely to drift more than several tens of ns in 24 hours.

 Many thanks for that swift response. 

 Oddly enough, shortly after posting my question, I noticed a reversal of today's ~1ns/hour downward drift of the ruby versus my 'Simple GPSDO' just minutes after local sunset. I rather think I'd just observed the beginnings of this diurnal phase shift effect just where one might expect it to come into play at the day/night transition periods of this daily cycle.

 Another factor that reinforces this observation being the fact that overnight test runs generally displayed the least drift and disciplining wobble, exactly the time period when the ionosphere in the unlit hemisphere could be expected to be at its least dense and most stable condition.

 With regard to stability of Rb oscillators, most home lab concoctions (the Rb frequency reference projects described in you tube videos at any rate) would be doing extremely well to achieve daily phase shift rates below 100ns unless they happened to fortuitously be one of the few examples exhibiting an extremely low tempco by pure blind chance alone to start with.

 Just throwing a Rb oscillator into an enclosure designed one way or another merely to prevent overheating (or not in some cases!) is no way to create a stable home lab RFS imo, hence my now two year old project to do my LPRO 101 the justice it deserves.

 I started off with a simple analogue on/off thermostatic fan controller which, whilst it did improve the ruby's stability, offered no cost effective option to include barometric compensation, so a few months of experimentation later, I took the plunge into programming an Arduino Nano to the task, never once regretting this change of strategy ever since.

 It's that experience which now has me turning away from the G3RUH 'Simple GPSDO' option, as fine as it was, and finally taking a serious look at the MCU control option in my next GPSDO/GPSDRO project. I'm going to start with a GPSDRO simply because I should be able to bypass the horrendously destabilising tempco issues that seemed to have plagued a lot of the DIY mcu gpsdo designs that had been described in various EEVBlog topic threads.

 I can thermally bond any temperature critical components (including resistors) onto the thermally stabilised heat spreader to 'cheat my way past' any such tempco issues, maximising the return on all the effort I'd invested over the past two years on achieving a constant 36.10 degree (+/- 30mK or so) base plate temperature.

 Now that I'm aware of this diurnal phase shift issue with the GPS timing pulses, I can lay my RFS project to rest until I can at least create a more stable gpsdo reference. I also have a Symmetricom SA.22C awaiting a similar improvement exercise so I think the sequence will be:-

 Convert the LPRO into a GPSDRO to use as my reference standard to calibrate the Symmetricom SA.22C based RFS to convert that into a second GPSDRO which can then be used to finish refining the stand alone performance of the LPRO by a radical revamp of the insulation and cooling pathways with an exhaust gallery to allow servo controlled valves to gradually transition from full through flow to fully recirculated exhaust back to the intake plenum to ease speed control demands on the cooling fan to provide finer temperature control over a much extended ambient range (from a 33 deg max, down to quite possibly even sub zero ambient temperatures!).

 The current limits are 32 deg max down to around a 15 deg minimum before the controller is obliged to stop the fan and resort to on/off control. The problem in this case being the need to give a starting 'kick' to un-stick a brushless DC fan without over-cooling the heatsink under such cool air intake conditions. Even then, this low operating temp limit was only achieved by placing a damper in the intake vent, hence the 1 degree sacrifice on the max ambient temperature margin.

 I've attached a photo of the LPRO based RFS along with a screenshot showing the drift since 1 minute past midnight to 22:00 this evening. The trace had started at the LHS, reached the RHS around sunset just over 16 hours later before sweeping leftwards to its current location where it seems to have stood still for the past hour.

 You can see the 'scope in the background of the photo along with that of the SDM3065X displaying the current lamp voltage supplied from the lower of the two stereo jacks which also provides access to the XTal voltage. The upper jack socket provides access to the 5v reference at the hot end of the cal pot and that of its wiper contact which is linked to the 'C Field' pin via a (temperature stabilised) 3 Mohm resistor. That RFS box, btw, is 12 inches wide by 8 inches tall by 10 inches deep! It needs to be that big simply to accommodate all the insulation and ventilation galleries.

[EDIT 2022-11-20]

I've added a new photo. Can you spot the difference?