Hi, On 03/11/2018 12:53 PM, Bob kb8tq wrote: > Hi > > So, how good is “good enough?”. My first attempt ran a counter with a 1 us > period resolution. > (remember, it was tube based …). That turned out to be major overkill in > terms of line frequency > measurement. 60.123 Hz is doing pretty well in terms of line frequency. Even > to get that level, you > will be doing a bit of filtering (or you are just watching the last two > digits pop around randomly). > > Your typical time base in a PC is good to a few hundred ppm. That’s giving > you an error in the > fourth digit of your measurement. With a bit of luck, your sound card > timebase may be 5X > more accurate than your system clock. (or it may be worse …) it depends a bit > on how fancy > your audio setup is. > > Adding NTP to your PC will correct for any long term errors. In a rational > environment it should > get you into the “few ppm” range short term and zero error long term. > > A GPS gizmo will get you into the parts per billion (or better) range. It > might be 100’s of ppb, but it’s > still *way* better than your CPU clock. The usual auction sites have lots of > candidates in the sub $50 > range.There are also places that are happy to sell you shields with GPS > devices on them. > > A fancier yet solution is a GPSDO. We are well into overkill at this point. > The advantage to using > one is that it may be the time / frequency standard for your entire lab > setup. You are up in the > $100 to $500 range for most of them. They will get you into 10’s or 100’s of > parts per trillion. > > There are indeed *lots* of different time sources you could use. The number > of alternatives is > *much* larger than what’s on the list above.
It so depends on what you do. Power-grid folks uses phasor-measurement units, following the IEEE C37.118.1 and .2 spec. In that you sample the V and/or I of the phases at high rate, downconvert it with a specified filter to whatever report-rate is requested, frequency shift it with a reference 50 Hz or 60 Hz and then timestamp measurements. For 60 Hz systems, reportrate of 30 samples per second is fairly common, but both 60 and 120 samples per second is in use. To meet the 0,1 % Total Vector Error, the timing needs to be within 22 us, but measurement noise can be well below 1 us, reaching for 100 ns. The post-processing of the PMU crunches out phase, frequency and Rate-Of-Change-Of-Frequency. The ROCOF is what we time-nuts call linear frequency drift. The remote post-processing can find islanding, inter-area oscillations, forces oscillations beyond the clear evidence of over and under production of power. You can see when the network shakes for a larger even when a whole section of a network oscillates between overpowered and underpowered before the ringing dies out. Care must be taken to use data that is remote and local to get good observability of mode. This also depends on wither you measure voltage or current, and voltage will only have observability on the ends where as current will have observability in the middle, just as you expect from a half-wave bipole antenna. For phase measures, you want to compare two measures to see the phase difference between two points. It is interesting to see two sources struggle to balance and how that changes with power consumption, power production and strength of the interconnected network. Find out more here: https://rubidium.dyndns.org/~magnus/papers/KTH_paper1.pdf In general, NASPI has a wide range of publications online that may be of good reference. They formmed the Time Synchronization Task Force as a result of me informing them about the 26 Jan 2016 incident, and their report could be useful for many: https://www.naspi.org/node/608 Cheers, Magnus > > Bob > >> On Mar 10, 2018, at 11:46 PM, Tom Van Baak <t...@leapsecond.com> wrote: >> >>> I've done some Googling and have found any number of designs. >> >> Pat, >> >> 1) Safety. I usually use a low voltage step-down transformer. This gives >> isolation and safety. Anything from 3 VAC to 24 VAC is fine. >> >> 2) Trigger. There are dozens of schematics on the web for capturing the >> zero-crossing of a low-voltage sine wave. You can easily go overboard on >> this. Or just keep it simple and feed the signal through a resistor directly >> into a microprocessor input. The internal clamping diodes do their thing. A >> Schmitt trigger input is helpful but not necessary depending on how your >> software makes the measurement. >> >> 3) Timebase. Given the long-term accuracy of mains (seconds a day, seconds a >> year) you don't need an atomic timebase. If you collect data for a couple of >> days any old XO will be fine. If you plan to collect data for months you may >> want a OCXO. Most of us just use cheap GPS receivers. >> >> 4) Measurement. There are many ways to measure the signal. You can measure >> frequency directly, as with a frequency counter. You get nice data but it >> may not be perfect long-term due to dead time or gating effects in the >> counter. >> >> So what most of us do is measure phase (time error) instead. One way is to >> make time interval measurements from a given mains cycle to a GPS 1PPS tick >> or vice versa, from each GPS/1PPS tick to the very next mains cycle. Either >> way you get about sample per second. If you're in search of perfection it >> gets a bit tricky when the two signals are in a coincidence zone. >> >> The other approach is not to use a frequency or time interval counter at >> all. Instead you timestamp each cycle, or every 60th cycle. Unix-like >> systems have this capability. See Hal's posting. I use a picPET, a PIC >> microcontroller that takes snapshots of a free-running decimal counter >> driven by a 10 MHz timebase (OCXO or GPSDO). >> >> The advantage of the timestamp method is that you don't ever miss samples, >> you can time every cycle (if you want), or throw away all but one sample per >> second or per 10 seconds or per minute, etc. And best of all, timestamping >> avoids the hassles of the coincidence zone. >> >> 5) CPU. A plain microcontroller, or Arduino, or R-Pi can be used. Or if >> you're on Windows and have a native or USB serial port try this simple tool >> as a demo: >> >> http://leapsecond.com/tools/pctsc.exe >> http://leapsecond.com/tools/pctsc.c >> >> 6) An assortment of mains links: >> >> http://leapsecond.com/pages/mains/ >> http://leapsecond.com/pages/mains-cv/ >> http://wwwhome.cs.utwente.nl/~ptdeboer/misc/mains.html >> http://leapsecond.com/pages/mains/mains-adev-mdev-gnuplot-g4.png >> http://leapsecond.com/pages/tec/mains-clock-ani.gif >> http://leapsecond.com/pages/ac-detect/ >> http://leapsecond.com/pic/picpet.htm >> http://leapsecond.com/pic/pp06.htm >> >> 7) Final comments. >> >> It is tempting to worry about the design, as they are so many out there on >> the web. Which is best? What are the pitfalls? What about noise immunity? >> What about precision and accuracy? My recommendation is not to over-think >> this. Just throw something together and see what you've got. Most of the >> work is with handling the data you get, doing the math, making plots, etc. >> If after the first day you see odd-looking 16 ms jumps in your data then you >> know you need to pay more attention to trigger level or noise issues. >> >> 8) A sound idea. >> >> We need someone to try out the sound card method. Send the isolated low >> voltage AC into the L channel and a GPS 1PPS into the R channel. "The rest >> is just software." Note that because you have access to the entire sine wave >> there's a lot you can do with this method besides making charts of time >> drift or frequency deviation from the zero-crossings. >> >> For an even cheaper solution, forget the GPS receiver and the R channel -- >> since the PC (if running NTP) already knows the correct time. And skip the >> AC transformer too -- instead just hang a foot of wire off the L channel >> input. There's mains hum everywhere. It would be the one time in your life >> where the ever-present audio hum actually has a good use. >> >> /tvb >> >> ----- Original Message ----- >> From: "Patrick Murphy" <fgdhr...@gmail.com> >> To: <email@example.com> >> Sent: Saturday, March 10, 2018 2:53 PM >> Subject: [time-nuts] Recommendations for Mains Power Monitor / Logger >> >> >> All this talk of varying mains power frequency aberrations has me >> curious what is happening in my own back yard here in Tulsa in the >> USA. Can some recommend a reasonable "introductory level" solution for >> this? (As a fledgling Time-Nut, those two words were hard to say.😀) >> At the least I would like to watch voltage and frequency, with a >> configurable monitoring and logging interval. I can provide precise >> timing as needed for synchronization and time-stamping. Expanded >> ability to also monitor amperage, various power factors, etc is a plus >> but not required at this point. >> >> I've done some Googling and have found any number of designs. What I >> can't tell is how well they work. I am pretty handy with my hands and >> do not at all mind a DIY solution. >> >> So what do the Oracles say? >> >> Thanks! >> >> -Pat >> _______________________________________________ >> time-nuts mailing list -- firstname.lastname@example.org >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> _______________________________________________ >> time-nuts mailing list -- email@example.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- firstname.lastname@example.org > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- email@example.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.