In article ,
Jeff Liebermann wrote:

On Mon, 21 May 2012 00:00:49 -0700, isw wrote:

I don't understand why there would ever be a missed once-per-second
pulse (assuming you know how to design digital stuff), but even so, the
next time a NMEA sentence comes along (or whenever you decide to read
the next one), you'd know you were off, and which way.

The missing pulse problem is with the 1pps clock implementation, not
the NEMA sentence reader. Clock slip with 1pps is very real. I can
do it with my weather station if I transmit on my VHF HT within about
2ft.

Maybe true, but I would have no easy way to determine if it needed to
be resynced with the GPS clock. If it drifted off frequency for some
reason, all my measurements would be off.

But if it ran at the same rate as the GPS clock, then it wouldn't be
drifting ...

Only if the clock didn't miss a pulse.

I think we have a problem here. You're mixing a NEMA sentence driven
clock, with a 1pps conventional counting clock. The NEMA sentence
device does NOT have a clock slip problem and does not need
recalibration. The 1pps counting clock can easily lose count and
offers no easy way to determine that the clock has slipped and that it
requires recalibration.

I'm proposing to build a time-of-the-year clock that uses a (say) 10 MHz
oscillator for a timebase, with dividers (hardware or software) to
provide all the various outputs. The time-of-year output is available to
the frequency-controlling loop, which compares its value with what it
gets from the NMEA sentences -- if the local clock is ahead, slow down
the 10 MHz, and vice-versa.

After a while, that oscillator is going to be dead on.

Setting the frequency to
1*10^-11 takes days to set, and the same time to reset. Might as well
leave it on all the time.

Well, of course it's on all the time; there's no other way to keep the
oscillator stable.

OK. Then forget about battery operation.

Using temperature to control frequency, probably; using other means, not
much of a problem. A decent GPS chip set, a little CMOS computer, and an
LCD for readout will come in at a small fraction of a watt. If you
picked a better-than-average crystal, stability-wise, you could turn off
everything but the oscillator for most of the time and still get
exceptional long-term accuracy. I expect that some clever design could
produce an "oven" that could be heated by a quarter-watt resistor glued
to the crystal case, so even using the temperature-control-of-frequency
method could still give you something that could operate all day on a
battery.

But if your local notion of time (what the NTP folks
call "epoch") tracks the data coming from the GPS, then it will
eventually be within that error band. And if it stays on longer, it'll
become ever more accurate (long-term).

Overkill (except for leap seconds). I don't think anyone cares about
sub-second accuracy in a home alarm clock. However, the last digit
(seconds) should be accurate.

Right. But what they might care about is that the clock never drifts
away from "real" time, no matter what the power line does. That, of
course, is the appeal of all "radio clocks".

Use whatever crystal you want/need to get the temperature/frequency
curve you need.

If I do that, the design becomes more difficult. For example, a
higher freq/temp slope for the crystal will require more insulation.

Not really. Remember, it's in a temperature-controlled oven. The
temperature control loop will keep the crystal at whatever temperature
is called for to keep the frequency at precisely 10.000... MHz.

Crystals with such a slope tend to have large frequency drift during
aging characteristics.

Which will be compensated for continuously by the loop.

Reverse slopes in the operating area will
create some rather bizarre tuning characteristics.

Well, don't operate it in that regime ...

Pick an oven temperature range that gives the slope you
need.

Well, if I use an AT cut crystal at 80C, the slope is about 2ppm/C. At
10MHz, that's 5Hz/C. You could probably adjust the temperature over a
20C range (to avoid the dip in the AT curve at 75C) yielding a 100Hz
range. Yep, that might work, but you'll need to reduce the oscillator
thermal mass, and greatly increase the insulation.

Nope. Very slow response times are no problem. The loop will eventually
arrange things so that precisely ten million cycles will elapse per one
second elapsed, over the long term. Still, small thermal mass is easy --
just pick a small crystal package, and heat that package directly with a
small resistor or two. Insulation is cheap and a lot of it is not a
problem. I'd use fairly long, very thin, stainless steel wires to
connect the crystal (and those resistors) to the rest of the circuit,
too. One major source of problems on high-stability oscillators is
thermal or acoustical shock running right up the connecting wires
directly to the quartz itself. I've seen ovenized oscillators that were
disrupted every time the thermostat clicked, and not because of
electrical transients.

I don't see what's so hard about it.

Pretend you're on a large boat, which has about a 3 minute delay
between when you turn the rudder and when the vessel changes
direction. Newton's 2nd law and hysteresis delay at its best. To
speed up the turn, one tends to over shoot the rudder direction, and
then bring it back to the correct orientation. To anyone lacking
experience in piloting such an over-damped system, the path traveled
will be rather erratic. See control system damping calculations. your
manual oven corrections might be similarly erratic.

I've done a few control loops, some of them a bit "peculiar". If you
insist on having the fastest possible transition to the new heading to
within some specified error band, then you're correct. It you're willing
to do things a lot more slowly while still (eventually) arriving at the
new heading, then the loop gets very simple. For the above problem, just
put a really slow motor on the power steering for the rudder.

It's not even clear to me why
you even need a low-noise oscillator for a clock, assuming it's being
disciplined by a more accurate "master" (the GPS time system).

I don't need a low noise oscillator for an alarm clock. I mentioned
the low noise in reference to by building a GPSDO, which will be used
for everything from running my test equipment clock, to synchronizing
transmitters. I don't see any reason to build multiple versions when
one device will do it all.

Consider the 10 MHz output from this sort of clock as the frequency
reference for whatever sort of synthesizer you want. If the clock runs
at the proper rate, the oscillator is at the specified frequency. After
it's run for a while, the frequency will always be very, very close to
exactly ten megahertz.

The 1/f phase noise of an oscillator is directly related to the power
density of the device. That means using a moderately high current
device at about 10% of its rated current. That's also why nobody uses
low noise RF front end transistor for low noise oscillators. That
leaves flicker noise, which reduced with lots of negative feedback.

The short-term noise and the long-term stability are different. That's
why super-precision sources use rubidium oscillators (low noise, poor
drift), stabilized by cesium devices (higher noise, essentially zero
long-term drift).

True and thanks for recognizing that a rubidium source is not a
primary frequency standard. The issue with noise is that it has an
effect on accuracy in that one cannot measure the frequency to a
resolution less than the noise. For example, if there is 1Hz of FM
noise on the oscillator, the frequency cannot be measured to less than
1Hz. Of course, one could average the measurements, which only works
if the noise spectra is symmetrical. Also, 1Hz of FM noise at the
10MHz clock reference, multiplied up to a 10GHz transmitter, is
1000Hz, which is audible and quite fatal to data.

One of the advantages of this sort of loop (thermally controlled) is
that there is literally nothing in the circuit that prevents the noise
from being as low as it can possibly be for whatever sort of oscillator
you choose, while still constraining it to being very close to the
design frequency.

Isaac