[time-nuts] 60Hz line data

[Alexander Pummer]

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:
> bill at iaxs.net 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.
>
>
>
>