AC power frequency monitoring experiment

Here in North America, AC power is delivered at 60 Hz. Back in the day, electric clocks were designed with synchronous motors whose rotation was directly linked to this frequency. Later, electronic clocks were designed to actually use the AC line frequency as the timebase. This worked because the standards for electricity delivery called for long-term accuracy.

How can this be? The line frequency is subject to reduction when highly inductive loads are imposed on the grid. Well, the standard says that the accuracy specification for the frequency is only a long term value. You can count on seeing 5,184,000 cycles in a day on average. If demand creates a frequency sag, the utility is supposed to make up for that later with a matching period of higher frequency.

Well, if that sort of thing is going on, it ought to be something that can be measured.

The AdaFruit Ultimate GPS breakout board is a good way to get an independent reference. It's PPS output is 100 ms positive-going pulses once every second, with nano-second levels of precision and accuracy.

We can take that PPS output and apply it directly to the INT0 pin of an Arduino Uno. With a RISING interrupt set on that pin, we'll be able to precisely gather statistics on second boundaries.

For the AC input, the path of least resistance is to buy a small AC-AC "wall wart." 9 volts would be fine, but anything under around 20 volts would work (the limiting factor is the -0.3-36 volt absolute maximum input range of an LM393). The shield of the wall wart will be tied to ground and the center pin run through a simple signal diode with a 20k pull-down on the "far" end and into the positive side of an LM393. The negative side will have a voltage divider with, oh, say, 2.5 volts on it. The result of that will be a square wave whose frequency equals the frequency of the incoming AC. Now, the duty cycle will be a mess, and there's no particular assurance that the comparator output will be synchronized to the line frequency, but none of that matters. We really just want to count the positive-going excursions, just like we're counting the rising edges of the GPS PPS output. The output of the comparator (with the pinMode set to INPUT_PULLUP) will go into INT1 and - again - a RISING interrupt will be set to count those pulses.

Most of the time, when the PPS interrupt is triggered, I expect the frequency interrupt count to be 60. When it is, that doesn't need to be reported. But occasionally, I expect it to be 59 or 61. Perhaps even occasionally 58 or 62. Those are noteworthy.

The hypothesis of the experiment is that over a long enough period of time, the sum of all of the offsets from 60 will be zero.

So the sketch:

setup() will set up the interrupt service routines. The PPS interrupt will gather the current AC interrupt count into a global reporting variable, clear the active counter and set a mark. The AC interrupt will increment the interrupt count only.

loop() will simply wait for the PPS interrupt flag and check to see if the delta of the count from 60 is zero. If it is, then it will ignore that interval and wait for the next one. If it is anything else, then that will be printed on the serial output.

I'll probably wire the serial output to my raspberry pi via an FTDI cable and set a little daemon up to capture and report all of the offset events. I can then make nice graphs and stuff.

This'd be a heck of a science fair project... Hmm.