Re: [time-nuts] Logging the grid frequency....
Ok, it´s a relative measurement... now I understand your data. Thank you. Not sure it's relative measurement. Probably best to call it a time error measurement, or a phase measurement (in the timekeeping sense, not the 2*pi sense). Just consider a 60 Hz wall clock; the data is how far wall clock time differs from true time, measured every zero-crossing. So subtracting successive data points gives you period (e.g., 0.017). This brings up a very interesting question. Many of us continuously log data from counters and such. Although cpu speed and disk capacity are high and costs low, it is still worth considering the format of data we collect -- especially if it's data collected over months or years. For example, if I measure 60 Hz zero-crossings for an hour with 100 ns resolution, what is the most compact way to format the data? That's 216,000 samples per hour; 5.184 million per day. Consider these methods: 1) ctime-like time-stamp of zero-crossing Fri Feb 22 23:38:00.2279906 2013 Fri Feb 22 23:38:00.2279906 2013 Fri Feb 22 23:38:00.2446570 2013 Fri Feb 22 23:38:00.2613322 2013 Fri Feb 22 23:38:00.2779954 2013 2) fractional unix time_t of zero-crossing 1361605080.2279906 1361605080.2446570 1361605080.2613322 1361605080.2779954 1361605080.2946650 3) ISO 8601-style (see xkcd.com/1179) 2013-02-22 23:38:00.2279906 2013-02-22 23:38:00.2446570 2013-02-22 23:38:00.2613322 2013-02-22 23:38:00.2779954 2013-02-22 23:38:00.2946650 4) Modified Julian Day (bad idea) 56345.9847248610 56345.9847250539 56345.9847252469 56345.9847254398 56345.9847256327 5) UTC time, one file per day (date in filename) 23:38:00.2279906 23:38:00.2446570 23:38:00.2613322 23:38:00.2779954 23:38:00.2946650 6) STOD (seconds time of day), one file per day 85080.2279906 85080.2446570 85080.2613322 85080.2779954 85080.2946650 7) per-cycle period measurement, date/time implied 0.014 0.0166752 0.0166632 0.0166696 8) per-cycle frequency measurement (bad idea) 60.00096002 59.96929572 60.01248260 59.98944186 9) period minus some nominal value (0.016) -0.002 0.086 -0.034 0.030 10) period - nominal (0.016) and scaled to integer 100 ns units -2 86 -34 30 11) successive difference of period in 100 ns units 14 88 -120 64 -24 12) time/phase difference between DUT and REF 0.003 -0.083 -0.048 -0.077 Most of us with TIC's (time interval counters) use data like #12 because it's natural, convenient, each datum stands on its own. This time series format can be fed directly into time/frequency/stability calculations. The most compact for 60 Hz appears to be #10 or #11, even if awkward to use (but a program can easily convert among any of these formats). Aside from cheap tricks like using binary instead of ascii or using file compression utilities (e.g., g/zip, etc.), does anyone have additional ideas on a compact streaming decimal data format? Thanks, /tvb ___ 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] Logging the grid frequency....
On 03/01/2013 12:26 PM, Tom Van Baak wrote: Ok, it´s a relative measurement... now I understand your data. Thank you. Not sure it's relative measurement. Probably best to call it a time error measurement, or a phase measurement (in the timekeeping sense, not the 2*pi sense). Just consider a 60 Hz wall clock; the data is how far wall clock time differs from true time, measured every zero-crossing. So subtracting successive data points gives you period (e.g., 0.017). This brings up a very interesting question. Many of us continuously log data from counters and such. Although cpu speed and disk capacity are high and costs low, it is still worth considering the format of data we collect -- especially if it's data collected over months or years. For example, if I measure 60 Hz zero-crossings for an hour with 100 ns resolution, what is the most compact way to format the data? That's 216,000 samples per hour; 5.184 million per day. Consider these methods: 1) ctime-like time-stamp of zero-crossing Fri Feb 22 23:38:00.2279906 2013 Fri Feb 22 23:38:00.2279906 2013 Fri Feb 22 23:38:00.2446570 2013 Fri Feb 22 23:38:00.2613322 2013 Fri Feb 22 23:38:00.2779954 2013 2) fractional unix time_t of zero-crossing 1361605080.2279906 1361605080.2446570 1361605080.2613322 1361605080.2779954 1361605080.2946650 3) ISO 8601-style (see xkcd.com/1179) 2013-02-22 23:38:00.2279906 2013-02-22 23:38:00.2446570 2013-02-22 23:38:00.2613322 2013-02-22 23:38:00.2779954 2013-02-22 23:38:00.2946650 4) Modified Julian Day (bad idea) 56345.9847248610 56345.9847250539 56345.9847252469 56345.9847254398 56345.9847256327 5) UTC time, one file per day (date in filename) 23:38:00.2279906 23:38:00.2446570 23:38:00.2613322 23:38:00.2779954 23:38:00.2946650 6) STOD (seconds time of day), one file per day 85080.2279906 85080.2446570 85080.2613322 85080.2779954 85080.2946650 7) per-cycle period measurement, date/time implied 0.014 0.0166752 0.0166632 0.0166696 8) per-cycle frequency measurement (bad idea) 60.00096002 59.96929572 60.01248260 59.98944186 9) period minus some nominal value (0.016) -0.002 0.086 -0.034 0.030 10) period - nominal (0.016) and scaled to integer 100 ns units -2 86 -34 30 11) successive difference of period in 100 ns units 14 88 -120 64 -24 12) time/phase difference between DUT and REF 0.003 -0.083 -0.048 -0.077 Most of us with TIC's (time interval counters) use data like #12 because it's natural, convenient, each datum stands on its own. This time series format can be fed directly into time/frequency/stability calculations. The most compact for 60 Hz appears to be #10 or #11, even if awkward to use (but a program can easily convert among any of these formats). Aside from cheap tricks like using binary instead of ascii or using file compression utilities (e.g., g/zip, etc.), does anyone have additional ideas on a compact streaming decimal data format? The COMTRADE format is interesting in many ways, but one of the key details is that is has a line counter (but can store LOTS of data on each line), which helps to identify if lines are missing or not. The COMTRADE format has a column for time, but it is redundant as start-time and sample rate is completely known, so keeping that column to 0 flags that it should be calculated from the giving info. COMTRADE files is being shared plentiful and can become very large, but it is important to identify broken data so it can be discarded. I have only seen a presentation on it, but it seemed interesting and good enough for many other uses than the intended use. Cheers, Magnus ___ 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] Logging the grid frequency....
Thanks for all the comments about this topic. They are much appreciated. About the difficulty of measuring every cycle with a conventional counter... thanks for that info, seems that i´ll have to make my own measurement hardware. I liked the idea of a time stamping counter it´s very doable in a FPGA :) About the fact that 60Hz mains have a lot of noise... I knew that and that´s part of a PLL job (filter very fast noise), but unfortunately when doing this measurement job we can only use analog filters or else we´ll mess too much with the frequency... i´m using a transformer (to isolate and to give some inductance) with capacitors to make a low pass filter. The PLL design is a wide band type. Seems that frequency stays between 59,95Hz and 60,05Hz for 99,99% of the time... that´s an interesting point too. Daniel Em 22/02/2013 23:09, Bob Camp escreveu: Hi A lot depends on what the real objective is. Is the loop supposed to transfer all of the 60 Hz bumps and wiggles (wide band loop) or is it supposed to ignore them (narrow band loop) ? Given that the starting point is 60 Hz wide and narrow will be relative to that. Bob On Feb 22, 2013, at 7:44 PM, David davidwh...@gmail.com wrote: On Fri, 22 Feb 2013 15:16:37 -0800, Tom Van Baak t...@leapsecond.com wrote: There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. Hal, it might make sense since the OP is designing a PLL and wants to get a feel for (short-term) frequency excursions. I would guess the whole point of his experiment is to quantify this; not just say there is a lot or not much noise over some number N of cycles. So that's why I posted the ADEV plot, which itself was based on timing every zero-crossing (using a time-stamping counter, not a frequency counter). I have been thinking about this problem on and off all day and would probably add a sampling phase detector driven by the output of the PLL or just use a sampling phase detector in the PLL loop. The sampling time can be adjusted independently of the PLL filtering within reason for whatever level of noise rejection in the measurement is desired. That would return the phase error on every cycle or even every half cycle. The whole thing of course could be implemented digitally but I like programming in solder. ___ 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] Logging the grid frequency....
Daniel, I've placed two log files for you under http://leapsecond.com/pages/mains/ log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) Each represents 6 hours of collection time. Units are seconds (elapsed time), resolution is 100 ns, granularity is 400 ns. This data was collected with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. This should be more than enough data to characterize the typical short-term noise and mid-term wander of the (US western) power grid. Of course, the power spectrum in Brazil will likely look different. I'd be interested in seeing your results. Thanks, /tvb - Original Message - From: Daniel Mendes dmend...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, February 28, 2013 6:08 AM Subject: Re: [time-nuts] Logging the grid frequency Thanks for all the comments about this topic. They are much appreciated. About the difficulty of measuring every cycle with a conventional counter... thanks for that info, seems that i´ll have to make my own measurement hardware. I liked the idea of a time stamping counter it´s very doable in a FPGA :) About the fact that 60Hz mains have a lot of noise... I knew that and that´s part of a PLL job (filter very fast noise), but unfortunately when doing this measurement job we can only use analog filters or else we´ll mess too much with the frequency... i´m using a transformer (to isolate and to give some inductance) with capacitors to make a low pass filter. The PLL design is a wide band type. Seems that frequency stays between 59,95Hz and 60,05Hz for 99,99% of the time... that´s an interesting point too. Daniel Em 22/02/2013 23:09, Bob Camp escreveu: Hi A lot depends on what the real objective is. Is the loop supposed to transfer all of the 60 Hz bumps and wiggles (wide band loop) or is it supposed to ignore them (narrow band loop) ? Given that the starting point is 60 Hz wide and narrow will be relative to that. Bob On Feb 22, 2013, at 7:44 PM, David davidwh...@gmail.com wrote: On Fri, 22 Feb 2013 15:16:37 -0800, Tom Van Baak t...@leapsecond.com wrote: There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. Hal, it might make sense since the OP is designing a PLL and wants to get a feel for (short-term) frequency excursions. I would guess the whole point of his experiment is to quantify this; not just say there is a lot or not much noise over some number N of cycles. So that's why I posted the ADEV plot, which itself was based on timing every zero-crossing (using a time-stamping counter, not a frequency counter). I have been thinking about this problem on and off all day and would probably add a sampling phase detector driven by the output of the PLL or just use a sampling phase detector in the PLL loop. The sampling time can be adjusted independently of the PLL filtering within reason for whatever level of noise rejection in the measurement is desired. That would return the phase error on every cycle or even every half cycle. The whole thing of course could be implemented digitally but I like programming in solder. ___ 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] Logging the grid frequency....
On 2/28/2013 11:37 AM, time-nuts-requ...@febo.com wrote: About the difficulty of measuring every cycle with a conventional counter... thanks for that info, seems that i?ll have to make my own measurement hardware. I liked the idea of a time stamping counter it?s very doable in a FPGA:) At work we have a similar issue, where we need to measure the frequency of every cycle of a pulse train running from a few Khz to 100Khz. We built a dedicated data acquisition system that will do just this. It will actually measure 8 independent frequency chains and ship the data via USB to a PC. This is referred to a 200Mhz clock (~5nS resolution). It took took a while to finish to the thing, but managed to pack it into an CPLD clocked at 200Mhz. It also has 6 CH of analog input +/- 10V at 14bit resolution at up to 125Khz sample rate, just for extra stuff one might want to add in... Something like this is probably overkill for your application, but is possible to pack it all into one chip. If you were doing one channel, it'd be pretty simple to do. Dan ___ 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] Logging the grid frequency....
Em 28/02/2013 13:37, Tom Van Baak escreveu: Daniel, I've placed two log files for you under http://leapsecond.com/pages/mains/ log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) Each represents 6 hours of collection time. Units are seconds (elapsed time), resolution is 100 ns, granularity is 400 ns. This data was collected with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. This isn´t very clear to me. First few lines say: 0.000 -0.029 -0.071 -0.064 0.027 -0.099 -0.176 Time went backwards? Daniel ___ 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] Logging the grid frequency....
Yes, correct, sometimes the power line goes faster than 60 Hz in which case the zero-crossings occur before you expect them; so time error can be negative, on average, as often as it is positive. You cannot design a PLL that always expects phase error to be unidirectional. The data I provided is time error relative to an ideal 60 Hz; this data can be both positive and negative; and both gaining and losing, as well as both accelerating and decelerating. Welcome to the interesting world of time frequency, even at 60 Hz. /tvb (iPhone4) On Feb 28, 2013, at 10:42 AM, Daniel Mendes dmend...@gmail.com wrote: Em 28/02/2013 13:37, Tom Van Baak escreveu: Daniel, I've placed two log files for you under http://leapsecond.com/pages/mains/ log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) Each represents 6 hours of collection time. Units are seconds (elapsed time), resolution is 100 ns, granularity is 400 ns. This data was collected with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. This isn´t very clear to me. First few lines say: 0.000 -0.029 -0.071 -0.064 0.027 -0.099 -0.176 Time went backwards? Daniel ___ 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] Logging the grid frequency....
Ok, it´s a relative measurement... now I understand your data. Thank you. Daniel Em 28/02/2013 20:03, Tom Van Baak (lab) escreveu: Yes, correct, sometimes the power line goes faster than 60 Hz in which case the zero-crossings occur before you expect them; so time error can be negative, on average, as often as it is positive. You cannot design a PLL that always expects phase error to be unidirectional. The data I provided is time error relative to an ideal 60 Hz; this data can be both positive and negative; and both gaining and losing, as well as both accelerating and decelerating. Welcome to the interesting world of time frequency, even at 60 Hz. /tvb (iPhone4) On Feb 28, 2013, at 10:42 AM, Daniel Mendes dmend...@gmail.com wrote: Em 28/02/2013 13:37, Tom Van Baak escreveu: Daniel, I've placed two log files for you under http://leapsecond.com/pages/mains/ log1932.dat.gz -- timing of every 60 Hz zero-crossing (1.296 million samples) log97312.dat.gz -- timing of every 60th zero-crossing (21.6 thousand samples) Each represents 6 hours of collection time. Units are seconds (elapsed time), resolution is 100 ns, granularity is 400 ns. This data was collected with a picPET (http://leapsecond.com/pic) using an accurate 10 MHz reference. This isn´t very clear to me. First few lines say: 0.000 -0.029 -0.071 -0.064 0.027 -0.099 -0.176 Time went backwards? Daniel ___ 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] Logging the grid frequency....
On Thu, Feb 28, 2013 at 6:08 AM, Daniel Mendes dmend...@gmail.com wrote: Thanks for all the comments about this topic. They are much appreciated. About the difficulty of measuring every cycle with a conventional counter... thanks for that info, seems that i´ll have to make my own measurement hardware. I liked the idea of a time stamping counter it´s very doable in a FPGA :) FPGA?? All you need is a standard PC with an RS232 port and a 6V transformers and you can use the pC normally while it is logging. Works at the microsecond level. Software is already available. Chris Albertson Redondo Beach, California ___ 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] Logging the grid frequency....
We had a problem some time ago with a large power system where I work. It would shut down every day around 7:00AM. It turns out that is when the power company switches large capacitors in to correct the poor power factor caused by inductive loads that are turned on when businesses start the work day. It took a while but after we convinced ourselves it had to be a line transient, we ended recording the transient with a Dranetz. It was only once a day, so it would probably not have affected ADEV significantly, but it sure caused havoc with our equipment. It caused ringing that would definitely have affected a zero crossing detector. Didier Sent from my Droid Razr 4G LTE wireless tracker. -Original Message- From: David davidwh...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sat, 23 Feb 2013 4:14 PM Subject: Re: [time-nuts] Logging the grid frequency That was on my mind when I suggested a sampling phase comparator with the sampling time adjusted for noise rejection. Of course since I have been doing a lot of research recently on sampler design, every problem looks like a nail. :) Thyristor commutation into a reactive load can be nasty but I have heard horror stories about inverters as well. On Sat, 23 Feb 2013 14:05:36 -0500, Peter Gottlieb n...@verizon.net wrote: Some grid connected inverters have a LOT of noise around the zero crossings, so much so that certain digital power meters won't function as they can't get frequency lock. I've seen this on the large Parker units as well as the low bid units out of China. So if you have solar or wind farm alternative energy projects nearby you may indeed see excessive noise. Excess noise and high order harmonics from such inverters has on occasion caused capacitive line filters on nearby equipment to overheat and catch fire. Peter On 2/23/2013 7:53 AM, Didier Juges wrote: I am curious how this compares with the zero crossing method. I suppose it should work much better because this method will not be so sensitive to noise around the zero crossings. It will use the entire waveform. Didier Sent from my Droid Razr 4G LTE wireless tracker. -Original Message- From: Gabs Ricalde gsrica...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Fri, 22 Feb 2013 9:01 PM Subject: Re: [time-nuts] Logging the grid frequency Hello, I also don't have a Picotest or similar equipment but I've done similar things by using the line input of a soundcard. Multiply the recorded signal with a 60 Hz quadrature oscillator, apply a low pass filter then do some analysis on the resulting phasor. The stability of the sound card oscillator should be enough for this purpose. You can measure the frequency difference w.r.t. the 60 Hz oscillator by taking the slope of the phasor angle (be careful with phase wraparounds) and you can do this as often as you like. I'm curious how this compares with the zero crossing method. ___ 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] Logging the grid frequency....
On 02/23/13 12:01 PM, John wrote: All, If you want a reason for logging the mains frequency, see the following link to a news item which appeared on a BBC news program a few weeks ago here in the UK. http://www.bbc.co.uk/news/science-environment-20629671 There was also a full program about it which you can listen to at the following link http://www.bbc.co.uk/programmes/b01p7bxw John G3UUT Interesting. I never realized the UK national grid was just one grid, all running at the one frequency. I wonder if there are small variations in frequency at a local level due to all these wind-turbines that seem to be cropping up everywhere? I doubt they will generate a voltage at exactly the same frequency the voltage is coming into them, especially as it is not a constant. I personally object to funding these things so others can make a huge profit from them. Perhaps I can argue they are a threat to national security! Dave -- Dr. David Kirkby Ph.D C.Eng MIET ___ 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] Logging the grid frequency....
By their nature, these distributed generation devices operate in current injection mode. That is, they are synchronized to the line and inject enough current at whatever voltage the line is at (subject to IEEE 1547 provisions, e.g., -12% to +10% of nominal) to transfer the power they need to. So yes, they generate their power at the exact frequency the line is at. They are all four-quadrant devices and can also generate quadrature (imaginary) power as well so can correct for power factor problems. All the decent sized inverters I have seen are tightly phase locked to the line. Now here's a fun thing to think about: due to safety concerns the power company does not want any of these things to generate power if a line goes down. They call this a power island. So every inverter must have detection for this condition. It's trivial to detect if the load on the island is different than the inverter output - the voltage will immediately go out of bounds - but not so easy to detect if the island load matches the inverter output. so, what to do? One thing manufacturers do is to wiggle the Q (imaginary power) output and see if it shows up. If they're connected to the grid, well, they're way too small to move the overall power factor but if they're the only source, it shows right up! So many of these inverters are actually creating a small amount of phase noise onto the mains. In terms of powering things it is insignificant and of no consequence, but when you get to time-nut accuracy and measurement capabilities, I'd bet you can actually see such modulation! If you are out on a long run from the nearest substation it could even throw off your measurements as it will be non-steady and depend on insolation or local wind conditions of the source inverter. As for huge profits, well, not in that industry. Peter On 2/24/2013 11:01 AM, Dr. David Kirkby wrote: On 02/23/13 12:01 PM, John wrote: All, If you want a reason for logging the mains frequency, see the following link to a news item which appeared on a BBC news program a few weeks ago here in the UK. http://www.bbc.co.uk/news/science-environment-20629671 There was also a full program about it which you can listen to at the following link http://www.bbc.co.uk/programmes/b01p7bxw John G3UUT Interesting. I never realized the UK national grid was just one grid, all running at the one frequency. I wonder if there are small variations in frequency at a local level due to all these wind-turbines that seem to be cropping up everywhere? I doubt they will generate a voltage at exactly the same frequency the voltage is coming into them, especially as it is not a constant. I personally object to funding these things so others can make a huge profit from them. Perhaps I can argue they are a threat to national security! Dave ___ 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] Logging the grid frequency....
So it is not correct to measure one point to a gnat's nose hair and call it the grid frequency. Bill, Yes, and this is true for any source of frequency. That's why when we specify stability the averaging interval is critical; the x-axis of a log-log ADEV plot. One might look at every cycle to measure stuff like jitter, not so much to measure frequency over a tau of 0.016 seconds. The nice thing about ADEV is that a single plot can convey frequency stability for all intervals from as short as a single cycle to as long as days or months or more. Now with a 10 MHz standard we don't normally start an ADEV plot at a single (100 ns) cycle. But for 60 Hz it's perfectly natural to do so. A histogram of period is another way to show variations in cycle time. This gives more information than a single ADEV point. But to show variations as a function of averaging time, a whole set of separate histograms, or overlaid histograms, are required. It might be more accurate to put a flywheel on a synchronous motor and measure its speed, because the time constant of that system is a whole lot closer to that of the real grid frequency. I too was suspicious of digital or PLL or filtered methods of monitoring 60 Hz phase. To validate the digital methods I compared against an old synchronous wall clock. In the following animated GIF, a photo was taken exactly every 900 seconds (15 minutes): http://leapsecond.com/pages/tec/mains-clock-ani.gif It turns out the zero-crossing microprocessor digital time-stamping method exactly agreed with the old mechanical synchronous motor/inertia method. Satisfied with this result, I do all my mains phase/frequency logging using the digital time-stamp method (picPET). /tvb ___ 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] Logging the grid frequency....
All, If you want a reason for logging the mains frequency, see the following link to a news item which appeared on a BBC news program a few weeks ago here in the UK. http://www.bbc.co.uk/news/science-environment-20629671 There was also a full program about it which you can listen to at the following link http://www.bbc.co.uk/programmes/b01p7bxw John G3UUT On 23/02/2013 08:15, Tom Van Baak wrote: So it is not correct to measure one point to a gnat's nose hair and call it the grid frequency. Bill, Yes, and this is true for any source of frequency. That's why when we specify stability the averaging interval is critical; the x-axis of a log-log ADEV plot. One might look at every cycle to measure stuff like jitter, not so much to measure frequency over a tau of 0.016 seconds. The nice thing about ADEV is that a single plot can convey frequency stability for all intervals from as short as a single cycle to as long as days or months or more. Now with a 10 MHz standard we don't normally start an ADEV plot at a single (100 ns) cycle. But for 60 Hz it's perfectly natural to do so. A histogram of period is another way to show variations in cycle time. This gives more information than a single ADEV point. But to show variations as a function of averaging time, a whole set of separate histograms, or overlaid histograms, are required. It might be more accurate to put a flywheel on a synchronous motor and measure its speed, because the time constant of that system is a whole lot closer to that of the real grid frequency. I too was suspicious of digital or PLL or filtered methods of monitoring 60 Hz phase. To validate the digital methods I compared against an old synchronous wall clock. In the following animated GIF, a photo was taken exactly every 900 seconds (15 minutes): http://leapsecond.com/pages/tec/mains-clock-ani.gif It turns out the zero-crossing microprocessor digital time-stamping method exactly agreed with the old mechanical synchronous motor/inertia method. Satisfied with this result, I do all my mains phase/frequency logging using the digital time-stamp method (picPET). /tvb ___ time-nuts mailing list --time-nuts@febo.com To unsubscribe, go tohttps://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] Logging the grid frequency....
Some grid connected inverters have a LOT of noise around the zero crossings, so much so that certain digital power meters won't function as they can't get frequency lock. I've seen this on the large Parker units as well as the low bid units out of China. So if you have solar or wind farm alternative energy projects nearby you may indeed see excessive noise. Excess noise and high order harmonics from such inverters has on occasion caused capacitive line filters on nearby equipment to overheat and catch fire. Peter On 2/23/2013 7:53 AM, Didier Juges wrote: I am curious how this compares with the zero crossing method. I suppose it should work much better because this method will not be so sensitive to noise around the zero crossings. It will use the entire waveform. Didier Sent from my Droid Razr 4G LTE wireless tracker. -Original Message- From: Gabs Ricalde gsrica...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Fri, 22 Feb 2013 9:01 PM Subject: Re: [time-nuts] Logging the grid frequency Hello, I also don't have a Picotest or similar equipment but I've done similar things by using the line input of a soundcard. Multiply the recorded signal with a 60 Hz quadrature oscillator, apply a low pass filter then do some analysis on the resulting phasor. The stability of the sound card oscillator should be enough for this purpose. You can measure the frequency difference w.r.t. the 60 Hz oscillator by taking the slope of the phasor angle (be careful with phase wraparounds) and you can do this as often as you like. I'm curious how this compares with the zero crossing method. On Fri, Feb 22, 2013 at 8:46 PM, Daniel Mendes dmend...@gmail.com wrote: Hi, I have a Picotest U6200A. I´m trying to log the grid frequency (60Hz) to generate data for my work. I need to get data from every cycle. I setup their program (it always starts in chinese... very funny) but seems that it can only log every 100ms. Questions: 1) Is that a limitation of the equipment or the software? 2) Using direct comands, can I get data faster? Thanks for any help... Daniel ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1430 / Virus Database: 2639/5625 - Release Date: 02/23/13 ___ 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] Logging the grid frequency....
That was on my mind when I suggested a sampling phase comparator with the sampling time adjusted for noise rejection. Of course since I have been doing a lot of research recently on sampler design, every problem looks like a nail. :) Thyristor commutation into a reactive load can be nasty but I have heard horror stories about inverters as well. On Sat, 23 Feb 2013 14:05:36 -0500, Peter Gottlieb n...@verizon.net wrote: Some grid connected inverters have a LOT of noise around the zero crossings, so much so that certain digital power meters won't function as they can't get frequency lock. I've seen this on the large Parker units as well as the low bid units out of China. So if you have solar or wind farm alternative energy projects nearby you may indeed see excessive noise. Excess noise and high order harmonics from such inverters has on occasion caused capacitive line filters on nearby equipment to overheat and catch fire. Peter On 2/23/2013 7:53 AM, Didier Juges wrote: I am curious how this compares with the zero crossing method. I suppose it should work much better because this method will not be so sensitive to noise around the zero crossings. It will use the entire waveform. Didier Sent from my Droid Razr 4G LTE wireless tracker. -Original Message- From: Gabs Ricalde gsrica...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Fri, 22 Feb 2013 9:01 PM Subject: Re: [time-nuts] Logging the grid frequency Hello, I also don't have a Picotest or similar equipment but I've done similar things by using the line input of a soundcard. Multiply the recorded signal with a 60 Hz quadrature oscillator, apply a low pass filter then do some analysis on the resulting phasor. The stability of the sound card oscillator should be enough for this purpose. You can measure the frequency difference w.r.t. the 60 Hz oscillator by taking the slope of the phasor angle (be careful with phase wraparounds) and you can do this as often as you like. I'm curious how this compares with the zero crossing method. ___ 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] Logging the grid frequency....
Hi Don't have a Picotest, but do have similar counters. It's very common for them to do what looks like a divide of the input frequency before they measure it. The net result is that you can't measure 60 Hz in 1/60th of a second. You measure it in 4/60th's of a second instead. The next problem you will run into is that the counter takes time to arm. Even if it did the measure in 1/60th of a second, you would only get every other cycle. One way to get every cycle is to measure time rather than frequency. You time tag every positive zero crossing and then do the math to get frequency. If you drive one input with a fixed 60 Hz square wave and put the line into the other input you can get the time offset between them. Another approach is to use two conventional period counters and let them each measure a cycle. One measures while the other is dumping data and re-arming. Bob -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Daniel Mendes Sent: Friday, February 22, 2013 7:47 AM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Logging the grid frequency Hi, I have a Picotest U6200A. I´m trying to log the grid frequency (60Hz) to generate data for my work. I need to get data from every cycle. I setup their program (it always starts in chinese... very funny) but seems that it can only log every 100ms. Questions: 1) Is that a limitation of the equipment or the software? 2) Using direct comands, can I get data faster? Thanks for any help... Daniel ___ 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] Logging the grid frequency....
Curiosity makes me wonder why you want to measure cycle-by-cycle variations in the generator frequency. Are you looking for cycle swing when the load changes? Or is it a matter of wanting to because you should be able to? Which, of course, is a great reason for doing all sorts of things! -Chuck Harris Daniel Mendes wrote: Hi, I have a Picotest U6200A. I´m trying to log the grid frequency (60Hz) to generate data for my work. I need to get data from every cycle. I setup their program (it always starts in chinese... very funny) but seems that it can only log every 100ms. Questions: 1) Is that a limitation of the equipment or the software? 2) Using direct comands, can I get data faster? Thanks for any help... Daniel ___ 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] Logging the grid frequency....
No, just designing a very wicked PLL and needing statistics of the frequency derivative... No generator is involved, it´s mains frequency (but you gave me another idea... thanks!). Daniel Em 22/02/2013 11:53, Chuck Harris escreveu: Curiosity makes me wonder why you want to measure cycle-by-cycle variations in the generator frequency. Are you looking for cycle swing when the load changes? Or is it a matter of wanting to because you should be able to? Which, of course, is a great reason for doing all sorts of things! -Chuck Harris Daniel Mendes wrote: Hi, I have a Picotest U6200A. I´m trying to log the grid frequency (60Hz) to generate data for my work. I need to get data from every cycle. I setup their program (it always starts in chinese... very funny) but seems that it can only log every 100ms. Questions: 1) Is that a limitation of the equipment or the software? 2) Using direct comands, can I get data faster? Thanks for any help... Daniel ___ 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] Logging the grid frequency....
dmend...@gmail.com said: No, just designing a very wicked PLL and needing statistics of the frequency derivative... No generator is involved, it´s mains frequency (but you gave me another idea... thanks!). There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. Two suggestions: With a transformer and a few resistors, you can feed the line into the audio input on a PC. Then you can search for zero crossings, run it through a filter, feed it to a FFT... You can also feed the line into a modem control signal on a PC serial port. (USB probably won't work.) The PPS logic from NTP will count cycles and record a timestamp on the last one. -- 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] Logging the grid frequency....
People have measured AC mains period (and hence frequency) with very simple devices. The best is just an AC plug-in power cube and a diode to square the sine wave then this is connected directly to a DCD input on a serial port. The Linix PPS driver will time tage each pulse with a nanosecond timer that is good really only to about two microseconds. This is better than good enough. All you need is a computer and a few bucks worth of parts. Here is one setup using DCD as the sensor http://wwwhome.cs.utwente.nl/~ptdeboer/misc/mains.html The newels PPS software will do the logging now. What you are left with is a file that lists the time of each zero crossing. You get 60 new lines of text every second. -- Chris Albertson Redondo Beach, California ___ 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] Logging the grid frequency....
On Fri, Feb 22, 2013 at 10:47 AM, Hal Murray hmur...@megapathdsl.net wrote: You can also feed the line into a modem control signal on a PC serial port. (USB probably won't work.) The PPS logic from NTP will count cycles and record a timestamp on the last one. Yes RS-232 wants a signal that is about +/- 9 volts. so if you are very brave all you need is a 15:1 voltage divider on the AC to scale it. However it is smarter to use a transformer. Some others who are even more conservative were using an optocoupler between the AC mains and the PC's serial port. But I think the transformer provides good enough isolation. -- 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. -- Chris Albertson Redondo Beach, California ___ 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] Logging the grid frequency....
There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. Hal, it might make sense since the OP is designing a PLL and wants to get a feel for (short-term) frequency excursions. I would guess the whole point of his experiment is to quantify this; not just say there is a lot or not much noise over some number N of cycles. So that's why I posted the ADEV plot, which itself was based on timing every zero-crossing (using a time-stamping counter, not a frequency counter). Two suggestions: With a transformer and a few resistors, you can feed the line into the audio input on a PC. Then you can search for zero crossings, run it through a filter, feed it to a FFT... You can also feed the line into a modem control signal on a PC serial port. (USB probably won't work.) The PPS logic from NTP will count cycles and record a timestamp on the last one. For those of you using plain old Windows instead of NTP/PPS/Linux I have a DCD pin serial port time-stamping tool which works pretty well (on an idle system) to measure every cycle, 60 lines per second: http://leapsecond.com/tools/pctsc.c http://leapsecond.com/tools/pctsc.exe Since the DCD pin is bipolar by design one can connect the secondary of, say, a 6 or 9 or 12 VAC wall transformer directly to pins 1 and 5. Use a 1k resistor if you're paranoid. It works fine with direct COM ports or USB/serial adapters. /tvb ___ 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] Logging the grid frequency....
Bob, You're right that conventional period, frequency, or universal counters have great difficulty measuring (timing) separate events that occur as fast as 60 Hz. A fine exception is the Pendulum CNT-90/91 which is a time-stamping universal counter. With a few simple GPIB commands, you get data on every rising/falling edge of an input signal. The resolution is 50 ps and the capture rate is 250k sps. If anyone has been able to collect zero-deadtime per-cycle timing using, say, a HP 5370 or 53132 or SR620 I would be interested to know it was done. It might actually be possible, but I've not tried hard enough. The HP 5372A is another possibility. /tvb - Original Message - From: Bob Camp li...@rtty.us To: 'Discussion of precise time and frequency measurement' time-nuts@febo.com Sent: Friday, February 22, 2013 5:34 AM Subject: Re: [time-nuts] Logging the grid frequency Hi Don't have a Picotest, but do have similar counters. It's very common for them to do what looks like a divide of the input frequency before they measure it. The net result is that you can't measure 60 Hz in 1/60th of a second. You measure it in 4/60th's of a second instead. The next problem you will run into is that the counter takes time to arm. Even if it did the measure in 1/60th of a second, you would only get every other cycle. One way to get every cycle is to measure time rather than frequency. You time tag every positive zero crossing and then do the math to get frequency. If you drive one input with a fixed 60 Hz square wave and put the line into the other input you can get the time offset between them. Another approach is to use two conventional period counters and let them each measure a cycle. One measures while the other is dumping data and re-arming. Bob -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Daniel Mendes Sent: Friday, February 22, 2013 7:47 AM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Logging the grid frequency Hi, I have a Picotest U6200A. I´m trying to log the grid frequency (60Hz) to generate data for my work. I need to get data from every cycle. I setup their program (it always starts in chinese... very funny) but seems that it can only log every 100ms. Questions: 1) Is that a limitation of the equipment or the software? 2) Using direct comands, can I get data faster? Thanks for any help... Daniel ___ 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] Logging the grid frequency....
On Fri, 22 Feb 2013 15:16:37 -0800, Tom Van Baak t...@leapsecond.com wrote: There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. Hal, it might make sense since the OP is designing a PLL and wants to get a feel for (short-term) frequency excursions. I would guess the whole point of his experiment is to quantify this; not just say there is a lot or not much noise over some number N of cycles. So that's why I posted the ADEV plot, which itself was based on timing every zero-crossing (using a time-stamping counter, not a frequency counter). I have been thinking about this problem on and off all day and would probably add a sampling phase detector driven by the output of the PLL or just use a sampling phase detector in the PLL loop. The sampling time can be adjusted independently of the PLL filtering within reason for whatever level of noise rejection in the measurement is desired. That would return the phase error on every cycle or even every half cycle. The whole thing of course could be implemented digitally but I like programming in solder. ___ 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] Logging the grid frequency....
Hi A lot depends on what the real objective is. Is the loop supposed to transfer all of the 60 Hz bumps and wiggles (wide band loop) or is it supposed to ignore them (narrow band loop) ? Given that the starting point is 60 Hz wide and narrow will be relative to that. Bob On Feb 22, 2013, at 7:44 PM, David davidwh...@gmail.com wrote: On Fri, 22 Feb 2013 15:16:37 -0800, Tom Van Baak t...@leapsecond.com wrote: There is a lot of noise on the line. I'm not sure if frequency makes sense on a cycle to cycle basis. Hal, it might make sense since the OP is designing a PLL and wants to get a feel for (short-term) frequency excursions. I would guess the whole point of his experiment is to quantify this; not just say there is a lot or not much noise over some number N of cycles. So that's why I posted the ADEV plot, which itself was based on timing every zero-crossing (using a time-stamping counter, not a frequency counter). I have been thinking about this problem on and off all day and would probably add a sampling phase detector driven by the output of the PLL or just use a sampling phase detector in the PLL loop. The sampling time can be adjusted independently of the PLL filtering within reason for whatever level of noise rejection in the measurement is desired. That would return the phase error on every cycle or even every half cycle. The whole thing of course could be implemented digitally but I like programming in solder. ___ 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] Logging the grid frequency....
Hello, I also don't have a Picotest or similar equipment but I've done similar things by using the line input of a soundcard. Multiply the recorded signal with a 60 Hz quadrature oscillator, apply a low pass filter then do some analysis on the resulting phasor. The stability of the sound card oscillator should be enough for this purpose. You can measure the frequency difference w.r.t. the 60 Hz oscillator by taking the slope of the phasor angle (be careful with phase wraparounds) and you can do this as often as you like. I'm curious how this compares with the zero crossing method. On Fri, Feb 22, 2013 at 8:46 PM, Daniel Mendes dmend...@gmail.com wrote: Hi, I have a Picotest U6200A. I´m trying to log the grid frequency (60Hz) to generate data for my work. I need to get data from every cycle. I setup their program (it always starts in chinese... very funny) but seems that it can only log every 100ms. Questions: 1) Is that a limitation of the equipment or the software? 2) Using direct comands, can I get data faster? Thanks for any help... Daniel ___ 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] Logging the grid frequency....
Friends, The grid contains a massive amount of inertia in the rotating synchronous machinery that generates power. The 'springiness' of the transmission lines allows local noise and even phase noise that is caused by loads added to or dropped from the line. Hal Murray (ICBW) had pictures of individual cycles that were badly distorted by changing taps on distribution transformers. So it is not correct to measure one point to a gnat's nose hair and call it the grid frequency. It might be more accurate to put a flywheel on a synchronous motor and measure its speed, because the time constant of that system is a whole lot closer to that of the real grid frequency. Now, I understand that nobody build things like that any more, so perhaps a mathematical model of such a system could be solved by a computer that samples the line voltage at about 100 times line frequency. But perhaps I have misunderstood what you have been talking about. 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] Logging the grid frequency....
I think you have to ask what is the use that is going to be made of that number. Do you want to know how well an old synchronous clock will keep time or do you want to know when there's been an (inductive) phase shift that signifies the loss of a transmission line? Are you interested in how phase relates at various parts of the system (synchrophasors)? How fast do you need to detect and how fast do you need to react (if that is your intent). Or do you just want to log and make pretty graphs later? You have to answer questions like this before you can say what is appropriate or not as a measurement means, and that's where this is heading, yes? On 2/22/2013 11:21 PM, Bill Hawkins wrote: Friends, The grid contains a massive amount of inertia in the rotating synchronous machinery that generates power. The 'springiness' of the transmission lines allows local noise and even phase noise that is caused by loads added to or dropped from the line. Hal Murray (ICBW) had pictures of individual cycles that were badly distorted by changing taps on distribution transformers. So it is not correct to measure one point to a gnat's nose hair and call it the grid frequency. It might be more accurate to put a flywheel on a synchronous motor and measure its speed, because the time constant of that system is a whole lot closer to that of the real grid frequency. Now, I understand that nobody build things like that any more, so perhaps a mathematical model of such a system could be solved by a computer that samples the line voltage at about 100 times line frequency. But perhaps I have misunderstood what you have been talking about. 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1430 / Virus Database: 2639/5624 - Release Date: 02/22/13 ___ 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.
