Would there be any benefit of using a higher frequency GNSS time clock for PTP?

[meh301]

I have been working on the hardware design side of GNSS systems for a few years now (mainly for positioning), and am now looking into designing some hardware for timing purposes as well.

One thing I noticed in many PTP projects is the use of 1PPS timing signal, presumably at the default output of 1Hz, even if the module in use (F9T, etc) can be configured for much higher frequencies (up to 25MHz for example). Wouldn't there be a benefit using a higher frequency clock sync in terms of reducing the time it takes to synchronize clocks or something else?

I would appreciate to know what others think about this.

[tim292stro]

I think there is perhaps a characteristic you are overlooking on the 1PPS signal.

"...Hertz (Hz) is the standard unit of frequency, measuring the number of cycles or repetitions per second of a periodic phenomenon..."

If you have a 1Hz/1PPS signal which is stable over a very long period of time, you are solving the "per-second" portion of the frequency measurement. From that, you can run a counter that increments every clock cycle, and then gate the counter's input with the 1Hz/PPS signal to sample how many cycles or repetitions occurred in your periodic phenomenon over that second. From that you may discover if your measured clock is faster or slower than your 1Hz/PPS reference, and if the clock source is steerable, it may be adjusted and compared with the reference source again.

On your idea of reducing the time it takes to synchronize clocks - making a fast correction, or frequent correction would appear in the clock as a glitch or jitter (respectively). In situations where you have a clock feeding a Phase-Locked-Loop (PLL) multiplier or divider (which describes basically all electronic applications above 25-50MHz nowadays) - a glitch or introducing jitter to a clock could result in the PLL unlocking, and the dependent circuitry falling out of function (typically there is a state machine in logic which has a prerequisite that the PLL be stable before it presumes the logic will function correctly, thus blocking or resetting the operation of the logic).

This is true even with the output of the F9T's frequency output - the logic of the ARM microcontroller inside the module runs at a given frequency, and its output is not precisely time-aligned to the second, it's the closest internal clock edge of the logic's frequency - the error between the sample time for the edge and the calculated truth of when the edge should have occurred is quantization. The F9T has a quantization error message (UBX-TIM-TP) that can output what the quantization error of the last edge was relative to the calculated solution, this can be used to feed forward into a delay line to correct the error out (but the delay line would need to delay for at least a second for that to be useful). This is similar to PTP's hardware stamping where a packet is output with a time, and the hardware can tell WHEN that packet was actually transmitted, and then append that information of its observation to the outbound packet.

So about synchronizing clocks - we get a message that can't update any faster than one second telling us what time it is, and with a 1PPS signal when get a sharp edge of WHEN that message was true. That second's horizon IS the synchronization moment, and it reoccurs every second - anything tighter (IMO) is going to be buried in jitter. So the question then is - what application would you have that would need a synchronization event instance more than once every second (and would the synchronization actually destabilize your system?

[meh301]

I understand that the PPS reference effectively acts as an interrupt for the serial data, but modern GNSS SoCs have observation frequencies significantly higher than 1Hz now. Budget options can usually do 10Hz timing (+"PPS" set to 10Hz), and the Septentrios can do 100Hz observations, so in this case, would it be better to use a faster observation rate and a matching pulse?

[tim292stro]

I still think you're over-thinking/misunderstanding this and more likely to inject into and propagate error within your system concept by doing this.

There are physics limitation to the accuracy of the various GNSS systems which already are best nulled-out by actually extending the time an observation is made. For example you'd look at a 24 hour or larger observation/accumulation of the measured timing data to discern the accumulated error rather than instantaneous error. It's done this way because, in a shorter term, GNSS is actually LESS accurate than a local crystal oscillator can be.

A good SC-cut crystal running in the plateau of the turning-point (typically through ovenizing it) is FAR more stable over a short duration than an RF signal that is propagating through the entire atmosphere and subject to noise and interference, and transmitting a fairly accurate (but not precise) position of where it was when it sent it. However there is a transition point very long off where the accuracy of the GNSS will exceed the stability over time of a crystal. Here is a graph I grabbed from Google illustrating the various error versus time of several types of "clocks" using in electronics. Higher values are higher timing error:

You'll note, that the red line of GPS/GNSS doesn't cross below a crystal until you accumulate more than 1000 seconds in this graph - until then the crystal is more accurate than GPS/GNSS. You'll also note that a CSAC or Rubidium cell, while lower than GPS at the shorter time period than GPS/GNSS, still has higher timing error than the crystal until ~300 or ~15 seconds (respectively). In this case if you used the timing output of those sources to steer the local crystal at a shorter time interval, you'd be injecting that timing error into the otherwise more stable crystal timing.

You'd also want to be careful HOW you do the corrections. If you just snapped to the presumed "correct" timing of your chosen reference source, see previous comment about unlocking PLLs or just wrecking your system with observable glitches. It's much better (empirical statement) to feather-in long-term accumulated error so that your longer-term average error is nearly zero - in this way you are using a more accurate long-term correction to compensate for the long-term shortcoming of the local oscillator. This is a round-about way of saying that, GNSS is observably less accurate than a crystal oscillator at decreasing intervals - so increasing the correction occurrence in the region where the error is increasingly worse, actually makes your timing less accurate in that short interval.

When we're disciplining a local oscillator with GPS, this is similar to using another physical observation to account for motion - like we do when we use a Kalman-filter to integrate a local IMU with a GNSS macro-position solution. And for similar reasons we don't rely on GNSS when the solution it provides is observably worse than the local physical observation. If an accelerometer didn't see the sudden 3-meter movement the GNSS solution "swears just happened" we filter it out - relying on GNSS to only provide a bubble of where the device is rather than the tiniest sub-mm movements.