Synchronizing intermittent clock sources

[bonelli]

Hello,

I have 2 reference clocks, both are precise (+/-1µs) and give pps output. They suffer from different problems:
- The first one is intermittent (GNSS PPS signal)
- The second one is intermittent and also sometime strongly wrong: every few minutes, 5-6 consecutive pulses are far away from the "reference" clock. They are so wrong that they are easily detectable (error in tenth of µs to tenth of ms).

Adding a good TCXO in the loop, it must be possible to build something that always give a PPS, switching between the 2 external clock sources when available and falling back to TCXO when needed.

I need a precision in the µs range.

I'm more familiar with CPU than FPGA but I believe that for this application, a tiny FPGA will be more appropriated.

To your opinion, what will be the best approach: classical logic using counters and basic logic blocks, or a more smarter design using PLL?

Thank you
Regards

[ejeffrey]

Yes this is totally feasible.  A small FPGA would be an easy way to implement this.  Is the second pps source also ultimately linked back to GPS time?  Or can it skew arbitrarily over long enough time?

The pps that is both intermittent and sometimes wrong is a bit of a concern.  Your design should handle the case where the clock is missing for a while and then comes back with the first clock pulse is 10 us delayed.  That won't necessarily be more than the tcxo could have drifted in the time it was off.

One possibility is to consider if you can use an OCXO and if that would be stable enough to use only the GNSS system? Or does this have to work indoors where the GNSS signal can be missing quasi permanently?

[bonelli]

The second PPS source is contained in a few µs from the GNSS reference. It is intended to replace the GNSS PPS when working indoors (what will happens most of the time).

OCXOs consume a little bit too much power...

Your design should handle the case where the clock is missing for a while and then comes back with the first clock pulse is 10 us delayed. That won't necessarily be more than the tcxo could have drifted in the time it was off.

Yes!

Assuming I have already a STM32H7 on my design, a good implementation of the timers may also do the job.

[tggzzz]

Can I suggest you might like to define a few more points.

How long does it take to determine that a pulse is actually missing? When is the missing pulse re-inserted, and does that time delay affect your application?

If you have two sources of ppm pulses and the pulses occur, say, 456.789ms apart, how are they "combined" in a PLL?

I suggest that detecting and ignoring spurious pulse that is "tenth of µs" away from expected pulse is not easy. That's 1 part in 10⁷, which has implications for the lock-in time of a PLL.

[ejeffrey]

I'm pretty sure that was supposed to be 10s of microseconds because the overall resolution is only supposed to be +/- 1 microsecond