but for a very long time we get --or better to say got in the past --
the correct number of periods of the line frequency, I have two clocks
side by side -- one driven by the power line the other is an "atomic
clock" from Westclox guided by WWVB and the seldom "disagree" about the
time
73
KJ6UHN
Alex
On 8/4/2015 5:17 PM, Hal Murray wrote:
[email protected] said:
Frankly, I'm puzzled by the graphs that relate to the time offset. All
that's available to the observer is the line frequency. Relative time may be
inferred with a cycle counter. How is that counter set to UTC? How can you
tell the difference between time error from some reference point, and cycles
gained or lost in the counting equipment - due to noise and/or computer
interrupt servicing routines?
The counter isn't set to UTC. The zero point on the vertical offset is
arbitrary. All you can measure is the drift relative to some arbitrary
point. I used the start of the data as zero. That's the same as setting
your wall clock to UTC when you first took it out of the box and plugged it
in.
If you look in the archives, there is a time-lapse movie make with one frame
each minute when the second hand started straight up.
I'm pretty sure my setup isn't gaining or losing many cycles. Actually, I'm
pretty sure it is picking up an occasional extra cycle because I see them.
10 seconds at 60 Hz is 600 cycles. If you get an extra count, the frequency
will be off by 0.1 Hz. Since the normal range is much less than that, a
sample with an extra cycle stands out. They are infrequent enough that I
look at each one by hand and make a graph like this:
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-2012-Jan-26-a-pick.p
ng
I'm using a human filter. I haven't tried to automate it.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
