[time-nuts] 60Hz line data

[Bill Hawkins]

Does anyone east of the Rockies have any similar data?

At one time, the US FERC was going to deregulate frequency control to
reduce the amount of fuel used to accelerate in order to catch up. The
billing for power exchanged with a regional network is based on the
number of cycles produced or consumed. That requires producer and
consumer to run at the same frequency. So the deregulation was
abandoned.

California is a net consumer of power. The power is transmitted over the
mountains by high voltage DC tie lines. The DC to AC converters can run
at any frequency (actually phase) required to keep power flowing in the
right direction. Thus it is possible for CA to have 30 second swings
while the rest of the country maintains an exact number of cycles per
day or per year.

At least, that's what I learned from an engineer at a power company in
Philadelphia and Internet searches for CA. It would be interesting to
see what's really going on.

What do other countries do? DC tie lines?

Regards,
Bill Hawkins



-----Original Message-----
From: Hal Murray
Sent: Friday, July 10, 2015 2:45 AM
To: time-nuts at febo.com
Cc: Hal Murray
Subject: [time-nuts] 60Hz line data

My collection recently rolled over the year boundary:
 
http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2014-2015.
png

The grid is 4 weeks in the X direction.  The start of the Y offset is
arbitrary.  I picked the start of the data.

The pairs of colors are a month.  Within a month, days alternate colors.

Here is May 2015:
 
http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-May.p
ng

There were a few interruptions.  I lined things up by eye.  They are
probably off by a few cycles.  I don't think they are off by a second.

There are also occasional extra cycles.  I assume they are caused by
noise.  
One of these days, I'll catch one.  They add up to ballpark of a second.

Here is an old example:
 
http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-10-a-pick.pn
g

Here are the days before and after the leap second:
 
http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-Jun-3
0-le
ap.png
Here is the same data zoomed in to 1 hour each side:
 
http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-Jun-3
0-le
ap2.png

There is one frequency point way up high.  (1 second out of 10 is huge
on that scale.)  I set the Y2 scale manually in order to make the main
section interesting.

As you can see, I screwed up the leap second processing.  I sure knew
the leap second was coming, but I don't remember considering what that
program (or any others I'm running) would do when one happened.  I can't
see a simple way to fix it.  I think I'd have to convert the program to
use TAI, and then find or write a package to convert normal/UTC time to
TAI.  That needs a table lookup.

Google's smearing inserts a second over 20 hours: 1/72000 or 13.8 PPM.

If my collection system was playing the smear game, I think a 60 cycle
shift would be visible if you had a reference to compare to, but not
significant relative to all the other changes.  (That pair of days has
500 cycles peak-peak, so 60 is only 10%.)  On the frequency scale, it's
probably lost in the noise.



--
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.