From: Magnus Danielson <magnus@rubidium.se>

Hi Magnus, I don't remember seeing such a report.  Could you tell me where to find a copy?  I've got a lot of code-space left on this PIC, so assuming I can get the hardware to cooperate, much is possible. Bob ----------------------------------------------------------------- AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info From: Magnus Danielson <magnus@rubidium.se> To: Bob Stewart <bob@evoria.net>; Discussion of precise time and frequency measurement <time-nuts@febo.com> Cc: magnus@rubidium.se Sent: Wednesday, August 17, 2016 1:05 AM Subject: Re: [time-nuts] Holdover Bob, That is what seem to work well in commercial products, including my designs. Have you seen the RAI report on GPSDOs? I think we discussed it before, that will be a relevant reading. Not all system implements 3), and it is a bit complex, so consider it an option to add, but not necessarily always used. Sometimes you don't want to do that. Cheers, Magnus On 08/17/2016 02:08 AM, Bob Stewart wrote: > Thanks Magnus! > > These look like good guidelines.  I'll see what I can come up with. > > Bob > > ----------------------------------------------------------------- > AE6RV.com > > GFS GPSDO list: > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > > > ------------------------------------------------------------------------ > *From:* Magnus Danielson <magnus@rubidium.dyndns.org> > *To:* time-nuts@febo.com > *Cc:* magnus@rubidium.se > *Sent:* Tuesday, August 16, 2016 6:49 PM > *Subject:* Re: [time-nuts] Holdover > > Bob, > > On 08/16/2016 11:31 PM, Bob Stewart wrote: >> Hi Attila, >> In my unit, which is a frequency standard, I chose to tell the > receiver to stop sending 1PPS pulses when it loses sync to the sats. > And since the 1PPS is no longer coming, the PLL does nothing and the DAC > doesn't change.  (Let's avoid the question of aging correction for > now.)  So, I'm wondering where to go and what to do if I want to get > time from my unit.  Clearly I could just tell the receiver to continue > to send 1PPS pulses and sync to those - marking the time as unreliable. > When the receiver synced back up, then it would warp the time output, > the 1PPS would warp in phase, and the PLL would correct the phase error. >> >> So, that's one way, but probably not a desirable way.  My interest was > in the option of using the OCXO to create the time, which clearly gives > a better option when the receiver syncs back up to the sats.  Is there a > published standard for this, or is this something that everyone (except > the newbie) knows so well that it's not worth discussing? > > There is no standard, but a few basic ways to go about which seems > reasonable and used by most is: > > 1) As you go into hold-over, keep producing PPS etc > 2) As you leave hold-over, attempt to adjust the phase back. > 3) If your system been in hold-over for a longer time, say that it > reasonably deviates outside of +/- 10 us (or some other limit), alarm > and turn output off > > I have selected a somewhat more intricate setup in which you can set a > re-assignment limit, so when the phase error is outside of that limit, > you turn the output off, jumps the phase difference, and then starts to > track in from there. The reason being that at some time deviation, the > time it takes to track in the phase error is too large to be practical > so turning of and jump has less impact. > > Cheers, > Magnus > >> Bob >>  ----------------------------------------------------------------- >> AE6RV.com >> >> GFS GPSDO list: >> groups.yahoo.com/neo/groups/GFS-GPSDOs/info >> >>      From: Attila Kinali <attila@kinali.ch <mailto:attila@kinali.ch>> >>  To: Bob Stewart <bob@evoria.net <mailto:bob@evoria.net>>; Discussion > of precise time and frequency measurement <time-nuts@febo.com > <mailto:time-nuts@febo.com>> >>  Sent: Tuesday, August 16, 2016 3:46 PM >>  Subject: Re: [time-nuts] Holdover >> >> On Tue, 16 Aug 2016 04:35:40 +0000 (UTC) >> Bob Stewart <bob@evoria.net <mailto:bob@evoria.net>> wrote: >> >>> It's been pointed out to me that I didn't understand the function of >>> the 1PPS of a time standard.  I confess that somehow I had confused the >>> term to be timing standard; which would be an entirely different thing. >>> But, this is time-nuts, so I should have realized... >>> Anyway, is there a standard, or at least an accepted practice, for how >>> holdover is handled in a time standard? >> >> There are many ways how to do that and which one you choose depends >> on the application and its requirements. You can find everything between >> "jump imediatly" and "just keep the frequency stable and don't care about >> alignment". >> >>                Attila Kinali >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@febo.com> > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > >

1. Always a PPS out, TOD string carries a valid or "do not use" flag - default, actually used about 1/3 of the time
2. Output only when clock is "synced" , That is  the error is small and the slope of the changes made is small, for at least 4 observational windows. 
3. Like number 2 but adds the notion of Holdover. That is when sync is broken, if you had been synced for "enough" time, keep output if you hold over counter has not expired. 

Loop bandwidth is set by the source, PTP / IEEE 1588 sources bandwidth can be as narrow as  1~3 mHz , GNSS has much wider bandwidth, 

All of the clock class mappings, limits and thresholds are configurable at some level. 	

Hello Bob, At work we make internet clock that are governed by a number of ITU and IEEE standards. As others have stated correctly, there is no standard. There are a number of behaviors that can be configured depending on application. 1. Always a PPS out, TOD string carries a valid or "do not use" flag - default, actually used about 1/3 of the time 2. Output only when clock is "synced" , That is the error is small and the slope of the changes made is small, for at least 4 observational windows. 3. Like number 2 but adds the notion of Holdover. That is when sync is broken, if you had been synced for "enough" time, keep output if you hold over counter has not expired. Now what to do when your source is re-established.. If the offset is large, or if the PPS has been squelched, or the reference source has changed, jam the 1pps, and steer from there. If the offset is small, ( some µs, ) steer the 1pps , with the max rate of steering set by how much we can screw up the frequency, default is 10 ppb Loop bandwidth is set by the source, PTP / IEEE 1588 sources bandwidth can be as narrow as 1~3 mHz , GNSS has much wider bandwidth, All of the clock class mappings, limits and thresholds are configurable at some level. Link On Aug 15, 2016, at 21:35 , Bob Stewart <bob@evoria.net> wrote: > It's been pointed out to me that I didn't understand the function of the 1PPS of a time standard. I confess that somehow I had confused the term to be timing standard; which would be an entirely different thing. But, this is time-nuts, so I should have realized... > Anyway, is there a standard, or at least an accepted practice, for how holdover is handled in a time standard? Not "how it's done", as in algorithms, but what is expected by the user. I can see at least 2 ways: time warping (which would be especially bad if the time standard had gotten ahead in time) and nudging back to the correct time. The case of warping is obvious. But, are there other methods, and is there some standard for how quickly the time output of the time standard, and of course the 1PPS pulse, is nudged back to the correct time? > Bob - AE6RV > ----------------------------------------------------------------- > AE6RV.com > > GFS GPSDO list: > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.