Hi

In any real world design there are a ton of variables. Without knowing a lot about what your objectives are this is going to be a lot of guessing. Sorry about that.

The first layer would be to run a second clock in the FPGA off of the OCXO. Update that clock with the NMEA information. When GPS goes away, you have a clock that keeps running.

If the OCXO is free running, that clock will have some level of drift. How much depends on how far off frequency that OCXO is.

If the OCXO is disciplined by GPS, the clock should be pretty stable when GPS is in view. Once GPS goes out of view, the OCXO will drift and the clock will follow it. It should drift less than a free running OCXO.

Yes, this is very general, and I’m already into a lot of guessing.

If GPS goes out of view for hours or days in your application, That might impact what you do.

If a one second error on the clock is acceptable, that is a very different thing than needing one microsecond or something in the nanoseconds.

Lots of things impact how this gets done.

Bob

Hello Abdul,

François Vernotte is giving a series of four lectures in the FEMTO-ST
institute in Besançon (France). Three of them are already online at
https://www.youtube.com/@femtost4271. The fourth one will be on "Holdover
and long-time extrapolation", and is scheduled in principle for May 22. If
you keep an eye on the YouTube channel of FEMTO-ST in the days after the
lecture, you should see the recording appear there. Also, an illustrious
member of this list recently gave an excellent presentation on holdover (
https://www.ion.org/publications/abstract.cfm?articleID=19958), but I do
not think the material is public.

If you are comfortable with (lots of) math, here is a classic reference,
even if the word "holdover" is not in the title:
Vernotte, F., Delporte, J., Brunet, M. and Tournier, T., Metrologia,
(2001). Uncertainties of drift coefficients and  extrapolation errors:
Application to clock error prediction, E1319

Cheers,

Javier

On Fri, May 2, 2025 at 1:48 PM ABDUL HAI via time-nuts <
time-nuts@lists.febo.com> wrote:

Hi,

On 2025-05-02 12:34, ABDUL HAI via time-nuts wrote:

As Bob already mentions, there is a ton of variables to this, but I
think a bit of generalization later I think we can sketch some suitable
approach that is typically used.

First, your GPS/GNSS receiver needs to one way or another give you
information that it lost lock. You can choose a range of different paths
here, but one is to parse messages out of the receiver, another is to
let it turn of it's PPS when it does not have lock. Regardless of which
method, what you want to protect is the state of your phase and
frequency learning, so you want a fast enough method to achieve that.

A second aspect, I assume you either use a steered oscillator or a
free-running oscillator with a re-synthesis through say a DDS. In the
larger scheme, it gives you a frequency control mechanism, so the
implementational details becomes more on how good or bad they are, but
concept wise they are about the same.

You naturally have some form of phase / Time Interval measurement that
occurs.

As you go into hold-over, you essentially stop updating the phase,
frequency and potentially linear frequency drift states with the input.
You keep repeating the same frequency correction. If you also do lineary
frequency drift, the last frequency drift state then keeps updating the
frequency for each time unit, as this is what is predicted.

You want to make sure you fail fast on going into holdover. Details on
that depends on what signals you have access to.

Secondly, you want to be conservative in accepting signal again, so it
has to proove it's stability for you before you start updating your state.

When the signal comes back, just a normal linear regulation down is
perfect for smaller errors. However, for larger errors you would
consider jumping phase and then lock in after that. This however would
cause a jump on the output, and it is for most application wise to
signal this to the following users through one of many ways, but turning
off (squelching) signals is one that is being used.

For some uses you actually declare your state to be so degenerated that
you reclassify yourself after some time. ITU-T is going through a number
of efforts on this very point for telecom standards, as it reflects on
Clock Class in PTP for instance.

So, you can choose a simple method, you can accelerate it and you can be
more refined to keep track of expected uncertainty.

See HP SmartClock and also IEEE Std 1139-2022.

Another method to handle larger errors is to increase the PLL bandwidth,
and this way significantly reduce the trace in time and then step it up
as lock has been achieved. This gives behaviour similar to a Kalman
filter model would do if properly modelled.

Regardless, there is not one single method available, but rather a range
of them. Some depends on the developes experience but also the expected
requirements for the application. Some is more or less dirty hacks you
don't care to share, but there can be some smart tricks too you do not
want to disclose.

Cheers,
Magnus

Hi,

easiest approach for you is to implement classical Kalman Filter (KF) for clock. Estimate OCXO offset and drift in the KF, and when your GPS signal is lost you those two clock parameters to do a holdover.

The tricky part is to know when to do KF estimation and when to switch to holdover. Based on your application GPS/GNSS can disappear quickly, or not, with degraded 1PPS performance happening fast or not. This would impact you KF estimates.

Hope this helps.

Best regards
Zdenek

Thanks very much for your views.
Yes, I need it to have a accuracy of within 100ns with ref. to UTC. I have a GPSDO with 1pps input and output that can give holdover of 1.5us/24Hrs.
How can I use this? are there any better available for required holdover?

----- Original Message -----
From: "Bob kb8tq via time-nuts" time-nuts@lists.febo.com
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "Bob kb8tq" kb8tq@n1k.org
Sent: Friday, May 2, 2025 6:35:50 PM
Subject: [time-nuts] Re: Holdover mechanism..

Hi

In any real world design there are a ton of variables. Without knowing a lot about what your objectives are this is going to be a lot of guessing. Sorry about that.

The first layer would be to run a second clock in the FPGA off of the OCXO. Update that clock with the NMEA information. When GPS goes away, you have a clock that keeps running.

If the OCXO is free running, that clock will have some level of drift. How much depends on how far off frequency that OCXO is.

If the OCXO is disciplined by GPS, the clock should be pretty stable when GPS is in view. Once GPS goes out of view, the OCXO will drift and the clock will follow it. It should drift less than a free running OCXO.

Yes, this is very general, and I’m already into a lot of guessing.

If GPS goes out of view for hours or days in your application, That might impact what you do.

If a one second error on the clock is acceptable, that is a very different thing than needing one microsecond or something in the nanoseconds.

Lots of things impact how this gets done.

Bob

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com

Thanks very much for your valuable suggestions. are there any literature available for this?
instead of directly reading and updating time from nmea, can I use internal OCXO (with hold over of 1.5us/24hrs), with discipline from 1PPS & with loading initial time from nmea?

----- Original Message -----
From: "Zdenek Chaloupka" z.c.nl@ieee.org
To: "Discussion of precise time and frequency measurement" time-nuts@lists.febo.com
Cc: "abdulhai basha" abdulhai_basha@nrsc.gov.in
Sent: Friday, May 2, 2025 9:29:46 PM
Subject: Re: [time-nuts] Holdover mechanism..

Hi,

easiest approach for you is to implement classical Kalman Filter (KF) for clock. Estimate OCXO offset and drift in the KF, and when your GPS signal is lost you those two clock parameters to do a holdover.

The tricky part is to know when to do KF estimation and when to switch to holdover. Based on your application GPS/GNSS can disappear quickly, or not, with degraded 1PPS performance happening fast or not. This would impact you KF estimates.

Hope this helps.

Best regards
Zdenek

Hi

The answer very much depends on what you are trying to achieve.

Is the 1.5 us drift of the GPSDO is acceptable in your application? If not, you will need to do something else.

If it is, then sync your FPGA to the 1 pps edge all the time. Use the GPS to load time of day once at boot. You have the GPSDO managing all the into and out of holdover stuff for you.

Bob

Flattery works.  I’ve attached my ION-PTTI paper, although in truth it is just a minor extension of the Vernotte et al. masterpiece.  (ION does not hold the copyright to individual papers, only to them as a whole.)