[time-nuts] 1pps signal presence with no GPS signal.
cfmd at bredband.net
Thu Jul 7 19:45:25 EDT 2005
From: David Kirkby <david.kirkby at onetel.net>
Subject: Re: [time-nuts] 1pps signal presence with no GPS signal.
Date: Thu, 07 Jul 2005 23:59:35 +0100
Message-ID: <42CDB3D7.7090406 at onetel.net>
> Magnus Danielson wrote:
> >>Is turning off the 1pps, the best thing to do if controlling a crystal
> >>or rubidium? It seems most logical to me, so I can't understand why the
> >>default is to not to.
> > Turning of the internal PPS is a crude way to say "no signal" compared to
> > having it read of the GPS kit. Also, if it is not turned on normally, then the
> > design might not be done for it either. So, it boils down to how your locking
> > scheme works. For some very simple schemes, loosing the PPS is worse than the
> > wrong PPS.
> > Cheers,
> > Magnus
> I take the point made by yourself and others that whether to turn on or
> off the 1pps is better depends on what you are syncing to and how the
> syncing is done.
Exactly. You have to think system-wide and not only component-for-component.
If you want a system that gives you good timing, you also need to care about
the failure modes and how those could have reduced effect on your stability
and functionality. The more detailed info one could get, the better judgement
one should be able to get. Getting a good set of state information from the
GPS receiver should certainly be a good start. I should read up on the
A bad implementation (we are talking really bad in this context) will have the
phase detector flooring it, it will naturally start emptying the loop filter of
"good" state and the frequency control will eventually flooring it too and you
get the uncompensated drift of the oscillator, plus the frequency error of the
floored DAC as well as the now uncompensated noise of the DAC reference and
oscillator power. The later is normally suppressed by the locking loop. This
noise can be rather significant. So, you loose both traceability and stability.
A good design can actually give you higher stability (mid-term) by temporary
drop the traceability from the GPS. Naturally, the long term stability is the
traceability so the forced hold-over is a rather short period anyway. Short-
term stability (jitter) is really due to the oscillator.
> In my case, I intend locking two items to 1pps.
> a) PRS10 rubidium from Stanford.
> b) HP 10811A via the Bruce Shera board.
I assume you mean the Brook Shera board from A & A Engineering:
> As far as I can tell, the PRS10 will not update the rubidium's frequency
> unless the 1pps is present, so it would seem to me the PRS10 would
> benefit from no 1pps signal rather than the wrong one. But perhaps I am
I think you are right. As I recall it, it stops learning from lack of PPS.
As always, stop assuming and know instead.
> In the case of a 10811A via the Shera board, I am less sure.
I scanned the article, but no real clue. However, if it is missing, it should
be a small feat to fix the PIC code to do it properly. Basically, lack of PPS
within say 1.5 sec of the last one means go into hold-over state. When in
hold-over state just keep the same DAC value. If you are fancy, you do more
(the HP SmartClock technology is neat since it will actively compensate for
perturbations in environmental variables etc to predict the trimming needed,
which is cool).
More information about the time-nuts