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

Tom Harris celephicus at gmail.com
Wed Feb 5 17:40:09 EST 2014


For your setup measuring mains there will be a large phase difference
across the transformer. This is due to very many physical properties of the
materials, the largest being the magnetic succeptability of the core. Now,
this does show a slight temperature dependance. So how do you know that you
are not getting a slow variation in the phase showing up as a frequency
shift, since you are measuring such tiny variations. I know that the
transformer is probably in thermal equilibrium with it's surroundings, so
is at a steady temperature, but this problem  (of getting an accurate idea
of mains frequency & phase) has exercised me over the years. I currently
use an opto and voltage reference to get mains frequency, phase & and
voltage (computed by lookup table from pulse width) which I found was more
stable than a transformer. And cheaper as well, since this is for a
commercial product.

I'm just surprised that you get such results with a cheap transformer.

Just remembered, we got a tiny change in phase shift across a transformer
due to its orientation, we could turn it 90 Deg and get a tiny change (less
than a milliradian), we never got to the bottom of it, maybe the Earth's
magnetic field?


Tom Harris <celephicus at gmail.com>


On 6 February 2014 04:39, 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.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>


More information about the time-nuts mailing list