Re: [time-nuts] 60 Hz line quirks, anybody recognize this stuff?
On Mon, 03 Sep 2012 12:00:53 -0500, Graham / KE9H time...@austin.rr.com wrote: On 9/1/2012 1:35 AM, Hal Murray wrote: The context is using the 60 Hz line for timing. I'm feeding 60 Hz from a wall wart transformer into a modem control signal that the kernel PPS stuff watches. Mostly, it works as expected, but occasionally, it picks or drops a cycle. In order to understand what was going on, I fed the same signal into the audio input and setup a job to capture the audio. Here is an example of a pick: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a-pick.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a1.png OK, that somewhat makes sense. Something happened several days ago. I used to get picks/drops rarely, say ballpark of 1 a month. Now I'm getting 10 or 20 per day. So I started looking closer. I'm now seeing stuff like this. I've got lots and lots of examples. I added a second PC with different hardware. It sees the same stuff. Does anybody recognize this? http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-b0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-c0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-d0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-e0.png Hal: Two ideas: 1.) You could have some process in Windows that is causing aperiodic blocking of the OS's ability to process real time data. Can be many, many causes. It is very common for a lot of the background processes that autonomously run when you are not actively using the mouse and keyboard to cause these type of problems. Back up utilities, virus checkers, USB WiFi accessories, are examples. (The worst I have seen was the little CPU inside a (Dell) laptop battery, hanging up the USB bus, every time while it calculated the charge in the battery.) Windows is NOT a real time operating system. A fast computer that is not heavily loaded can come close, but there is a lot of background stuff going on in Windows that can aperiodically hang up a lightly loaded machine. Download a DPC tester (Deferred Procedure Call tester) and watch it for an extended time that includes one of your power glitches. http://www.thesycon.de/deu/latency_check.shtml You can add to this list the SMM (system management mode) routines stored in the BIOS. If those are causing the problem then the OS latency performance becomes academic. I have had to qualify motherboards and BIOS revisions before to avoid problems with them. http://en.wikipedia.org/wiki/System_Management_Mode#Problems ___ 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] Rb-Thunderbolt test during a solar eclipse
Remember the man with two clocks: here we are in the same situation. We cannot tell which of the two is being screwed up or maybe both... this is my opinion. Interesting experiment but I think it would be better if a third clock was involved, for example a Cs reference. On Mon, Sep 3, 2012 at 9:16 PM, iov...@inwind.it iov...@inwind.it wrote: Dear time-nuts, a friend of mine, Prof. Alexander Pugach (1), did an experiment on January 15, 2010, comparing a Rb standard to a GPSDO during a solar eclipse. The experimenal site was Kiev, Ukraine. With reference to the attached graph, his text is (note: the red curve belongs to another test; the curve which matters here is the bold blue one): Dear colleagues, An experiment has been made aiming to investigate, how the “daily rate of clock” varies during a solar eclipse on 01.15.2010. In our observatory the high-precision rubidic standard (RbSt) of frequency is exploited. Its indications were compared to a basic frequency from highly stable GPS receiver TRIMBLE Thunderbolt Е. The difference obtained is noted as “residue” and expressed in nanoseconds (ns). This residue was conventially set equal to 0 ns at 00h 00m 13.01.2010. The mean “daily rate of RbSt” equals 2740 ns/d, i.e. 3.17 10-11. In the Figure this rate is shown with blue dashed line. What we have really registered is shown with the bold blue curve. The main minimum of this difference approximately coincided with the eclipse start on the Earth. The derivative on site А-В is approximately 6 times as much as mean “daily rate of RbSt”. 19.02.2010 Apparently, the difference of rate of the two clocks varied by some 4000 ns, A to B, in the 6 hours of duration of the eclipse (s to e = start to end of eclipse at earth, T1-T4 =eclipse in Kiev). I would ask you time-nuts, if such a variation could be simply due to an occasional sum of ordinary adverse factors such as temperature, holdover, sky view, multipath, etc.., or it is really too large to be explained that way. Sorry, I've no idea of what would be the worst case for any of the above factors. Thanks, Antonio I8IOV (1) Prof. Pugach is a senior astronomer at the Academy of Sciences of Ukraine. ___ 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] Rb-Thunderbolt test during a solar eclipse
azelio.bori...@screen.it wrote: Data: 03/09/2012 21.53 Remember the man with two clocks: here we are in the same situation. We cannot tell which of the two is being screwed up or maybe both... This is a different case. No matter what each clock does, what matters is the variation of the difference of rates, the variation, not the difference itself. Interesting experiment but I think it would be better if a third clock was involved, for example a Cs reference. A four-atomic-clock test including an Rb, two Cs and an H maser had been done at another eclipse with null result, but the clocks were at the same location. What is new with this test is that it involves a GPSDO and hence a virtual clock elsewhere. Antonio I8IOV On Mon, Sep 3, 2012 at 9:16 PM, iov...@inwind.it iov...@inwind.it wrote: Dear time-nuts, a friend of mine, Prof. Alexander Pugach (1), did an experiment on January 15, 2010, comparing a Rb standard to a GPSDO during a solar eclipse. The experimenal site was Kiev, Ukraine. With reference to the attached graph, his text is (note: the red curve belongs to another test; the curve which matters here is the bold blue one): Dear colleagues, An experiment has been made aiming to investigate, how the “daily rate of clock” varies during a solar eclipse on 01.15.2010. In our observatory the high-precision rubidic standard (RbSt) of frequency is exploited. Its indications were compared to a basic frequency from highly stable GPS receiver TRIMBLE Thunderbolt Е. The difference obtained is noted as “residue” and expressed in nanoseconds (ns). This residue was conventially set equal to 0 ns at 00h 00m 13.01.2010. The mean “daily rate of RbSt” equals 2740 ns/d, i.e. 3.17 10-11. In the Figure this rate is shown with blue dashed line. What we have really registered is shown with the bold blue curve. The main minimum of this difference approximately coincided with the eclipse start on the Earth. The derivative on site А-В is approximately 6 times as much as mean “daily rate of RbSt”. 19.02.2010 Apparently, the difference of rate of the two clocks varied by some 4000 ns, A to B, in the 6 hours of duration of the eclipse (s to e = start to end of eclipse at earth, T1-T4 =eclipse in Kiev). I would ask you time-nuts, if such a variation could be simply due to an occasional sum of ordinary adverse factors such as temperature, holdover, sky view, multipath, etc.., or it is really too large to be explained that way. Sorry, I've no idea of what would be the worst case for any of the above factors. Thanks, Antonio I8IOV (1) Prof. Pugach is a senior astronomer at the Academy of Sciences of Ukraine. ___ 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] 60 Hz line quirks, anybody recognize this stuff?
On 09/03/2012 12:00 PM, Graham / KE9H wrote: On 9/1/2012 1:35 AM, Hal Murray wrote: The context is using the 60 Hz line for timing. I'm feeding 60 Hz from a wall wart transformer into a modem control signal that the kernel PPS stuff watches. Mostly, it works as expected, but occasionally, it picks or drops a cycle. In order to understand what was going on, I fed the same signal into the audio input and setup a job to capture the audio. Here is an example of a pick: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a-pick.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a1.png OK, that somewhat makes sense. Something happened several days ago. I used to get picks/drops rarely, say ballpark of 1 a month. Now I'm getting 10 or 20 per day. So I started looking closer. I'm now seeing stuff like this. I've got lots and lots of examples. I added a second PC with different hardware. It sees the same stuff. Does anybody recognize this? http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-b0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-c0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-d0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-e0.png Hal: Two ideas: 1.) You could have some process in Windows that is causing aperiodic blocking of the OS's ability to process real time data. Can be many, many causes. Hmmm - but wouldn't that result in missing samples and an abrupt phase jump? The waveforms reported appear phase continuous (right number of samples) but the sample values are somehow forced to a constant value. I would guess that the waveform being sampled actually looks like that. attachment: smither.vcf___ 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] OT - NASA ebooks was - coupled oscillator book available online
I also read the mishap book and remembered recently seeing this news story. http://news.yahoo.com/air-france-flight-447-crash-didnt-happen-expert-162449729--abc-news-topstories.html?bcmt_s=m#ugccmt-container Seems some lessons are never learned. - Original Message - From: gary li...@lazygranch.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, September 02, 2012 4:02 PM Subject: Re: [time-nuts] coupled oscillator book available online A bit OT, but more NASA ebooks. No need to open your wallet. Well technically, you already did through taxes, but NASA funding is well worth it. http://www.nasa.gov/connect/ebooks/index.html I'm reading the Mishap book. ___ 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] 60 Hz line quirks, anybody recognize this stuff?
Hal The power company switches capacitors in and out of the system to help correct bad power factors and this creates glitches. In addition, they also make frequency corrections from time to time. These kinds of corrections occur all the time and at times the power company will change their distribution of power pattern and where you had minimal glitches, you now can have an increase in numbers. Monitoring the power directly from the power line as opposed to the wall wort should or can look the same. But a direct power analysis should point you in proper direction to figure out your problem. Joe k3wry In a message dated 9/3/2012 5:12:46 P.M. Eastern Daylight Time, smit...@c-c-i.com writes: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-a0.png ___ 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] Rb-Thunderbolt test during a solar eclipse
On 09/03/2012 10:17 PM, iov...@inwind.it wrote: azelio.bori...@screen.it wrote: Data: 03/09/2012 21.53 Remember the man with two clocks: here we are in the same situation. We cannot tell which of the two is being screwed up or maybe both... This is a different case. No matter what each clock does, what matters is the variation of the difference of rates, the variation, not the difference itself. Interesting experiment but I think it would be better if a third clock was involved, for example a Cs reference. A four-atomic-clock test including an Rb, two Cs and an H maser had been done at another eclipse with null result, but the clocks were at the same location. What is new with this test is that it involves a GPSDO and hence a virtual clock elsewhere. We have been touching this subject before. To make me happy, you would have multiple clocks at the site, multiple clocks at another site, common view monitoring of several time sources and other links, fibre and radio. Multiple frequency monitoring of GPS signals for instance, but there is GLONASS also. I want different effects separated, by measurements to support these different effects. Effect on ionospheric delay is one of them. Dual-frequency (or more) measurement is one such tool. So, I still think there is too little data to support anything else then saying we see a difference and my response is OK, let's characterize it properly. 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] 60 Hz line quirks, anybody recognize this stuff?
On 09/03/2012 11:11 PM, Bob Smither wrote: On 09/03/2012 12:00 PM, Graham / KE9H wrote: On 9/1/2012 1:35 AM, Hal Murray wrote: The context is using the 60 Hz line for timing. I'm feeding 60 Hz from a wall wart transformer into a modem control signal that the kernel PPS stuff watches. Mostly, it works as expected, but occasionally, it picks or drops a cycle. In order to understand what was going on, I fed the same signal into the audio input and setup a job to capture the audio. Here is an example of a pick: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a-pick.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Aug-09-a1.png OK, that somewhat makes sense. Something happened several days ago. I used to get picks/drops rarely, say ballpark of 1 a month. Now I'm getting 10 or 20 per day. So I started looking closer. I'm now seeing stuff like this. I've got lots and lots of examples. I added a second PC with different hardware. It sees the same stuff. Does anybody recognize this? http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-b0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-c0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-d0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-01-e0.png Hal: Two ideas: 1.) You could have some process in Windows that is causing aperiodic blocking of the OS's ability to process real time data. Can be many, many causes. Hmmm - but wouldn't that result in missing samples and an abrupt phase jump? The waveforms reported appear phase continuous (right number of samples) but the sample values are somehow forced to a constant value. I would guess that the waveform being sampled actually looks like that. Indeed. What I was stroked by was the repetitive levels and their tendency (except for one case) to strive towards zero with a small slope. For me the source is in the analogue domain rather than digital domain. Phase continuity and restoration of phase rather implies disturbance of the analogue signal, and the fault behaviour looks like some form of intermittent glitch and discharge mechanism. Try to see if you can find some intermittent part of the design. 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] 60 Hz line quirks, anybody recognize this stuff?
Thanks for all the hints and suggestion. The problem seems to be anRS-232 receiver. I haven't seen any glitches like those since I moved the PPS line to a different PC. Has anybody seen anything like that before? Anybody got any ideas on how a receiver can turn into a driver? The typical level shifters have separate receivers and transmitters rather than a tri-state and enable. Maybe I'll take it apart and see what chip it uses. There is a 1K resistor in series with the output of the wall wart so it makes some sense if a current/slew limited (aka weak) driver got turned on. Looks like I got a lemon in that box. (That's the box that has crazy stuff on the audio input like this: http://www.megapathdsl.net/~hmurray/time-nuts/li ne/2012-Aug-07-a0.png) Anyway, I'm back to looking at things that seem reasonable. Sometimes, glitches happen when the line voltage changes. Here are a few graphs: Here is a sample voltage change: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-b0.png These are the beginning and end of the above: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-b1.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-b2.png A pair of glitches that were close together: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-c0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-c1.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-c2.png Isolated glitches: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-b0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-c0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-d0.png -- 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] 60 Hz line quirks, anybody recognize this stuff?
At a quick look, those look plausible line transients. However, the actual plots look badly undersampled during the transients. The plotted results in the transient areas are pretty meaningless, IMO. YMMV, -John Thanks for all the hints and suggestion. The problem seems to be anRS-232 receiver. I haven't seen any glitches like those since I moved the PPS line to a different PC. Has anybody seen anything like that before? Anybody got any ideas on how a receiver can turn into a driver? The typical level shifters have separate receivers and transmitters rather than a tri-state and enable. Maybe I'll take it apart and see what chip it uses. There is a 1K resistor in series with the output of the wall wart so it makes some sense if a current/slew limited (aka weak) driver got turned on. Looks like I got a lemon in that box. (That's the box that has crazy stuff on the audio input like this: http://www.megapathdsl.net/~hmurray/time-nuts/li ne/2012-Aug-07-a0.png) Anyway, I'm back to looking at things that seem reasonable. Sometimes, glitches happen when the line voltage changes. Here are a few graphs: Here is a sample voltage change: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-b0.png These are the beginning and end of the above: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-b1.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-b2.png A pair of glitches that were close together: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-c0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-c1.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-c2.png Isolated glitches: http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-02-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-a0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-b0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-c0.png http://www.megapathdsl.net/~hmurray/time-nuts/line/2012-Sep-03-d0.png -- 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] 60 Hz line quirks, anybody recognize this stuff?
j...@quikus.com said: At a quick look, those look plausible line transients. However, the actual plots look badly undersampled during the transients. The plotted results in the transient areas are pretty meaningless, IMO. I agree. I'm sampling at 16 bits, 8K samples per second, mono. I tried 8 bits. It wasn't enough. I picked 8K out of the air. It's a compromise between getting enough data and chewing up disk space. It's good enough for 60 Hz and would probably be good enough to show me the next layer of glitches. 2*8K*86400 is 1.38 gigabytes per day. I've got enough disk space so I can run that for a week or two without having to do serious housecleaning. -- 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.
