UBLOX GPS waveform jitter: experiment shows the cause

There are 2 different situations that result in signal jitter from uBlox GPS, as follows:
Situation 1: Jitter happens whenever the chosen output frequency does NOT divide evenly into 24 MHz (where 24 MHz is the frequency of the uBlox onboard TCXO). This jitter happens because the uBlox can only produce these "odd" frequencies by mixing "even" frequencies of different wavelengths. Note that this type of jitter happens whether or not a GPS satellite has been acquired. Avoiding this first type of jitter is simple: choose output frequencies that divide evenly into 24 MHz.
Situation 2: Jitter occurs after GPS satellite acquisition. Note that this type of jitter occurs regardless of the chosen output frequency. There does not appear to be a workaround to avoid this situation. This jitter seems to be due to the way time is maintained by the uBlox device before vs after satellite acquisition. Prior to satellite acquisition, the internal TCXO is relied upon for all timing. Thus, generated output frequencies are produced and counted by the same TCXO clock. Thus, they remain in sync and jitter is avoided. After satellite acquisition, the uBlox relies on precision GPS time and mixes different frequencies in order to produce the desired output frequency (cycles per second). This mixing of frequencies causes jitter. As the video demonstrated, the output frequency is primarily controlled by the physical properties of the onboard oscillator, while frequency measurements/counting is controlled by the method of timing (GPS vs TCXO). The frequency of the resulting jitter depends on the difference between GPS clock ticks and the uBlox oscillator's clock ticks.
Conclusion
------------------
In both situations, the root cause of jitter is fundamentally the same: The desired signal's wavelength does not fit evenly between clock ticks. Since wavelength and frequency are related by the speed of light, there is nothing that can be done other than to mix different frequencies, in order to output the requested cycles between clock ticks. This causes output jitter.
If you want to use your uBlox GPS unit as a limited signal generator and can accept an inaccuracy of a few Hertz, choose an output frequency that divides evenly into 24 MHz and turn off the satellite networks using uCenter software. This should produce a jitter-free output signal.
Correction
----------------
The NEO-M8N has a TCXO -
Temperature-Compensated Crystal Oscillator (not an oven controlled crystal oscillator).

[@SuperSerNiko97]

A channel by the name of @TheHWcave showed that the jitter was caused when the PPS frequency is not a divisor of the internal oscillator frequency which should be 48 MHz if I’m not mistaken.
This is the video: th-cam.com/video/M6SmdqMA-Dg/w-d-xo.html

[@philipgiacalone5605]

Thank you for the link. Note that jitter will also occur after getting a GPS fix, even when the frequency is a divisor of 48 MHz, as demonstrated in this video.

[@SuperSerNiko97]

@@philipgiacalone5605 Basically there are two sources of jitter then

[@philipgiacalone5605]

@@SuperSerNiko97 Yes, there are two different scenarios. The root cause of both is the same: the generated frequency is not a perfect divisor of the clock frequency (so the waves/cycles don't fit perfectly between clock ticks).

[@TrimeshSZ]

OK, I did some testing using an LEA-M8T-0-10 module with f=12MHz, 50% duty cycle, lock to GNSS, and I can't see any jitter - it's a clean 12MHz square wave. I also measured it on a counter in stats mode (HP53131A, Ref from a FE5680 Rb standard) over 100 cycles with a 1s gate time and got:
Fmin = 11,999,999.975Hz, Fmax = 12,000,000.039Hz - high time was min = 40.7ns max = 43.2ns - since 1 tick of the 48MHz clock is about 20ns this is likely just noise from my quickly hooked up test setup.

[@philipgiacalone5605]

That is very interesting, thank you. I see from the spec sheet that the LEA-M8T has an RTC that provides a more accurate time base. That feature may partially explain the cleaner analog output. I will have to get one and try it, thank you.

[@philipgiacalone5605]

Btw, are you using a scope and triggering on the GPS signal? That hides the jitter and is why I'm triggering on a separate signal in my video. You could trigger on the Rb signal in your testing, for example, and then observe the GPS channel for jitter. Curious to hear what that might show...

[@TrimeshSZ]

@@philipgiacalone5605 I tried several approaches - one was just to use the scope on it's own, one was to use the Rb in one channel and trigger off that with the holdoff set to 6 cycles of the reference (which should correspond to 5 cycles of the 12MHz) and the last was to use an RF signal generator (an ancient Marconi 2019A, but it still works) set to 12MHz and connected to the Rb. I couldn't see any jitter with any of the setups I tried.

[@chasingcapsaicin]

What is the expected GNSS time base expected to be, also wouldn't one expect to see a shift depending on time of day as well?

[@philipgiacalone5605]

@@TrimeshSZ Thanks for that added info. Very interesting, indeed. If the tick period of the LEA-M8T's clock and oscillator is spot-on with the GPS time period, then the jitter problem would disappear (for frequencies that divide evenly into 48 MHz). It's curious how they could achieve that. Another experiment you might try is heating the LEA-M8T and see if jitter returns. Seems to me the output frequency would still be controlled by the physical properties of the oscillator. So if the frequency changes while the GPS timebase doesn't, jitter should return. BTW, all of this playing around with GPS signals has been out of curiosity and for fun. It's an interesting topic, imo, and I appreciate learning from your results, too.