[time-nuts] 60 Hz power glitch, US West coast (Silicon Valley)
Tom Harris
celephicus at gmail.com
Wed Feb 5 22:40:09 UTC 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_lists.febo.com
mailing list