More 60 Hz data/graphs
I've moved the 60 Hz stuff from
http://www.megapathdsl.net/~hmurray/time-nuts/
to
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/
The main graph is now up to sightly over 4 days.
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz.png
Peak-to-peak is almost 8 seconds.
The slew rate is pretty fast in a few places.
1 second in 1/2 hour at hour 64.
4 seconds in 3 hours at hour 13.
2.5 seconds in 3 hours at hour 44.
7 seconds in 7 hours at hour 91.
When I started, I picked 10 seconds as the sampling rate. That was just a
wild guess, but it seems to have worked out well. That's 1/2 megabyte per
day. (I think I can trim a factor of 2.)
I plotted the frequency. It's not as clean as the offset. Here are 3
graphs, measured over 10, 100, and 1000 seconds.
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-f10.png
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-f100.png
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-f1000.png
Note the two big spikes on the 10 second graphs. Those correspond to 2
glitches in the raw data. Both have 3 extra counts within a 10 second sample
slot.
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-g1.png
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-g2.png
Note that they are close to 24 hours apart, at 6:30 to 7:00 AM Pacific local
time (California).
Has anybody noticed things like this? As a sustained slew rate, it's huge
relative to the longer samples above. But maybe steps like that are normal
transients when somebody throws a big switch. Or maybe they are glitches due
to lightning/whatever. I guess I'll have to connect up the audio port and
grab a lot of raw data so I can inspect the area around glitches like these.
This is the (python) code I'm using to collect the data:
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz.py
Edit daemon to 0 if you want to debug things.
It's got my directory hard wired in it. (That should be easy to fix.)
If you improve it, please send things back to me and/or put your version on
the web.
It's a quick hack, don't expect elegance. It uses some Linux specific
tricks. I'll work on a version in c that will probably run on *BSD if
anybody wants it.
The raw log files include the 10 second deltas. This is the hack I use to
compute the 100 second and 1000 second data.
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/stretch-60Hz.py
If anybody wants it/them, I'll put the gnuplot files I use out there too.
--
These are my opinions, not necessarily my employer's. I hate spam.
Hal,
That's good stuff. Sadly, I've got to convert UTC to your local time to
interpret the results, so I haven't done it. Tom's MJD will be even worse.
The reason is that the loads that cause frequency droop occur during
workdays. Lost cycles are made up at night, so I need to know when local
day and night occur.
At the present time (before July 15th), the power dispatching center for
an area tries to end the day (perhaps at 7 AM) with exactly 60x60x60x24
cycles of power generated. This keeps the clocks on time, and balances
the power budget for the day - no extra cycles given away and no cycles
stolen from other areas.
The Time Error Correction (TEC) elimination experiment (to find out who
notices the loss) is motivated by the number of frequency excursion (not
trip) errors that occur when dispatch requests a correction. It costs
the generating plants money (nothing else drives change today) to
increase power on demand - in fuel and stress on the equipment.
With any luck, my next message will be about the frequency control
problem.
Bill Hawkins
-----Original Message-----
From: Hal Murray
Sent: Sunday, July 03, 2011 11:15 PM
I've moved the 60 Hz stuff from
http://www.megapathdsl.net/~hmurray/time-nuts/
to
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/
The main graph is now up to sightly over 4 days.
http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz.png
Peak-to-peak is almost 8 seconds.
The slew rate is pretty fast in a few places.
1 second in 1/2 hour at hour 64.
4 seconds in 3 hours at hour 13.
2.5 seconds in 3 hours at hour 44.
7 seconds in 7 hours at hour 91.
Hal,
That's good stuff. Sadly, I've got to convert UTC to your local time to
interpret the results, so I haven't done it. Tom's MJD will be even worse.
Bill,
If you know C, see mjd_code.c under www.leapsecond.com/tools/.
Otherwise, if you use Excel it's even easier -- just subtract the
magic number 15018 from a MJD value and you get date/time
in Excel format.
Dealing with timezones is easy too; subtract the fraction N/24
where N is 4,5,6,7,8 here in the US. But let's keep everything
in UTC since the grid crosses timezones (doesn't it?).
A note about:
#define MJD_TO_EXCEL(n) ( (n) - 15018 )
The reason this works is that MJD has an origin of 17-Nov-1858
and Excel uses an origin of (well, sort of) 0-Jan-1900. There are
15,018 days between those time-scales.
/tvb