On the mystery voltage regulator: most OCXOs also provide a regulated reference output on the pin that's marked N/C on this device. This reference is important because the tuning voltage is scaled relative to some reference voltage, and a modulation in that reference voltage can be seen as an out-of-phase modulation in the tuning voltage. Hence, bringing a pristine reference out of the oven is the cleanest option. Second best is to place an external regulator close to the oven, as they've done here.
That's what I use in the GPSDO in one of my projects. The internal voltage reference powers a 10bit DAC that we dither to tune the OCXO. If the microcontroller has a voltage rail just for it's internal DAC, that would be the best way to run it. You could drop the opamp and voltage reference from the design and just keep the RC filter.
The opamp would still be a good idea no? That RC filter output will be very susceptible to noise and we wish the OCXO tune input to be as stable as possible. When I built one of these a friend had me route the opamp output as a guard ring around the entire DAC to VCXO tune net.
I'm not sure: I remember seeing comments in the past about crappy Vref outputs of OCXOs (when compared to external Vrefs) and just today, I saw another such comment though I don't remember where either.
I've studied quite a bit of GPSDO schematics, but none of them are using the internal Vref. Though that maybe because these designs allow for different OCXOs, some of which don't have a Vref output.
"Lastly, I'm not going to use the Oscilloquartz reference voltage to power the frequency setting circuit. It seems the logical thing to do, but this so called reference voltage is anything but a reference voltage. They are typically created by using a zener (reference) diode like the TL431, but that is simply not good enough as you will see."
In some industrial GPS receivers, there was a FPGA, a very capable ADC, and a PLL. Logic was split between the analog incoming section and the digital processing section. Maxim components were used frequently as it they had excellent engineering support (sampling esp.) from the vendor. IIRC, there were Flash EEPROMs rated for 10k block writes (only!) but were reliable up to low 100k's.
> It’s a generally accepted truism that once you’ve acquired your first frequency counter, you slowly get sucked into the Cult of the Time Nuts and their never ending quest for increasingly accurate time measurements.
I only narrowly managed to escape this fate after acquiring an HP 5345A, a massive fifty pound brick that was the fastest (and thus accuratestest) reciprocal counter for some time. It's a pretty strong black hole for money.
I’m currently at 3 frequency counters, but past weekend at the Silicon Valley electronics flea market, I managed to walk away without buying that 4th one.
I managed to sell the HP after acquiring a (somewhat) smaller and (much) lighter Philips counter which also uses a 500 Mhz reference clock so it can do more countings per counting. So I only very briefly had two. Glad it didn't exponentially escalate at that point: https://i.imgur.com/NCKDQEh.jpg
> There is no such phase detector or ADC on this PCB, so it’s a good guess to assume that the TM4313 uses frequency locked loop.
They almost certainly implemented a digital PLL in the micro that compares the 10 MHz clock signal to the 1 PPS output of the GNSS module. Using a frequency lock would lead to a residual drift with respect to the GNSS time scale.
You're absolutely right about the drift, but an FLL is sufficient for cases where you case about the frequency and not about the exact position of the 1PPS output.
E.g. when using a GPSDO to drive or calibrate frequency counters, spectrum analyzers, signal generators, and similar kind of equipment.
There are many GPSDOs out there that are FLL only.
I'm not sure how you'd implement a pure digital-only phase detector inside an LPC1752. The precision of measuring the phase would be pretty terrible when the internal clock is only, say, 100MHz?
Edit: I should be able to check this by putting the GPS module 1PPS and the GPSDO 1PSS output on the scope.
> The LPC1759/58/56/54/52/51 include four 32-bit timer/counters. The timer/counter is designed to count cycles of the system derived clock or an externally-supplied clock. It can optionally generate interrupts, generate timed DMA requests, or perform other actions at specified timer values, based on four match registers. Each timer/counter also includes
two capture inputs to trap the timer value when an input signal transitions, optionally generating an interrupt.
Time-tagging the transitions of the 1PPS signal (and subtracting 100000000 at each transition) directly gives the phase difference measured in clock cycles. At 100 MHz clock frequency, the resolution is 10 ns which is well below the timing jitter of a GNSS 1PPS output. The OXCO can then be steered using a very slow feedback loop (in order not to spoil its short-term stability).
> At 100 MHz clock frequency, the resolution is 10 ns which is well below the timing jitter of a GNSS 1PPS output.
I own a more expensive GPSDO model from the same vendor and I can confirm that the TIC output is at 10ns resolution. TM4313 is being sold at 1/3 price of mine, I'd be very surprised if its TIC has a higher resolution.
I thought that 10ns was too coarse, when most PLL-based GPSDO get much higher accuracy with 8-bit ADCs. But maybe that just doesn't matter enough when the input jitter is very high to begin with.
Even the simplest TCXO is more stable than the GNSS up to a few ten s. The OCXO has the crossover at a few hundred s, and the Rubidium atomic clock at over one thousand s.
At these time scales, the jitter of the 1PPS measurement averages out very well and should not be a serious limitation.
All PLL-based GPSDO designs that I've seen measure the difference between the rising edge of the 1PPS signal to the next rising edge of the 10MHz clock (or vice versa). You're basically using the kind of analog interpolation that's also used in frequency counters to get sub-10MHz clock cycle granularity. (See here: https://tomverbeure.github.io/2023/06/16/Frequency-Counting-...).
I understand that you can still implement a PLL with a pure digital 10ns counter (I've once designed one to create a 12.288MHz I2S clock out of a very jitters 48kHz audio sample tick), but I'm wondering what the benefits are of using the analog interpolator.
If the input 1PPS signal is so jittery, when do you get diminishing returns in increasing the precision of the pulse-to-pulse measurement?
Oh, I am so happy someone posted about this topic here.
Does anyone know whether I can use a GPSDO with an SDR to have very accurate timestamps of each I/Q sample? I don't just want the sampling to run at the correct phase, and without drift, I want a timestamp. Could be any SDR, but I'd prefer something reasonably priced (under $1000). Most SDRs will happily take the 10MHz reference clock, but are not be able to ingest or output time.
I did this back in the day using a ublox LEA-M8F module for my PhD work following the instructions posted here:
http://www.opendigitalradio.org/lea-m8f-gpsdo
I also experimented with RTK which this module is capable of.
Now there's probably a more up to date ublox module available which could provide even better results using multi frequency GNSS etc.
If you want to build something, ITU-T G.703 + G.8271 (both available for free) outline how this works for telco equipment. There's a low-speed serial channel alongside the PPS / 10MHz signals, carrying the actual wallclock time. It's transported over RS422 on a RJ45 connector for PPS + side channel, SMA (or other coaxial connector) for 10MHz reference. Some devices also accept plain NMEA stanzas as input to read the clock from.
(I always thought RS422 for the PPS signal is a bit fishy, not sure how jitter-y those transceivers are. That said the hardware I've seen uses >25Mbaud high-speed transceivers [ISL3180, THVD1452], maybe those are fine in that regard.)
A modern 5G base station kinda does what you describe. All SDR these days anyway :)
Now that you mention it, I remember doing this now. Mine was not for SDR, but data acquisition all the same. I had the PPS and 10MHz signals go into an fpga, while the GNSS UART went to the CPU. The FPGA could be programmed with the current time which was then kept up to date internally. As data was acquired the timestamp was married to each sample and passed around one to one.
Yeah this should work. I was hoping to avoid having to add an FPGA.
On the other hand, BladeRF has an FPGA on board, perhaps it can ingest PPS. It will still be quite a bit if work to write for the FPGA, but at least I'll not have to design PCBs, which is way above my skill level.
I thought about it some more, you might be able to do this entirely with an off the shell SDR.
If you have a device that can record multiple bands simultaneously, and preserve timing between them, then you may be able to record both your target band and the GPS band and then use software later to reconstruct the time out of the GPS recording.
This is a very interesting idea. I think I could use a BladeRF, it has two input channels. I hope the two channels are perfectly synchronized, by glancing at people's projects it seems that they are.
I believe the GNURadio folks have implemented at least some of this, so it might be worth poking around GNURadio for a bit, Tags are what you're looking for.
Funny — that cheap GPS module seems to be using u-blox NEO footprint. I knew there were knock-offs of those, guess now I have a part number. I wonder how it performs, compared to a genuine u-blox module…
The serial port reports a clock of 100MHz inside the LPC1752. If that's connected to the PWM generators, you should be able to get away with 16 without any dithering.
...at least that's my best guess.