Re: [time-nuts] 60Hz line data
alex...@ieee.org said: but for a very long time we get --or better to say got in the past -- the correct number of periods of the line frequency, I have two clocks side by side -- one driven by the power line the other is an atomic clock from Westclox guided by WWVB and the seldom disagree about the time Which grid are you on? (I'm on the west coast.) Was your observation recent? It wouldn't surprise me if the timing accuracy has degraded over the years. I have some data from 2012, but it will take me a while to clean it up and make a nice graph. -- 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.
Re: [time-nuts] 60Hz line data
but for a very long time we get --or better to say got in the past -- the correct number of periods of the line frequency, I have two clocks side by side -- one driven by the power line the other is an atomic clock from Westclox guided by WWVB and the seldom disagree about the time 73 KJ6UHN Alex On 8/4/2015 5:17 PM, Hal Murray wrote: b...@iaxs.net said: Frankly, I'm puzzled by the graphs that relate to the time offset. All that's available to the observer is the line frequency. Relative time may be inferred with a cycle counter. How is that counter set to UTC? How can you tell the difference between time error from some reference point, and cycles gained or lost in the counting equipment - due to noise and/or computer interrupt servicing routines? The counter isn't set to UTC. The zero point on the vertical offset is arbitrary. All you can measure is the drift relative to some arbitrary point. I used the start of the data as zero. That's the same as setting your wall clock to UTC when you first took it out of the box and plugged it in. If you look in the archives, there is a time-lapse movie make with one frame each minute when the second hand started straight up. I'm pretty sure my setup isn't gaining or losing many cycles. Actually, I'm pretty sure it is picking up an occasional extra cycle because I see them. 10 seconds at 60 Hz is 600 cycles. If you get an extra count, the frequency will be off by 0.1 Hz. Since the normal range is much less than that, a sample with an extra cycle stands out. They are infrequent enough that I look at each one by hand and make a graph like this: http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-2012-Jan-26-a-pick.p ng I'm using a human filter. I haven't tried to automate it. ___ 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.
Re: [time-nuts] 60Hz line data
b...@iaxs.net said: Frankly, I'm puzzled by the graphs that relate to the time offset. All that's available to the observer is the line frequency. Relative time may be inferred with a cycle counter. How is that counter set to UTC? How can you tell the difference between time error from some reference point, and cycles gained or lost in the counting equipment - due to noise and/or computer interrupt servicing routines? The counter isn't set to UTC. The zero point on the vertical offset is arbitrary. All you can measure is the drift relative to some arbitrary point. I used the start of the data as zero. That's the same as setting your wall clock to UTC when you first took it out of the box and plugged it in. If you look in the archives, there is a time-lapse movie make with one frame each minute when the second hand started straight up. I'm pretty sure my setup isn't gaining or losing many cycles. Actually, I'm pretty sure it is picking up an occasional extra cycle because I see them. 10 seconds at 60 Hz is 600 cycles. If you get an extra count, the frequency will be off by 0.1 Hz. Since the normal range is much less than that, a sample with an extra cycle stands out. They are infrequent enough that I look at each one by hand and make a graph like this: http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz-2012-Jan-26-a-pick.p ng I'm using a human filter. I haven't tried to automate it. -- 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.
Re: [time-nuts] 60Hz line data
Hi The utility of the watch crystal is greatly enhanced in a wrist watch by the calibration process on the watch. When they use one in an AC powered clock (say a clock / radio / alarm) , it’s as a backup device. Power goes out and the crystal keeps time. They don’t do much (any at all) calibration in this application. The resultant time error is “ok” for an hour or so. It would be really objectionable over a week or a month. Bob On Jul 27, 2015, at 12:31 AM, Bill Byrom t...@radio.sent.com wrote: In the early 1970's both LED and LSI integrated circuit technology advanced to the point that digital wristwatches were introduced. These used 32,768 Hz crystals. Use of this technology was made in digital desk clocks (such as alarm radio clocks), but I think that for many years it was much less expensive to use the AC line as a frequency standard. Early Mostek clock IC's used the 50/60 Hz powerline as the reference and didn't include provisions for a crystal. The first digital clock I owned was a flip card clock radio in around 1970. An AC line powered synchronous motor slowly flipped minute and hour cards. A few years later I had a Radio Shack LED wristwatch. I see that 32,768 Hz crystals can now be purchased for US $0.15 each in lots of 100. -- Bill Byrom N5BB On Sun, Jul 26, 2015, at 07:08 PM, Dave Martindale wrote: It's not just synchronous-motor clocks that use line frequency as a time reference. I have a Heathkit alarm clock that counts cycles of line frequency as its timebase. I think that was common in the early generations of NMOS clock chips. The clock does have a backup oscillator (powered by a 9 V battery) for use when line voltage disappears, but its accuracy is horrible. I think it's an RC oscillator, and in a power failure of a few hours it will accumulate minutes of time error. So a bunch of people with analog and digital clocks from that era are likely to notice the drift, particularly at 20 minutes/year. When did 32 kHz crystals get cheap enough that line-powered clocks started using them as a time reference instead of counting line cycles? - Dave On Sun, Jul 26, 2015 at 2:25 PM, Bill Byrom t...@radio.sent.com wrote: 60Hz Stability on Power Grid Going Away? http://www.radiomagonline.com/deep-dig/0005/60hz-stability-on-power-grid-going-away/33527 NERC Frequency Response Standard Background Document http://www.nerc.com/comm/oc/rs%20landing%20page%20dl/related%20files/bal-003-1_background_document_clean_20121130.pdf It appears from various comments that with no manual time correction, the accumulated time error in the East Interconnection will typically gain 20+ minutes/year. The West will gain 8 minutes/year and ERCOT (Texas area) will gain 2 minutes/year. http://www.ercot.com/content/meetings/rms/keydocs/2011/0518/03_manual_time_error_correction_elimination_field_trial.doc So don't trust an AC synchronous motor clock in North America. -- Bill Byrom N5BB _ 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. ___ 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.
Re: [time-nuts] 60Hz line data
In the early 1970's both LED and LSI integrated circuit technology advanced to the point that digital wristwatches were introduced. These used 32,768 Hz crystals. Use of this technology was made in digital desk clocks (such as alarm radio clocks), but I think that for many years it was much less expensive to use the AC line as a frequency standard. Early Mostek clock IC's used the 50/60 Hz powerline as the reference and didn't include provisions for a crystal. The first digital clock I owned was a flip card clock radio in around 1970. An AC line powered synchronous motor slowly flipped minute and hour cards. A few years later I had a Radio Shack LED wristwatch. I see that 32,768 Hz crystals can now be purchased for US $0.15 each in lots of 100. -- Bill Byrom N5BB On Sun, Jul 26, 2015, at 07:08 PM, Dave Martindale wrote: It's not just synchronous-motor clocks that use line frequency as a time reference. I have a Heathkit alarm clock that counts cycles of line frequency as its timebase. I think that was common in the early generations of NMOS clock chips. The clock does have a backup oscillator (powered by a 9 V battery) for use when line voltage disappears, but its accuracy is horrible. I think it's an RC oscillator, and in a power failure of a few hours it will accumulate minutes of time error. So a bunch of people with analog and digital clocks from that era are likely to notice the drift, particularly at 20 minutes/year. When did 32 kHz crystals get cheap enough that line-powered clocks started using them as a time reference instead of counting line cycles? - Dave On Sun, Jul 26, 2015 at 2:25 PM, Bill Byrom t...@radio.sent.com wrote: 60Hz Stability on Power Grid Going Away? http://www.radiomagonline.com/deep-dig/0005/60hz-stability-on-power-grid-going-away/33527 NERC Frequency Response Standard Background Document http://www.nerc.com/comm/oc/rs%20landing%20page%20dl/related%20files/bal-003-1_background_document_clean_20121130.pdf It appears from various comments that with no manual time correction, the accumulated time error in the East Interconnection will typically gain 20+ minutes/year. The West will gain 8 minutes/year and ERCOT (Texas area) will gain 2 minutes/year. http://www.ercot.com/content/meetings/rms/keydocs/2011/0518/03_manual_time_error_correction_elimination_field_trial.doc So don't trust an AC synchronous motor clock in North America. -- Bill Byrom N5BB _ 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.
Re: [time-nuts] 60Hz line data
Gotta get some answers from my relative in a PA gas fired plant. A year ago he told me that the plan to deregulate the number of cycles in a day had been abandoned. The referenced documents are older than that. OTOH, there's no other explanation for Hal Murray's observation of the West Coast grid variation. Seems to me that all of the rotating synchronous machinery connected to a grid is constrained by all of that heavy rotating machinery to change speed quite slowly, like starting to change the direction of a ship heading to a port about 5 miles out. There are at least three grids in the US that are independent of each other in frequency. That reduces the strains on a grid from distant changes. Power is transferred using high voltage DC transmission lines. Really large solid state inverters convert between AC and DC. Each inverter can make any frequency it wants to, subject to the constraints of all that synchronous machinery. Frankly, I'm puzzled by the graphs that relate to the time offset. All that's available to the observer is the line frequency. Relative time may be inferred with a cycle counter. How is that counter set to UTC? How can you tell the difference between time error from some reference point, and cycles gained or lost in the counting equipment - due to noise and/or computer interrupt servicing routines? When I asked for data from parts of the country east of the Rockies (on 7/10), I got one reply from a person who is not a member of the list but reads archive sites. He sent his long term graph for Texas and the link to a real-time statistics page that gave him the data for the graph. The statistics are at (strip the stuff after com/ to get the home page and further details): http://www.ercot.com/content/cdr/html/real_time_system_conditions.html His chart (with permission) is at: http://home.earthlink.net/~schultdw/power/all.png In this case, the time reference was given by the power company. No cycles were counted. Regards, Bill Hawkins ___ 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.
Re: [time-nuts] 60Hz line data
I've updated the graph at: http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2014-2015.pn g and added July-2015 at: http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-Jul.png July 19th shifted 15 seconds in one day! The shift is 25 seconds over July 17-19. -- 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.
Re: [time-nuts] 60Hz line data
Hi That correlates quite well with data from the 1960’s before “everybody” was on one big network. Bob On Jul 25, 2015, at 7:25 PM, Hal Murray hmur...@megapathdsl.net wrote: I've updated the graph at: http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2014-2015.pn g and added July-2015 at: http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-Jul.png July 19th shifted 15 seconds in one day! The shift is 25 seconds over July 17-19. -- 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.
Re: [time-nuts] 60Hz line data
There have been a number of proposals to completely eliminate manual time correction (used to keep synchronous clocks accurate over long time periods). There apparently was a manual procedure activated when the error reached +/- 30 seconds from true time, but I think that since 2011 the power grid reliability considerations have caused grid operators to not make any frequency changes for clock time correction. Frequency changes are often made to change the power transfer rate. See: FERC Docket RM14-10-000 Order: Real Power Balancing Control Performance Reliability Standard (issued April 16, 2015) - this doesn't mention use of time error correction! http://www.ferc.gov/whats-new/comm-meet/2015/041615/E-3.PDF FERC docket RM09-13-000: Time Error Correction Reliability Standard http://www.balch.com/files/upload/%284-24-2010%29%20NERC_BAL-004_NOPR_Comments.pdf In October 2012 this petition was withdrawn. 60Hz Stability on Power Grid Going Away? http://www.radiomagonline.com/deep-dig/0005/60hz-stability-on-power-grid-going-away/33527 NERC Frequency Response Standard Background Document http://www.nerc.com/comm/oc/rs%20landing%20page%20dl/related%20files/bal-003-1_background_document_clean_20121130.pdf It appears from various comments that with no manual time correction, the accumulated time error in the East Interconnection will typically gain 20+ minutes/year. The West will gain 8 minutes/year and ERCOT (Texas area) will gain 2 minutes/year. http://www.ercot.com/content/meetings/rms/keydocs/2011/0518/03_manual_time_error_correction_elimination_field_trial.doc So don't trust an AC synchronous motor clock in North America. -- Bill Byrom N5BB On Sun, Jul 26, 2015, at 07:08 AM, Bob Camp wrote: Hi That correlates quite well with data from the 1960’s before “everybody” was on one big network. Bob On Jul 25, 2015, at 7:25 PM, Hal Murray hmur...@megapathdsl.net wrote: I've updated the graph at: http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2014-2015.pn g and added July-2015 at: http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-Jul.png July 19th shifted 15 seconds in one day! The shift is 25 seconds over July 17-19. -- 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. ___ 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.
Re: [time-nuts] 60Hz line data
It's not just synchronous-motor clocks that use line frequency as a time reference. I have a Heathkit alarm clock that counts cycles of line frequency as its timebase. I think that was common in the early generations of NMOS clock chips. The clock does have a backup oscillator (powered by a 9 V battery) for use when line voltage disappears, but its accuracy is horrible. I think it's an RC oscillator, and in a power failure of a few hours it will accumulate minutes of time error. So a bunch of people with analog and digital clocks from that era are likely to notice the drift, particularly at 20 minutes/year. When did 32 kHz crystals get cheap enough that line-powered clocks started using them as a time reference instead of counting line cycles? - Dave On Sun, Jul 26, 2015 at 2:25 PM, Bill Byrom t...@radio.sent.com wrote: 60Hz Stability on Power Grid Going Away? http://www.radiomagonline.com/deep-dig/0005/60hz-stability-on-power-grid-going-away/33527 NERC Frequency Response Standard Background Document http://www.nerc.com/comm/oc/rs%20landing%20page%20dl/related%20files/bal-003-1_background_document_clean_20121130.pdf It appears from various comments that with no manual time correction, the accumulated time error in the East Interconnection will typically gain 20+ minutes/year. The West will gain 8 minutes/year and ERCOT (Texas area) will gain 2 minutes/year. http://www.ercot.com/content/meetings/rms/keydocs/2011/0518/03_manual_time_error_correction_elimination_field_trial.doc So don't trust an AC synchronous motor clock in North America. -- Bill Byrom N5BB ___ 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.
Re: [time-nuts] 60Hz line data
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@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@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.
[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.png 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.png Here are the days before and after the leap second: http://www.megapathdsl.net/~hmurray/time-nuts/line/Calif-60Hz-2015-Jun-30-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-30-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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
