OCXO calibration

[Gyro]

The frequency outputs are not locked to GPS.

Do you have a reference for that statement?

There's sawtooth error on the frequency outputs, whatever frequency you program them to (there's no dedicated 1pps output). That's why you have to visually ignore the jitter when comparing on the scope - just watching the long term trend.

[edpalmer42]

As far as I know both frequency outputs are locked to the GPS

The frequency outputs are not locked to GPS.  They are just divided down from the free running GPS board oscillator via a DDS.   If they could lock the osc and GPS together (like the Thunderbolts do), then there would not be any 1PPS sawtooth error.

Is this a question of 'definition'?

Saying that the frequency isn't locked to GPS suggests to me that over time, the 10 MHz and the 1 PPS could drift apart.  I don't think that's true.  My understanding is that the rising (usually) transition on the 1 PPS output happens as close as possible to the actual time as broadcast by GPS.  Since the resolution is limited by the software and the clock speed of the GPS receiver, there is jitter which, over time, generates the sawtooth waveform.

The method of generating the 10 MHz signal will vary from model to model, but again I would expect something that relates back to the 1 PPS.  One receiver I looked at output shorter or longer pulses so that the average came out to exactly 100ns (i.e. 10 MHz).  I've sometimes seen warnings that these outputs should be cleaned up with a phase-locked oscillator to remove the jitter before trying to use them.

As you stated, a processor clock that was locked to GPS should be able to minimize, if not remove, sawtooth error.

Ed

[Gyro]

Yes, you have it exactly Ed.

I've sometimes seen warnings that these outputs should be cleaned up with a phase-locked oscillator to remove the jitter before trying to use them.

Yes, that's in the Ublox timing app note that I posted the link to. The human eye does a pretty good job though. I've done it, Lars has done it, Uncle Bob has done it.


EDIT:

As you stated, a processor clock that was locked to GPS should be able to minimize, if not remove, sawtooth error.

Of course the GPS is only able to output sawtooth correction data at low rate, iirc ic can be configured upto a few times a second on the ublox. Above that, you're down to removing the  sawtooth with a pll (or eye).

[texaspyro]

The Ublox output freqs are best described as "derived from" GPS rather than "locked to" GPS.   Adding and dropping pulses to keep the average frequency close to the desired value is a far cry from actually locking the oscillator frequency to the GPS data via something like a EFC input to steer the GPS TCXO.

[cdev]

How about "inspired by actual GPS signals" ?

[edpalmer42]

Or maybe "distantly related" to GPS.   

I've seen that output described as a Numerically Controlled Oscillator.

On the receiver I mentioned, I measured the 10 MHz output with an HP 5372A Time Interval Analyzer and got the following results:

"Measuring the period of 50M cycles shows two normal distributions, one centered at 94.0 ns (~20M readings) and
the other at 104.4 ns (~30M readings).  Apparently, this load 'brackets' the 100 ns point by sending short and long cycles on
an almost one-to-one basis that average to 100ns."

Later it was pointed out that the ratio of short and long pulses would vary from unit to unit and with temperature.  Note that the difference between the two periods of 10.4 ns represents a frequency of ~ 96 MHz.  This is sort of in the ballpark of the 'up to 120 MHz' note regarding the clock speed that was in the spec sheet.  The output might work if you were measuring frequency because the gate time of 1 to 10 seconds would be long enough to average out the jitter.  Other uses might not work as well.  The manufacturer didn't try to hide this behaviour and, in fact, had an application note on using a phase-locked oscillator to clean up the output.

I would still say that it was locked to GPS, but be careful - here be dragons!

Ed

[texaspyro]

I think the Ublox is running at 48 MHz and clocks the output on both edges -> 96 MHz.

Also, I don't know if their NCO actually attempts to compensate for TCXO drift or (I suspect) they are just attempting to align the 1PPS output to the nearest edge and report the difference via the sawtooth message and are not also adjusting the divisor for TCXO drift.

[lars]

The data sheet for the NEO-7M says this on page 10:

”The TIMEPULSE output generates pulse trains synchronized with GNSS or UTC time grid with intervals configurable over a wide frequency range. Thus it may be used as a low frequency time synchronization pulse or as a high frequency reference signal.”
https://www.u-blox.com/sites/default/files/products/documents/NEO-7_DataSheet_%28UBX-13003830%29.pdf

So maybe it is just a definition as Ed says. I call it locked, uBlox say synchronized and Mark derived from.

What I know from practical measurements is that the time pulse outputs stay enough close to other GPSDO's over a day to achieve at least 12 digits of accuracy.

Also the jitter on the time pulse is about 21ns p-p with a saw tooth like pattern (for short times as minutes). This is what you get with a free running 24MHz oscillator and the time pulses aligned to both edges of the oscillator. Another possibility is a 48MHz oscillator only aligned to one edge but I guess more on a 24Mhz oscillator.

The output pattern is also what you get with a NCO or a DDS with a 1 bit DA and a 48Mhz clock. I prefer to see it as a 1bit DDS as I have worked quite a lot with DDS’es and it makes it easier for me to think of jitter and spurious.
https://en.wikipedia.org/wiki/Direct_digital_synthesizer

If you say that the oscillator in the Trimble Thunderbolt is locked to GPS (Trimble probably should use even another word: disciplined ) I would also say that the free running oscillator + 1bit DDS is locked to GPS. The difference is the much lower jitter of the oven controlled oscillator in the TBolt compared to the DDS in the NEO-7M. The second difference is that the Tbolt has analog control of the oscillator and the NEO-7M digital of the DDS (oscillator). When of course the Tbolt has a timing receiver but that involves a lot of other errors outside of the internal GPS engine-oscillator “phase locked loop”.

By the way it is possible to read the frequency offset of the free running oscillator in the NEO-7M to nine digits (1ppb) every second with the UBX protocol.

Lars

[Gyro]

The Ublox output freqs are best described as "derived from" GPS rather than "locked to" GPS.   Adding and dropping pulses to keep the average frequency close to the desired value is a far cry from actually locking the oscillator frequency to the GPS data via something like a EFC input to steer the GPS TCXO.

Well I suppose that description is a getting a little bit closer than:

They are just divided down from the free running GPS board oscillator via a DDS

Progress indeed. 

There would be very little (zero) point in a GPS module outputting free running frequencies. As I explained, the frequency outputs, at whatever setting experience sawtooth error, yes that means that the closest edge of the 48MHz clock (yes I believe both edges are used, hence the 21ns P-P). Again that is very different from "Adding and dropping pulses" (citation definitely needed). What it results in is a clock with edge jitter (sawtooth error + if you are silly enough, any additional jitter resulting from non interger divide ratio).

If you really want, you can configure the frequency outputs to produce a free running clock in the absence of GPS lock (one of the many settings). Once the GPS lock is achieved, you can see the edge jitter start as it locks / 'derives' / synchronises / corrects the frequency. Of course in most cases it is more sensible to configure the outputs to stay at logic low or logic high until GPS lock is achieved.

Also, I don't know if their NCO actually attempts to compensate for TCXO drift or (I suspect) they are just attempting to align the 1PPS output to the nearest edge and report the difference via the sawtooth message and are not also adjusting the divisor for TCXO drift.

Again, there is no dedicated 1pps output, the mode of operation doesn't sudenly change when you go to 1pps.  To get 1pps, you just configure one of the frequency outputs to a 1000000uS period and set the mark/space to 10% or whatever you want. The only advantage of going down to low pps is that the serial or USB port can then output sawtooth correction data (configurable up to 10 times/sec iirc). [Edit:] I don't know how they do this either, presumably the former of your two suggestions as it applies at all frequencies, not just 1pps.

[texaspyro]

The Thunderbolt is rather unique in that the RF chain is derived from the OCXO.  That results in a 1PPS output that has no sawtooth error.  It also means that if the OCXO is off frequency by a small amount that  it won't track satellites.  You can set the DAC voltage to a setting that will cause loss of lock.

When I wrote the code that Lady Heather uses to "autotune" the disciplining parameters, I had to limit the DAC step it uses to calculate the EFC gain to around +/- 10 (?) mV in order to avoid losing lock.  I think I originally used +/- 500 mV.

[cdev]

These super affordable PIC based devices look potentially useful in helping ascertain the accuracy of a GPSDO given a decent frequency standard to use as a reference.

http://www.leapsecond.com/pic/

[Yannick99]

Codebird... you can build my oscillator. Easy and very cheap

https://www.instructables.com/id/GPSDO-YT-10-Mhz-Lcd-2x16-With-LED/

Just put your ocxo and the uC will adjust the vco by itself. No need of display or led if you want.

[usagi]

bg7tbl gpsdo master reference