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

[metrologist]

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.

I hope to do something like what this fellow did, but maybe use his idea of clocking the micro with the 10MHz ref.

http://k6jca.blogspot.com/2016/02/an-arduino-based-gps-disciplined.html

I also started to collect parts to make a Brooks Shera design (maybe not low parts count).

http://www.rt66.com/~shera/index_fs.htm

[0xPIT]

  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.

Yes, but the hw timer will not work alone, there will be code involved, so some compensation will be necessary.

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.

With the Neo7 Series, you can set an arbitrary output frequency.

[MosherIV]

but the hw timer will not work alone, there will be code involved, so some compensation will be necessary.

Then the hw timer implementation is not up to the job!
HW timer counters should be able to latch the count without sw intervention. You should be able to just read out the count.
They should also be able to start the next count without sw intervention.

Do not rely on the ESP32 clock to be accurate enough to gate your counter, it is 10 times worse than the clock you are trying to verify.
The 1pps should have something like 15ns jitter so is a better gate source for the timer.

With the Neo7 Series, you can set an arbitrary output frequency.

The Neo7 48MHz clock cannot be divided down to 10MHz evenly, this will result in the 10MHz freq having significant jitter. Do a search, I saw some people already tried to use the freq out of a gps as a clock source, they found there was jitter due to the divided down ratio.
In addition, the M series is the positioning model so the clock on it is not temperature compensated so any temperature variation will cause enough clock variation that it is not worth it.

[tggzzz]

but the hw timer will not work alone, there will be code involved, so some compensation will be necessary.

Then the hw timer implementation is not up to the job!
HW timer counters should be able to latch the count without sw intervention. You should be able to just read out the count.
They should also be able to start the next count without sw intervention.

Just so.

The XMOS xCORE processors recognise that common problem quite neatly. Each i/o port contains a counter that operates at up to 250MHz/4ns. You can setup the "FPGA-like" ports so that

• an input is captured at a specific count, or
• when an input changes, or is equal or not equal to a specified value, the input is captured and the time is recorded, and
• there are SERDES options, and
• s/input/output/

Plus the timing of each core is deterministic, so that the IDE will tell you whether you meet timing constraints before you execute the code.

[David Hess]

Just so. There are two techniques to reduce that jitter: only select frequencies that are sub-harmonics of the 48MHz clock, or use the output to drive a high-Q filter.

If you do the latter and the filter has a time constant of ~1s, then the jitter ought to be the same as for a 1pps output

A high Q filter introduces its own problem in the form of variation of phase and group delay versus temperature.

[CJay]

Integer divisors of the 48MHz clock on the Neo GPS modules work fairly well, there is significant jitter if you don't use an integer, it's that bad you can see it on a 'scope even though a frequency counter will show a solid 10MHz for instance.

Calling it a divisor is being generous as well, I believe it 'drops' clock cycles to get the correct number of pulse per second.

A HW counter, as others have already said, should, once configured, work independently of software, PICDiv is a good example of this and it achieves ridiculously good performance from an extremely simple 12F series PIC

[Gyro]

Integer divisors of the 48MHz clock on the Neo GPS modules work fairly well, there is significant jitter if you don't use an integer, it's that bad you can see it on a 'scope even though a frequency counter will show a solid 10MHz for instance.

Calling it a divisor is being generous as well, I believe it 'drops' clock cycles to get the correct number of pulse per second.

A HW counter, as others have already said, should, once configured, work independently of software, PICDiv is a good example of this and it achieves ridiculously good performance from an extremely simple 12F series PIC

As you say, there will be be severe jitter if you don't do an integer divide of the 48MHz clock. From my experiments in https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133 there is still some jitter for an integer divide (1MHz). This is very much lower but still sufficient to be visible on a scope, viewed against an OCXO (I measured it as about 25ns P-P).

[CJay]

As you say, there will be be severe jitter if you don't do an integer divide of the 48MHz clock. From my experiments in https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133 there is still some jitter for an integer divide (1MHz). This is very much lower but still sufficient to be visible on a scope, viewed against an OCXO (I measured it as about 25ns P-P).

Yeah, sorry, I should have been a little more verbose and added that there is still jitter with an integer divisor but it's much reduced.

Even with the jitter at 10MHz it still checks out to two decimal places on my counters but at 8MHz it's even better.

[Gyro]

Yes, I also found the jittery 10MHz gave a very consistent reading with my counter on a 10s gate time. It was almost enough to put me off bothering with OCXO locking experiments. 

[cdev]

All GPS's need some form of fairly good temperature compensation or they will lose position lock when situated in an environment where the temperature changes quickly.

[mark03]

A HW counter, as others have already said, should, once configured, work independently of software, PICDiv is a good example of this and it achieves ridiculously good performance from an extremely simple 12F series PIC

Something else to keep in mind is that most MCU timer/counters run in the clock domain of the MCU; for this reason they put reclocking logic (a couple of D flip flops clocked by the MCU clock) on all I/O pins.  This is easily recognized by comments in the reference manual to the effect of "the MCU clock must be greater than twice the frequency on this input pin".  In a GPSDO, it seems to me that this will introduce some additional uncertainty in the count values.  My understanding (correct me if I'm wrong) is that the PIC MCUs have timer/counters which can run in their own clock domain, i.e. if you set one up to count external pulses, it is really running in that external clock domain.  The reclocking logic is then on the readout (register) side of the timer/counter.  This always seemed to me like an obvious good idea, and I'm somewhat disappointed that none of the ARM Cortex-Ms I use feature this type of peripheral.

Another way around this would be to clock the MCU from the disciplined oscillator.