[time-nuts] 60 Hz power glitch, US West coast (Silicon Valley)

[Hal Murray]

jimmydburr at gmail.com said:
> Interesting.. I'm assuming the green graph is actual voltage and the red
> graph is..? 

The green is the frequency as measured over the last 10 seconds.

The red is the long term clock offset in cycles relative to what it would be 
if the frequency was exactly 60 Hz.  It's the error you would see if you 
looked at a clock that was tracking the power line.  The 0 point is arbitrary 
since I can't see the reference clock the power system is using.  For those 
graphs, I used the start of the day/file as 0.


> I've never done any mains monitoring/measuring and was wondering, what's
> your equipment setup? 

It's simple.  The hardware is an AC wall wart and a couple of resistors as a 
divider connected to a modem control pin.  I forget which one.  It's the one 
that ntpd expects to use with a PPS input.

There was a discussion on that topic here a year or 3 ago.  It's in the 
archives, but I couldn't find it with a quick look.

The software is a simple python hack.  It runs on Linux.
  http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/pps.py

Linux has a back door to the PPS info.  Things like 
/sys/class/pps/pps0/assert give text like this:
  1391619268.999925084#1125070
The number left of the # is the time of the last PPS.  The number to the 
right is the pulse count.  The software above just waits 10 seconds, grabs 
another sample, and writes a line of text to a log file and switches to a new 
file every day.  It's 1/2 megabyte per day.

If you have FreeBSD or NetBSD rather than Linux, it shouldn't be too hard to 
use the same API as ntpd uses.  I don't know how PPS works on Windows.

Another approach would be to feed it into the audio input and scan for zero 
crossings.  I captured the raw binary for a while when I was chasing some 
noise glitches.  It's a lot of data.


-- 
These are my opinions.  I hate spam.