Building one's own GPS-disciplined oscillator to generate 10 MHz cheaply?

[edpalmer42]

More complex designs rely on jitter correction from the GPS so if we ignore those, then we have typically 10s of nanoseconds of jitter in the pulse from the GPS because the clock generating the output pulse is asynchronous to GPS time in addition to the timing error from the GPS solution.  That leads to the simplest GPSDO solution being to divide down the output from the disciplined oscillator so that the maximum jitter from the GPS pulse does not allow cycle slipping when a phase locked loop is used to compare them.  At that point, performance depends on the time constant of the phase locked loop filter and even an analog filter can achieve 10s to 100s of seconds.

The Jupiter-T solution relies on a 1kHz reference and the James Miller circuit relies on a 10kHz reference from the GPS but there is no reason this cannot be done with the more common 1PPS reference.  Note that many or even most GPSes which provide a high frequency output are just phase locking it to the 1PPS solution so the higher reference frequency provides no advantage.

James Miller's circuit uses the 10 KHz output of the Jupiter board because at that frequency it's easy to use hardware PLL circuits.  In general, to phase lock to a 1 PPS signal, you have to use a software PLL.  It might be technically possible to use a hardware circuit, analog and/or digital, but it's really difficult.

FYI, here are measurements that I've made of the period of the 1 PPS output of some GPS receivers and GPSDOs.

Code: [Select]

GPS Devices -- Measure & analyze the period of the 1 PPS Output

Device ............... Std Dev (ns).... Range (max-min)(ns) ... Device ...... Notes

Navsync CW12 ......... 4 - 5 .......... 20 - 25 ............... GPS Rcvr .... 1,7
Motorola UT+ ......... 40 - 55 ........ 95 - 110 .............. GPS Rcvr .... 2,7
Rockwell Jupiter ..... 10 ............  50 ...................  GPS Rcvr .... 3,7
Motorola M12M ........ 10 - 15 ........ 40 - 60 ............... GPS Rcvr .... 7

Trimble Thunderbolt .. 0.4 - 0.5 ...... 2 - 4 ................. GPSDO ....... 6,8
HP Z3801A ............ 0.1 - 0.2 ...... < 1 ................... GPSDO ....... 6
HP Z3817A / CW12 ..... < 0.1 .......... < 1 ................... GPSDO ....... 4,6
Jackson Labs GPSTCXO . 0.3 - 0.4 ...... 2 - 3 ................. GPSDO ....... 6
NEC NWM-034241-201 ... 0.1 - 0.2 ...... < 2 ................... GPSDO ....... 5
Trimble UCCM ......... 0.09 - 0.11 .... < 1 ................... GPSDO ....... 5

Results are based on multiple runs of ~ 1000 measurements each.
Sawtooth correction has not been used for any of the GPS receivers.  Where supported, it would reduce the numbers substantially.
All units were connected to the same antenna system.

Notes

1.  Sawtooth correction not supported.
2.  Most 'range' results were in this group, but there were a few at 20 - 30.
3.  Only one test.
4.  Requires external 1 PPS input.  Equipped with E1938 oscillator.
5.  Measurement made with Fluke PM6681.
6.  Measurement made with HP 5370B.
7.  Measurement made with HP 5372A.
8.  Standard parameters.
9.  Optimized parameters. (Not yet used in any tests)
Ed

[David Hess]

James Miller's circuit uses the 10 KHz output of the Jupiter board because at that frequency it's easy to use hardware PLL circuits.  In general, to phase lock to a 1 PPS signal, you have to use a software PLL.  It might be technically possible to use a hardware circuit, analog and/or digital, but it's really difficult.

The problem as I see it is that the GPS timing error over short timescales is much greater than the disciplined oscillator error and a PLL with a long time constant to overcome this does not need the higher frequency reference and ignores the jitter in the 1 Hz output anyway.  1000 or 10,000 pulses showing the same phase error between the GPS solution and the oscillator is not any better than 1 pulse.  So the high frequency output makes the PLL easier because a faster time constant can be used but the faster time constant defeats the purpose of making a GPSDO; instead you could manually adjust your frequency counter based on the GPS pulse output and get better results using the frequency counter's reference output.

I agree the analog implementation is a technical challenge; common phase detectors are not designed with the low output leakage needed to support such long time constants.  That means using a discrete implementation with low leakage analog switches or maybe low leakage diodes.  I was working on a design when squirrels chewed through the cable on my GPS18x and ran off with it; after that I lost interest.  I was more worried about adding lock detection and fast settling from startup than achieving a long time constant.

FYI, here are measurements that I've made of the period of the 1 PPS output of some GPS receivers and GPSDOs.

Those are consistent with my own measurements of a Garmin GPS18x which can operate at 5PPS.  It was easy enough to see that the output pulse was aligned with the roughly 32 MHz clock inside the receiver so under ideal conditions, the pulse was jumping around by 33 nanoseconds.  The GPS mounted outside made a pretty good outdoor temperature sensor by monitoring the difference between the GPS receiver clock and GPS pulse.

[edpalmer42]

James Miller's circuit uses the 10 KHz output of the Jupiter board because at that frequency it's easy to use hardware PLL circuits.  In general, to phase lock to a 1 PPS signal, you have to use a software PLL.  It might be technically possible to use a hardware circuit, analog and/or digital, but it's really difficult.

The problem as I see it is that the GPS timing error over short timescales is much greater than the disciplined oscillator error and a PLL with a long time constant to overcome this does not need the higher frequency reference and ignores the jitter in the 1 Hz output anyway.  1000 or 10,000 pulses showing the same phase error between the GPS solution and the oscillator is not any better than 1 pulse.  So the high frequency output makes the PLL easier because a faster time constant can be used but the faster time constant defeats the purpose of making a GPSDO; instead you could manually adjust your frequency counter based on the GPS pulse output and get better results using the frequency counter's reference output.

I agree the analog implementation is a technical challenge; common phase detectors are not designed with the low output leakage needed to support such long time constants.  That means using a discrete implementation with low leakage analog switches or maybe low leakage diodes.  I was working on a design when squirrels chewed through the cable on my GPS18x and ran off with it; after that I lost interest.  I was more worried about adding lock detection and fast settling from startup than achieving a long time constant.

I think that the higher frequency just makes it technically easier to use hardware PLL circuits.  After that, it's up to the designer to make sure that the oscillator's performance isn't degraded by the short-term GPS noise.  If you look at this page:  http://www.leapsecond.com/pages/gpsdo/ , you'll see James Miller's hardware PLL compared to three commercial, presumably software, circuits.  Note that at low values of Tau, the free and locked performance is the same for all units.  That means that those designers did their job properly, regardless of whether they were working in the hardware or software realms.

Notice also that Miller's circuit was able to realize similar results to the other units at higher values of Tau.  That's not to say that hardware is superior to software.  Software can do tricks that hardware can only dream of.  eg.  Dual time constants for acquiring vs. tracking or aging compensation during holdover.

Ed

[metrologist]

Wow, you guys are way over my head in this. I was looking at my Jupiter module and tried to trigger that against my OCXO. Not sure what this is telling me...

top is 10kHz and I tuned my ocxo to sync with it.

[Gyro]

It's telling you that there's jitter on the 10kHz output of the Jupiter (as you would expect from the raw output of a GPS).


Edit: The equivalent display with the LEA-6T against OCXO, both signals at 1MHz, showing the same thing...

[cdev]

I don't have any fancy equipment but I do now have a bunch of identical tiny GPSs so to see if their timing pulses align perfectly I connected two (I currently only have two antenna adapters that fit the ultra-tiny UFL socket on the GPSs)

There are visible differences in the PPS pulse's leading edge's timing between two units, even when they are receiving the same signal (split using a signal splitter)

Like Ublox, Skytraq makes a slightly more expensive timing-specific GPS that also embeds a changeable frequency source. But they state that its got significant amounts of jitter, as all such devices do. However its good enough for some uses as it is.

I'm still working on my NTP setup. It would be interesting to sample the signals emanating from consumer GPS equipment with an eye to seeing if any of the available signals could be leveraged to make a stable frequency source very cheaply, with components that were not one of a kind finds.

(Taking the approach that was done here, perhaps..

https://www.eevblog.com/forum/projects/3-dollar-precision-frequency-standard/  )

The Skytraq "Navspark" maker-friendly GPSs actually run on a CPU, a Leon 3 processor, which also offers a substantial amount of processing power compared to an Arduino - but the Arduino code should work unmodified on it, with a simple recompile..

So, it might even be possible to build the associated processing capability needed to turn the available signals into a 10 MHz (or other frequency) standard by using self-written software running on the Leon 3.  It also has an ADC which might be useful also (although on the Mini it may not be brought out to a pin because its on the bottom of the chip)

I am just ruminating here, I have nowhere near the skill I would need to do this. I'm just speculating.

Cheap science is important to me because I see the doors to taught science closing for a good percentage of the planet.   

James Miller's circuit uses the 10 KHz output of the Jupiter board because at that frequency it's easy to use hardware PLL circuits.  In general, to phase lock to a 1 PPS signal, you have to use a software PLL.  It might be technically possible to use a hardware circuit, analog and/or digital, but it's really difficult.

The problem as I see it is that the GPS timing error over short timescales is much greater than the disciplined oscillator error and a PLL with a long time constant to overcome this does not need the higher frequency reference and ignores the jitter in the 1 Hz output anyway.  1000 or 10,000 pulses showing the same phase error between the GPS solution and the oscillator is not any better than 1 pulse.  So the high frequency output makes the PLL easier because a faster time constant can be used but the faster time constant defeats the purpose of making a GPSDO; instead you could manually adjust your frequency counter based on the GPS pulse output and get better results using the frequency counter's reference output.

I agree the analog implementation is a technical challenge; common phase detectors are not designed with the low output leakage needed to support such long time constants.  That means using a discrete implementation with low leakage analog switches or maybe low leakage diodes.  I was working on a design when squirrels chewed through the cable on my GPS18x and ran off with it; after that I lost interest.  I was more worried about adding lock detection and fast settling from startup than achieving a long time constant.

FYI, here are measurements that I've made of the period of the 1 PPS output of some GPS receivers and GPSDOs.

Those are consistent with my own measurements of a Garmin GPS18x which can operate at 5PPS.  It was easy enough to see that the output pulse was aligned with the roughly 32 MHz clock inside the receiver so under ideal conditions, the pulse was jumping around by 33 nanoseconds.  The GPS mounted outside made a pretty good outdoor temperature sensor by monitoring the difference between the GPS receiver clock and GPS pulse.

Squirrels.. now it all starts falling into place... *wink*

[edpalmer42]

Wow, you guys are way over my head in this. I was looking at my Jupiter module and tried to trigger that against my OCXO. Not sure what this is telling me...

top is 10kHz and I tuned my ocxo to sync with it.

You're seeing a combination of jitter and drift.  You can't tell what's coming from the Jupiter, the OCXO, or both.  Over time, the OCXO trace will just continue to wander across the screen.  If your scope has infinite persistance, you'll just see a continuous smear instead of a trace.

I've never found it very useful to look at these signals with a scope.  Once I've confirmed that the waveform is more or less as expected, I switch to a time interval counter so I can measure speed, drift, jitter, etc.  Basically, measure from the rising edge of the 1 PPS to the next rising edge of the OCXO.  This gives a much more precise view than the scope or even a frequency counter.

By the way, which OCXO are you using?

Ed

[David Hess]

Notice also that Miller's circuit was able to realize similar results to the other units at higher values of Tau.  That's not to say that hardware is superior to software.  Software can do tricks that hardware can only dream of.  eg.  Dual time constants for acquiring vs. tracking or aging compensation during holdover.

Dual time constants are common in long time constant analog designs to improve lock time.  In PLL designs where the reference is variable frequency, there are some clever analog tricks which can be used to vary the loop gain with frequency (1) so the time constant (and settling time) follows the reference frequency.  I was considering something similar where the correction was the square or non-linear function of the error and this would also have allowed analog lock detection.  Of course this makes the analog design more complex and a partial or all digital design relatively less costly.

Here is a summary of my "simple" idea.  On the leading edge of the reference pulse, use the phase detector to produce a voltage proportional to the phase error.  A window comparator can use this to provide a lock signal.  Then use a timed second stage to transfer charge proportional to that voltage to the integrator which is driving the voltage controlled oscillator.  Since the integrator is not connected to anything except when charge is transferred, offset, drift, and noise are more easily controlled.  Breaking the phase detection and integrator stages up allows lots of possibilities for non-linear control.  I know from experience that integrators in circuits like this can achieve better than 1uV/second drift.

(1) This is surprisingly easy to do.  National Semiconductor included it in one of their PLL application notes although I have never seen it used in real life.

[metrologist]

Wow, you guys are way over my head in this. I was looking at my Jupiter module and tried to trigger that against my OCXO. Not sure what this is telling me...

top is 10kHz and I tuned my ocxo to sync with it.

You're seeing a combination of jitter and drift.  You can't tell what's coming from the Jupiter, the OCXO, or both.  Over time, the OCXO trace will just continue to wander across the screen.  If your scope has infinite persistance, you'll just see a continuous smear instead of a trace.

I've never found it very useful to look at these signals with a scope.  Once I've confirmed that the waveform is more or less as expected, I switch to a time interval counter so I can measure speed, drift, jitter, etc.  Basically, measure from the rising edge of the 1 PPS to the next rising edge of the OCXO.  This gives a much more precise view than the scope or even a frequency counter.

By the way, which OCXO are you using?

Ed

MTI 220 series, are these of any value anymore?
http://www.mti-milliren.com/hirel_220.html

It took some time to get these signals synchronized. My counter can only measure 0.1Hz resolution at 10 MHz with a buffer.

I am tending more to scrapping this and buying an off the shelf solution, but something without questions.

[edpalmer42]

MTI 220 series, are these of any value anymore?
http://www.mti-milliren.com/hirel_220.html

It took some time to get these signals synchronized. My counter can only measure 0.1Hz resolution at 10 MHz with a buffer.

I am tending more to scrapping this and buying an off the shelf solution, but something without questions.

That looks like a nice OCXO.  1 PPB per day and 5e-12@ 1 sec.  Aging isn't really relevant when it's locked, but that short-term stability would give good performance in a GPSDO.

You're seeing the classic problem of trying to measure and compare frequencies of these signals.  To get better resolution, you have to use long gate times, but that blinds you to things going on at intervals shorter than your gate time.  The solution is simple - buy better test equipment!   

Ed

[DaJMasta]

If you want a simple digital way to do your disciplining to a PPS signal, it doesn't take much to make a counter that will operate at 10MHz, and then you just read out the value every PPS signal and use that as the basis for your phase adjustment.  It's once again going to be prone to jitter and such from the disciplining system, but you can build into your system the slow reaction time to GPS adjustments to decrease the impact of the jitter.  The difficulty here is that things need to be synchronous and you need a high resolution DAC to drive the VCO.  You could do a decent job with TTL to divide down the oscillator and a regular micro, or a fast enough micro (you MUST be able to detect every pulse, so several times the nyquist of the oscillator clock is needed, at minimum), but you'll run into problems from interrupts and such - you really want the counting and comparison to the PPS to be totally synchronous, and it seems like the common tactic is to use  CPLD where you can divide the clock domains.

The higher frequency clocks are more useful for traditional PLL designs, but you've basically got the same thing described above happening in the GPS module generating that clock.  The received GPS signal gives you seconds, though they are accurate to many zeroes, so PPS is the simplest output for the GPS module, even if they can be tough to deal with in some designs.

[MosherIV]

So I was thinking of using something like STM32F4 micro to do the freq count using the PPS as the gate source. The clever part is that I was planning on clocking the STM32F4 directly from the 10MHz oscillator. I think this means that the STM32F4 counter will always be in synch with the oscillator (am I wrong??)

As I said before, I found there are some articales on the WEB on doing digital PLL in software, to adjust the oscillator freq.

Not sure about locking the 10MHz to the PPS if there is jitter on the PPS. Surely you are better off with the short term stability of the OCXO and using PPS long term to check and correct for freq drift of xtal

[DaJMasta]

Clocking it from the reference will probably do the trick, I think an F4 series is probably way overkill for it, though - unless you're actually trying to timestamp the changes.

After posting that I realized there was an easy way to get the jitter-resistance built into just a ttl circuit - just make the counter count over several PPS before evaluating the difference from the target.

You could also read the counter output directly into a micro, do all your software averaging algorithms, and then drive a DAC with I2C or something, which if you're going to be waiting for a full second worth of counting, makes the speed and stability requirements of the micro near nothing.

So something like:
10MHz VCO into two daisy chained 12 bit counters.  Outputs of the counters into 3 8 bit storage latches.  PPS input triggers the latches to store their input, next 10MHz cycle stops the reading, next 10MHz cycle resets the counters.

Micro reads the latched outputs, adds 2 to the cycle count, does whatever averaging you want to reduce the impact of jitter, then I2C or I2S to the DAC (I2S is probably simplest because audio DACs are cheap and high resolution).  Then that feeds into a buffer amp which feeds back into the VCO.

Maybe $10-15 in ttl, a cheap micro, a cheap dac, an opamp, your VCOCXO of choice, a PPS signal from a GPS, and a bit of programming.  Could be a pretty capable little device and is probably less fiddly than trying to breadboard up a good quality analog PLL (especially when you can do so much for adjustments in the micro).

[David Hess]

The difficulty here is that things need to be synchronous and you need a high resolution DAC to drive the VCO.

The high precision DAC in a digital design is what prompted me to look for alternatives leading to a charged pumped analog design which originally was a digital design with the charge pump replacing the precision DAC.

[cdev]

These could be used with an additional microprocessor to control it.


http://www.analog.com/en/products/rf-microwave/pll-synth.html

[SKHILLBILLYSlures]

I was probing the depths of the internet and whilst search for a viable wifi jammer circuit strictly for home use. I found the wonders of the Motorola mc145151 in the schematic I veiwed it was being used as a GPS signal jammer. The ic however appears to perfectly capable of being configured to operate a smooth 10MHz and the ic structure also utulized a VCO

[mark03]

This discussion brings up a question that's been nagging me for a while.  Keep in mind I am not a time nut nor a GPS expert.

As I understand it, the typical homemade GPSDO design uses an OCXO and a GPS module with the 1 PPS output averaged over very long intervals.  The long time constant is necessary to average out the jitter in the PPS signal, which is due to the PPS pulses happening only at transitions of the GPS module's free-running internal clock.  Hence "hanging bridges" and "sawtooth correction" etc.  You also have to pay extra $$ (usually a factor of two or more) for a GPS module with the correct firmware features for timing applications.

So a fair bit of effort is being expended to reduce jitter which [arguably] should never have been introduced in the first place.  I.e., if the GPS module itself were built around a stable oscillator, and that oscillator were disciplined in the course of its normal operation, presto, you'd have your GPSDO already.  Reading through hamster_nz 's thread on building a GPS receiver around a Skyworks front-end chip, I was wondering what the minimal system implementation would look like, if all you want is a stable frequency reference, not position nor time?  Are the GPS carrier frequencies locked to their atomic clocks, such that if you decode the PN sequence from one satellite, you could just do carrier tracking and have your accurate frequency reference right there?  Or is there some reason a multi-satellite solution is required for accurate *frequency* that I don't understand?

[MosherIV]

As I understand it, the typical homemade GPSDO design uses an OCXO and a GPS module with the 1 PPS output averaged over very long intervals.  The long time constant is necessary to average out the jitter in the PPS signal, which is due to the PPS pulses happening only at transitions of the GPS module's free-running internal clock.  Hence "hanging bridges" and "sawtooth correction" etc.  You also have to pay extra $$ (usually a factor of two or more) for a GPS module with the correct firmware features for timing applications.

So a fair bit of effort is being expended to reduce jitter which [arguably] should never have been introduced in the first place.  I.e., if the GPS module itself were built around a stable oscillator, and that oscillator were disciplined in the course of its normal operation, presto, you'd have your GPSDO already.  Reading through hamster_nz 's thread on building a GPS receiver around a Skyworks front-end chip, I was wondering what the minimal system implementation would look like, if all you want is a stable frequency reference, not position nor time?  Are the GPS carrier frequencies locked to their atomic clocks, such that if you decode the PN sequence from one satellite, you could just do carrier tracking and have your accurate frequency reference right there?  Or is there some reason a multi-satellite solution is required for accurate *frequency* that I don't understand?

Hi, I am not time nut either and my understanding is not perfect either but here is my answer to you:
Only the simpler/cheaper gpsdo implementatiins user the 1pps, the better more advanced and stable ones use a better gps module the are able to derive a 10KHz clock from the agregation of the locked gps signals, not sure what they are agreagating, you might be right that they are based on the carrier waves byt I do not know.

The hanging bridge or saw tooth effect on the 10MHz clock is due to poor implementation in adjusting the OCXO. The adjustment should be filtered, ir to put it in simplist terms the adjustment is done over a period of time so that it is 'blended in'. Instantly applying the correction will result in something looking like hanging bridge or saw tooth.

The more advanced gosdo work by phase locking the 10MHz to the 10KHz, this allows for jitter free counting the error. Without PLL the 10MHz to the gps reference will result in a jitter in the error count BUT if you PLL to a jittery 1pps you will introduce the same jitter in the 10MHz, so in my oppinion it is better to live with the 1 count jitter when using 1pps.

I do not know how the better gps modules lock the 10KHz signal to what from the gos satellite, you might be right it might be the carrier signal.

[David Hess]

As I understand it, the typical homemade GPSDO design uses an OCXO and a GPS module with the 1 PPS output averaged over very long intervals.  The long time constant is necessary to average out the jitter in the PPS signal, which is due to the PPS pulses happening only at transitions of the GPS module's free-running internal clock.  Hence "hanging bridges" and "sawtooth correction" etc.  You also have to pay extra $$ (usually a factor of two or more) for a GPS module with the correct firmware features for timing applications.

The jitter in the PPS signal is not the only error source.  The GPS timing solution itself has considerable uncertainty and once the timing error from a good local oscillator overlaps with the error from the GPS, the jitter in the uncorrected PPS signal becomes less important.

So a fair bit of effort is being expended to reduce jitter which [arguably] should never have been introduced in the first place.  I.e., if the GPS module itself were built around a stable oscillator, and that oscillator were disciplined in the course of its normal operation, presto, you'd have your GPSDO already.  Reading through hamster_nz 's thread on building a GPS receiver around a Skyworks front-end chip, I was wondering what the minimal system implementation would look like, if all you want is a stable frequency reference, not position nor time?  Are the GPS carrier frequencies locked to their atomic clocks, such that if you decode the PN sequence from one satellite, you could just do carrier tracking and have your accurate frequency reference right there?  Or is there some reason a multi-satellite solution is required for accurate *frequency* that I don't understand?

Correcting for propagation errors and relativistic Doppler shift requires knowing the receiver's location with respect to the satellites.  You could track the carrier and timing from one satellite but it would be much like monitoring the various NIST broadcast frequencies which also suffer from propagation errors and Doppler shift limiting their accuracy.

[mark03]

So a fair bit of effort is being expended to reduce jitter which [arguably] should never have been introduced in the first place.  I.e., if the GPS module itself were built around a stable oscillator, and that oscillator were disciplined in the course of its normal operation, presto, you'd have your GPSDO already.  Reading through hamster_nz 's thread on building a GPS receiver around a Skyworks front-end chip, I was wondering what the minimal system implementation would look like, if all you want is a stable frequency reference, not position nor time?  Are the GPS carrier frequencies locked to their atomic clocks, such that if you decode the PN sequence from one satellite, you could just do carrier tracking and have your accurate frequency reference right there?  Or is there some reason a multi-satellite solution is required for accurate *frequency* that I don't understand?

Correcting for propagation errors and relativistic Doppler shift requires knowing the receiver's location with respect to the satellites.  You could track the carrier and timing from one satellite but it would be much like monitoring the various NIST broadcast frequencies which also suffer from propagation errors and Doppler shift limiting their accuracy.

Yeah, that makes sense.  I suppose if you knew both your own location (based on an earlier survey) and the satellite positions (based on a reasonable ephemeris), you could correct the Doppler.  But there would still be more residual error than if one performed the full solution using many satellites?

It still seems like one could build a GPS receiver which disciplines its own LO (perhaps an OCXO), rather than the indirect approach of using 1PPS.

[jpb]

It still seems like one could build a GPS receiver which disciplines its own LO (perhaps an OCXO), rather than the indirect approach of using 1PPS.

The Ublox LEA-M8F does this (it is not an OCXO but it is an oscillator disciplined to GPS) but I think it would still be best to combine it with an external OCXO and pll anyway.

https://www.u-blox.com/en/product/lea-m8f-module

Ublox's timing white paper is quite interesting as well:
https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_%28GPS.G6-X-11007%29.pdf

[DaJMasta]

It still seems like one could build a GPS receiver which disciplines its own LO (perhaps an OCXO), rather than the indirect approach of using 1PPS.

They make these, most GPS receivers designed for timing or with any sort of high frequency output will have a TCXO or better disciplined to the GPS source.  I think PPS takes less hardware, since you can basically just interpolate in a micro when the second would tick over (GPS timestamps give you down to microseconds), so you're basically just using that stability of your micro's clock and software as the control loop.  There are a number of modules that advertise that they include one sort of high stability oscillator or another, and you need at least a decent baseline just to get a good PPS signal, so it is very common for them to be integrated, even if it's less common for their output to be directly available.

[Vgkid]

I was thinking about this when at the gym. What if you do it this way. Power on?wait for gps lock? wait for ocxo heater to reach operating temp? use adc to fll ocxo efc pin to 1pps of gps unit ( slowly, just needs to be close. Might not take to  ) after it locks ? switch system to pll(it can go a lot slower, I was thinking about a analog loop...). Just my thoughts.

[0xPIT]

Hi,

I'm not sure if I'm on topic: I also intend to build a cheap & low parts count GPSDO.

Hardware I have at hand are a 10MHz OCXO and a NEO 7M, plus several micros. I really want to opt to use a ESP32 module, so it would be powerful (LCD, etc.) and cheap and I want to gain some experience with an actual project that can be released freely later.

I was thinking to implement a DPLL, but I've read several times (can't remember where) that it's "problematic". I fail to see the problems, though – can anyone enlighten me?

The ESP32 has hardware timers and even hardware pulse counters, I guess it should be possible to compensate jitter caused by code execution, as this is deterministic. It seems to be straight forward to feed a NEO Module's 48/n MHz, as well as the 10MHz of the OCXO to external counter inputs and measure lead/lag timing, and after some IIR low pass filter drive the VCO input of the OCXO – what do you think?

So, what are arguments against a Software DPLL? Does anyone have a pointer to read?

Cheers

  - pit


PS: The ESP32's firmware only support 40 MHz crystal oscillator for now if you want to use Wifi and Bluetooth, but that would be ok without for this application, so the OCXO could serve as clock source for the ESP32, too.

[MosherIV]

  The ESP32 has hardware timers and even hardware pulse counters, I guess it should be possible to compensate jitter caused by code execution, as this is deterministic

If the pulse counter is truely a hardware counter, you do not need to comprnsate for code execution. The pulse counter works independantly of the processor.

So, what are arguments against a Software DPLL?

Nothing from me, that was what I was proposing.
You will have to average over thousands of seconds to overcome jitter in the 1PPS of the NEO7M.