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

[Jimmy Burrell]

Hal,

Thanks for the info. I think I'm going to give it a go. At any rate it's a good excuse to buy another Raspberry pi :)

Thanks for the python source too. Looks useful.

Jimmy...
N5SPE

> On Feb 5, 2014, at 11:39 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> 
> 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.
> 
> 
>