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 <celephi...@gmail.com> On 6 February 2014 04:39, Hal Murray <hmur...@megapathdsl.net> wrote: > > jimmydb...@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@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.