View Single Post
  #63   Report Post  
Posted to sci.electronics.repair
Jeff Liebermann Jeff Liebermann is offline
external usenet poster
 
Posts: 4,045
Default LED alarm clocks all lose accuracy over time

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.

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.

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.

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.
Crystals with such a slope tend to have large frequency drift during
aging characteristics. Reverse slopes in the operating area will
create some rather bizarre tuning characteristics.

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.

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.

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.

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.

If you're building a clock, the noise and jitter aren't very important;
long-term drift is.


True. However, I'm building GPSDO, while you're building a GPS alarm
clock. I agree that the requirements are quite different.

Isaac


--
Jeff Liebermann
150 Felker St #D
http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558