[time-nuts] 60Hz line data

[Hal Murray]

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.




-- 
These are my opinions.  I hate spam.