From imp at bsdimp.com Thu Jan 1 00:02:05 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed, 31 Dec 2008 17:02:05 -0700 (MST) Subject: [time-nuts] Early leap second data In-Reply-To: <041b01c96b97$428c6260$0a01a8c0@ATHLONXP1700> References: <495B8633.3030701@febo.com> <8CB397776CBA6AC-494-179@WEBMAIL-MA02.sysops.aol.com> <041b01c96b97$428c6260$0a01a8c0@ATHLONXP1700> Message-ID: <20081231.170205.-1325211413.imp@bsdimp.com> My server, which is slaved to NIST's stratum 1 server, did the leap correctly: Wed Dec 31 16:59:45 MST 2008 Wed Dec 31 16:59:46 MST 2008 Wed Dec 31 16:59:47 MST 2008 Wed Dec 31 16:59:48 MST 2008 Wed Dec 31 16:59:49 MST 2008 Wed Dec 31 16:59:50 MST 2008 Wed Dec 31 16:59:51 MST 2008 Wed Dec 31 16:59:52 MST 2008 Wed Dec 31 16:59:53 MST 2008 Wed Dec 31 16:59:54 MST 2008 Wed Dec 31 16:59:55 MST 2008 Wed Dec 31 16:59:56 MST 2008 Wed Dec 31 16:59:57 MST 2008 Wed Dec 31 16:59:58 MST 2008 Wed Dec 31 16:59:59 MST 2008 Wed Dec 31 16:59:59 MST 2008 Wed Dec 31 17:00:00 MST 2008 Wed Dec 31 17:00:01 MST 2008 Wed Dec 31 17:00:02 MST 2008 Wed Dec 31 17:00:03 MST 2008 Wed Dec 31 17:00:04 MST 2008 Warner From dmoisan at davidmoisan.org Thu Jan 1 00:03:22 2009 From: dmoisan at davidmoisan.org (David Moisan) Date: Wed, 31 Dec 2008 19:03:22 -0500 Subject: [time-nuts] Fw: How to schedule a leap second on 5071A? In-Reply-To: <95B4A4FBA9E240F3808BB388FDE2BFF6@pc52> References: <495BF6D3.6080103@rubidium.dyndns.org> <95B4A4FBA9E240F3808BB388FDE2BFF6@pc52> Message-ID: Yes it did. But then it ran backwards until I refreshed it! -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Tom Van Baak Sent: Wednesday, December 31, 2008 6:44 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Fw: How to schedule a leap second on 5071A? > Does your "web nixie clock" display the leap second properly? Last I remember it did. I guess we'll find out in a few minutes... http://www.leapsecond.com/java/nixie.htm /tvb From rdarlington at gmail.com Thu Jan 1 00:04:32 2009 From: rdarlington at gmail.com (Robert Darlington) Date: Wed, 31 Dec 2008 17:04:32 -0700 Subject: [time-nuts] FreeBSD 7 ntp server Message-ID: Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my system ticked :59 twice. Here's the output of my not so very scientific logs (up arrow, enter, over and over): ntp_gettime() returns code 1 (INS) time cd0685ff.18496674 Wed, Dec 31 2008 16:59:59.094, (.094870766), maximum error 4762 us, estimated error 15 us, TAI offset 33 ntp_adjtime() returns code 1 (INS) modes 0x0 (), offset -0.278 us, frequency -0.051 ppm, interval 1 s, maximum error 4762 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, time# ntptime ntp_gettime() returns code 1 (INS) time cd0685ff.65479d28 Wed, Dec 31 2008 16:59:59.395, (.395624242), maximum error 4762 us, estimated error 15 us, TAI offset 33 ntp_adjtime() returns code 1 (INS) modes 0x0 (), offset -0.278 us, frequency -0.051 ppm, interval 1 s, maximum error 4762 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, time# ntptime ntp_gettime() returns code 1 (INS) time cd0685ff.b73eee0c Wed, Dec 31 2008 16:59:59.715, (.715804039), maximum error 4762 us, estimated error 15 us, TAI offset 33 ntp_adjtime() returns code 1 (INS) modes 0x0 (), offset -0.278 us, frequency -0.051 ppm, interval 1 s, maximum error 4762 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, time# ntptime ntp_gettime() returns code 3 (OOP) time cd0685ff.03fb7a60 Wed, Dec 31 2008 16:59:59.015, (.015556955), maximum error 5262 us, estimated error 15 us, TAI offset 34 ntp_adjtime() returns code 3 (OOP) modes 0x0 (), offset -0.277 us, frequency -0.051 ppm, interval 1 s, maximum error 5262 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, time# ntptime ntp_gettime() returns code 3 (OOP) time cd0685ff.50d0bb50 Wed, Dec 31 2008 16:59:59.315, (.315685712), maximum error 5262 us, estimated error 15 us, TAI offset 34 ntp_adjtime() returns code 3 (OOP) modes 0x0 (), offset -0.277 us, frequency -0.051 ppm, interval 1 s, maximum error 5262 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, time# ntptime ntp_gettime() returns code 3 (OOP) time cd0685ff.9d5dc3c8 Wed, Dec 31 2008 16:59:59.614, (.614712868), maximum error 5262 us, estimated error 15 us, TAI offset 34 ntp_adjtime() returns code 3 (OOP) modes 0x0 (), offset -0.277 us, frequency -0.051 ppm, interval 1 s, maximum error 5262 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, time# ntptime ntp_gettime() returns code 3 (OOP) time cd0685ff.ef985218 Wed, Dec 31 2008 16:59:59.935, (.935918664), maximum error 5262 us, estimated error 15 us, TAI offset 34 ntp_adjtime() returns code 3 (OOP) modes 0x0 (), offset -0.277 us, frequency -0.051 ppm, interval 1 s, maximum error 5262 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, time# ntptime ntp_gettime() returns code 4 (WAIT) time cd068600.4e4a6a6c Wed, Dec 31 2008 17:00:00.305, (.305823220), maximum error 5762 us, estimated error 15 us, TAI offset 34 ntp_adjtime() returns code 4 (WAIT) modes 0x0 (), offset -0.276 us, frequency -0.051 ppm, interval 1 s, maximum error 5762 us, estimated error 15 us, status 0x2011 (PLL,INS,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, From holrum at hotmail.com Thu Jan 1 00:06:09 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 00:06:09 +0000 Subject: [time-nuts] Thunderbolt Leapsecond missing In-Reply-To: References: Message-ID: My Thunderbolt showed no leap second (set to display GPS time) ... went from 23:59:59 to 00:00:00. 15 seconds after the hour the "Leapsecond Pending" indicator went off. _________________________________________________________________ Send e-mail anywhere. No map, no compass. http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008 From marc at msys.ch Thu Jan 1 00:06:21 2009 From: marc at msys.ch (Marc Balmer) Date: Thu, 1 Jan 2009 01:06:21 +0100 Subject: [time-nuts] Early leap second data In-Reply-To: <20081231.170205.-1325211413.imp@bsdimp.com> References: <495B8633.3030701@febo.com> <8CB397776CBA6AC-494-179@WEBMAIL-MA02.sysops.aol.com> <041b01c96b97$428c6260$0a01a8c0@ATHLONXP1700> <20081231.170205.-1325211413.imp@bsdimp.com> Message-ID: <20090101000621.GD28788@mail.msys.ch> * M. Warner Losh wrote: > My server, which is slaved to NIST's stratum 1 server, did the leap > correctly: It did not. There can not be two equal times. > > Wed Dec 31 16:59:45 MST 2008 > Wed Dec 31 16:59:46 MST 2008 > Wed Dec 31 16:59:47 MST 2008 > Wed Dec 31 16:59:48 MST 2008 > Wed Dec 31 16:59:49 MST 2008 > Wed Dec 31 16:59:50 MST 2008 > Wed Dec 31 16:59:51 MST 2008 > Wed Dec 31 16:59:52 MST 2008 > Wed Dec 31 16:59:53 MST 2008 > Wed Dec 31 16:59:54 MST 2008 > Wed Dec 31 16:59:55 MST 2008 > Wed Dec 31 16:59:56 MST 2008 > Wed Dec 31 16:59:57 MST 2008 > Wed Dec 31 16:59:58 MST 2008 > Wed Dec 31 16:59:59 MST 2008 > Wed Dec 31 16:59:59 MST 2008 this is wrong. > Wed Dec 31 17:00:00 MST 2008 > Wed Dec 31 17:00:01 MST 2008 > Wed Dec 31 17:00:02 MST 2008 > Wed Dec 31 17:00:03 MST 2008 > Wed Dec 31 17:00:04 MST 2008 > > Warner > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. -- Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland http://www.msys.ch/ http://www.vnode.ch/ "In God we trust, in C we code." From ralph at ralphsmith.org Thu Jan 1 00:06:51 2009 From: ralph at ralphsmith.org (Ralph Smith) Date: Wed, 31 Dec 2008 19:06:51 -0500 Subject: [time-nuts] Garmin GPS18 Leap Second Observation Message-ID: <1F09B7C8-449E-4F83-A44E-1AFEB366F54B@ralphsmith.org> I was watching the leap second on the NMEA output of my Garmin GPS18, displaying the RNC and GGA sentences. The GGA sentences repeated 235959, but the RMC sentence repeated 000000. $GPRMC,235958,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7D $GPGGA,235958,3855.4967,N,07723.0144,W,1,07,1.9,119.9,M,-33.9,M,,*7C $GPRMC,235959,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7C $GPGGA,235959,3855.4967,N,07723.0144,W,1,07,1.9,120.1,M,-33.9,M,,*7F $GPRMC,000000,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7D $GPGGA,235959,3855.4967,N,07723.0144,W,1,07,1.9,120.2,M,-33.9,M,,*7C $GPRMC,000000,A,3855.4967,N,07723.0144,W,000.0,013.3,010109,010.5,W*7D $GPGGA,000000,3855.4967,N,07723.0144,W,1,07,1.9,120.3,M,-33.9,M,,*7C $GPRMC,000001,A,3855.4967,N,07723.0144,W,000.0,013.3,010109,010.5,W*7C $GPGGA,000001,3855.4967,N,07723.0144,W,1,07,1.9,120.4,M,-33.9,M,,*7A Odd. Ralph From tvb at LeapSecond.com Thu Jan 1 00:12:52 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 31 Dec 2008 16:12:52 -0800 Subject: [time-nuts] Fw: How to schedule a leap second on 5071A? References: <495BF6D3.6080103@rubidium.dyndns.org> <95B4A4FBA9E240F3808BB388FDE2BFF6@pc52> Message-ID: <3839F849FB81414EAADC90C2EED74A5E@pc52> >> Does your "web nixie clock" display the leap second properly? > > Last I remember it did. I guess we'll find out in a few minutes... > > http://www.leapsecond.com/java/nixie.htm > > /tvb Yes, see attached iPod screenshot. But then it started counting down; a JavaScript bug I now remember that I need to fix in the next year or two. It's tricky to debug a event that only happens a few times a decade... Attached also is www.time.gov doing the right thing. /tvb -------------- next part -------------- A non-text attachment was scrubbed... Name: 2008-time-gov-leap-second.gif Type: image/gif Size: 33461 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20081231/e15186f9/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: 2008-ipod-nixie-leapsecond.jpg Type: image/jpeg Size: 56475 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20081231/e15186f9/attachment-0001.jpg From dave.g0dja at tiscali.co.uk Thu Jan 1 00:14:15 2009 From: dave.g0dja at tiscali.co.uk (Dave Ackrill) Date: Thu, 01 Jan 2009 00:14:15 +0000 Subject: [time-nuts] Fw: How to schedule a leap second on 5071A? In-Reply-To: <95B4A4FBA9E240F3808BB388FDE2BFF6@pc52> References: <495BF6D3.6080103@rubidium.dyndns.org> <95B4A4FBA9E240F3808BB388FDE2BFF6@pc52> Message-ID: <495C0AD7.2070502@tiscali.co.uk> Tom Van Baak wrote: > Last I remember it did. I guess we'll find out in a few minutes... > > http://www.leapsecond.com/java/nixie.htm > > /tvb > It seemed to hang when the count got down to zero here, and now keeps saying I have to refresh the page every so often. Dave From clintjeffrey at optusnet.com.au Thu Jan 1 00:11:55 2009 From: clintjeffrey at optusnet.com.au (Clint Jeffrey - VK3CSJ) Date: Thu, 1 Jan 2009 11:11:55 +1100 Subject: [time-nuts] Capturing CHU frequency switchover In-Reply-To: References: <495B187C.1020503@rubidium.dyndns.org> Message-ID: Hi Folks With less than 10 minutes to spare, after just reading this post, I went out to the shack to see if anything could heard but unfortunately nothing was detectable here on 7335 or 7850KHz...in fact I don't think I've ever heard CHU in Melbourne, not to say it wouldn't propagate this far, I'll do some listens on the new 7850KHz frequency over the next few days and see if I can hear it.... Happy New Year to all... Clint - VK3CSJ Melbourne. Aust. ----- Original Message ----- From: "Neville Michie" To: "Discussion of precise time and frequency measurement" Sent: Wednesday, December 31, 2008 11:39 PM Subject: Re: [time-nuts] Capturing CHU frequency switchover > Over here in Australia there are no time services to see/hear the > leap second. > WWV is available but only during the night. > The leap second will be here about 10AM so I will not be able to hear > WWV. > If WWV does something notable I would love it if some one could make > a sound clip of it. > > Have a precise, accurate, happy and very prosperous New Year, > Neville Michie > > > On 31/12/2008, at 6:00 PM, Magnus Danielson wrote: > >> Hi! >> >> I don't have the equipment for it, but I am sure that a ham near would >> be able to pull this off. Here the deal: >> >> "After seventy years of broadcasting Canada's official time, NRC's >> shortwave station CHU will move the transmission frequency for the >> 7335 >> KHz transmitter to 7850 KHz. The change will occur on 01 January >> 2009 at >> 00:00 UTC." >> >> Now, as this happends at the same time as the leap second, it would be >> kind of cool recording both the old and new CHU transmissions on left >> and right channel of a stereo-pair. That should capture leap-second >> and >> frequency switchover. >> >> Just a thought for the hams out there in North America. >> >> Cheers, >> Magnus >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ >> time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From Arnold.Tibus at gmx.de Thu Jan 1 00:16:48 2009 From: Arnold.Tibus at gmx.de (Arnold Tibus) Date: Thu, 01 Jan 2009 01:16:48 +0100 Subject: [time-nuts] Early leap second data Message-ID: Hello the group, happy New Year to everybody! (In Cental Europe we are already in 2009 since 23h UTC!) My Thunderbolt did show correctly the 60 sec, then showing 00. (Unfortunately I pressed PRN key twice - exchanging the 60 with 00... -((, so no picture of it available, but I swear. ) I watched very comfortable via WLAN, LAN and COM-server, very practical indeed - sitting with a (or two) glass of the good Spanish Rioja Vi~na Alarde 1999 and the Laptop in front, prosit ! Greetings Arnold, DK2WT From chris.kuethe at gmail.com Thu Jan 1 00:18:31 2009 From: chris.kuethe at gmail.com (Chris Kuethe) Date: Wed, 31 Dec 2008 16:18:31 -0800 Subject: [time-nuts] Garmin GPS18 Leap Second Observation In-Reply-To: <1F09B7C8-449E-4F83-A44E-1AFEB366F54B@ralphsmith.org> References: <1F09B7C8-449E-4F83-A44E-1AFEB366F54B@ralphsmith.org> Message-ID: <91981b3e0812311618u3b4ac854j5f57a98b883f30d2@mail.gmail.com> And my gps18 seems to have got very confused - it was tracking satellites but was not generating solutions. 5 other receivers (thunderbolt, sirfstar2, itrax03, antaris, antaris4t) in the same area were working OK. After resetting the gps18, it was tracking the same satellites and all was shiny and happy again. CK On Wed, Dec 31, 2008 at 4:06 PM, Ralph Smith wrote: > I was watching the leap second on the NMEA output of my Garmin GPS18, > displaying the RNC and GGA sentences. The GGA sentences repeated > 235959, but the RMC sentence repeated 000000. > > $GPRMC,235958,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7D > $GPGGA,235958,3855.4967,N,07723.0144,W,1,07,1.9,119.9,M,-33.9,M,,*7C > $GPRMC,235959,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7C > $GPGGA,235959,3855.4967,N,07723.0144,W,1,07,1.9,120.1,M,-33.9,M,,*7F > $GPRMC,000000,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7D > $GPGGA,235959,3855.4967,N,07723.0144,W,1,07,1.9,120.2,M,-33.9,M,,*7C > $GPRMC,000000,A,3855.4967,N,07723.0144,W,000.0,013.3,010109,010.5,W*7D > $GPGGA,000000,3855.4967,N,07723.0144,W,1,07,1.9,120.3,M,-33.9,M,,*7C > $GPRMC,000001,A,3855.4967,N,07723.0144,W,000.0,013.3,010109,010.5,W*7C > $GPGGA,000001,3855.4967,N,07723.0144,W,1,07,1.9,120.4,M,-33.9,M,,*7A > > Odd. > > Ralph > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- GDB has a 'break' feature; why doesn't it have 'fix' too? From smace at intt.net Thu Jan 1 00:23:27 2009 From: smace at intt.net (Scott Mace) Date: Wed, 31 Dec 2008 18:23:27 -0600 Subject: [time-nuts] Early leap second data In-Reply-To: References: Message-ID: <495C0CFF.3010406@intt.net> Both my Fury (time-a) and z3801a (time-b) handled it correctly remote refid st t when poll reach delay offset jitter ============================================================================== clepsydra.dec.c .GPS. 1 u 248 1024 377 48.794 1000.24 1000.04 +time-a.intt.org .PPS. 1 u 195 1024 377 9.008 0.161 0.009 *time-b.intt.org .PPS. 1 u 298 1024 377 2.681 0.790 0.697 *tick.uh.edu .GPS. 1 u 869 1024 377 1.268 -2.133 0.033 tock.usno.navy. 85.83.78.79 2 u 699 1024 377 54.801 1003.98 999.849 +time.nist.gov .ACTS. 1 u 326 1024 263 47.122 2.865 0.391 Scott From phk at phk.freebsd.dk Thu Jan 1 00:24:53 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 01 Jan 2009 00:24:53 +0000 Subject: [time-nuts] Early leap second data In-Reply-To: Your message of "Thu, 01 Jan 2009 01:06:21 +0100." <20090101000621.GD28788@mail.msys.ch> Message-ID: <51768.1230769493@critter.freebsd.dk> In message <20090101000621.GD28788 at mail.msys.ch>, Marc Balmer writes: >* M. Warner Losh wrote: >> My server, which is slaved to NIST's stratum 1 server, did the leap >> correctly: > >It did not. There can not be two equal times. Send your complaint to The Open Group, this is how POSIX mandates it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From tvb at LeapSecond.com Thu Jan 1 00:26:27 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 31 Dec 2008 16:26:27 -0800 Subject: [time-nuts] Garmin GPS18 Leap Second Observation References: <1F09B7C8-449E-4F83-A44E-1AFEB366F54B@ralphsmith.org> Message-ID: Yes, I think if you dig out the Garmin documentation they say that's the way they chose to handle leap seconds. It may be not be "officially" correct; but it's one of several work-around solutions. If I had to guess, in the NMEA world, omitting one or repeating a time stamp twice is not as bad as having a time stamp showing a 61st second. If someone from Garmin is on the list, please tell us the real reason. /tvb ----- Original Message ----- From: "Ralph Smith" To: "Discussion of precise time and frequency measurement" Sent: Wednesday, December 31, 2008 4:06 PM Subject: [time-nuts] Garmin GPS18 Leap Second Observation >I was watching the leap second on the NMEA output of my Garmin GPS18, > displaying the RNC and GGA sentences. The GGA sentences repeated > 235959, but the RMC sentence repeated 000000. > > $GPRMC,235958,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7D > $GPGGA,235958,3855.4967,N,07723.0144,W,1,07,1.9,119.9,M,-33.9,M,,*7C > $GPRMC,235959,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7C > $GPGGA,235959,3855.4967,N,07723.0144,W,1,07,1.9,120.1,M,-33.9,M,,*7F > $GPRMC,000000,A,3855.4967,N,07723.0144,W,000.0,013.3,311208,010.5,W*7D > $GPGGA,235959,3855.4967,N,07723.0144,W,1,07,1.9,120.2,M,-33.9,M,,*7C > $GPRMC,000000,A,3855.4967,N,07723.0144,W,000.0,013.3,010109,010.5,W*7D > $GPGGA,000000,3855.4967,N,07723.0144,W,1,07,1.9,120.3,M,-33.9,M,,*7C > $GPRMC,000001,A,3855.4967,N,07723.0144,W,000.0,013.3,010109,010.5,W*7C > $GPGGA,000001,3855.4967,N,07723.0144,W,1,07,1.9,120.4,M,-33.9,M,,*7A > > Odd. > > Ralph > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From newell at cei.net Thu Jan 1 00:30:08 2009 From: newell at cei.net (Scott Newell) Date: Wed, 31 Dec 2008 18:30:08 -0600 Subject: [time-nuts] Thunderbolt Leapsecond missing In-Reply-To: References: Message-ID: <200901010030.n010UF5t023501@host22.the-web-host.com> At 06:06 PM 12/31/2008, Mark Sims wrote: >My Thunderbolt showed no leap second (set to display GPS time) >... went from 23:59:59 to 00:00:00. 15 seconds after the hour the >"Leapsecond Pending" indicator went off. I have a screenshot of TBoltMon showing "23:59:60", but I'm monitoring UTC time. UTC offset confusion, perhaps? -- newell N5TNL From hmurray at megapathdsl.net Thu Jan 1 00:35:02 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 31 Dec 2008 16:35:02 -0800 Subject: [time-nuts] Garmin GPS18 Leap Second Observation In-Reply-To: Message from "Chris Kuethe" of "Wed, 31 Dec 2008 16:18:31 PST." <91981b3e0812311618u3b4ac854j5f57a98b883f30d2@mail.gmail.com> Message-ID: <20090101003503.24A9CBCD7@ip-64-139-1-69.sjc.megapath.net> > And my gps18 seems to have got very confused - it was tracking > satellites but was not generating solutions. That happens to me occasionally. I've got mine inside so reception is far from good. That gives lots of exercise to the section of code that handles satellites coming and going. I assume it hasn't been debugged yet. I also see occasional times where it reports valid data but is off by a second. That recovers. -- These are my opinions, not necessarily my employer's. I hate spam. From time-nuts at adobe-labs.com Thu Jan 1 00:35:50 2009 From: time-nuts at adobe-labs.com (Brent Gordon) Date: Wed, 31 Dec 2008 17:35:50 -0700 Subject: [time-nuts] Trimble Copernicus Leap Second Message-ID: <495C0FE6.1080806@adobe-labs.com> The start of the $GPZDA is specified to match the PPS output. Interesting that the others are one second slow. Any missing sentences were not sent. $GPZDA,235959.00,31,12,2008,,*6C $GPGLL,3507.53830,N,10631.28409,W,235958.00,A,A*75 $GPZDA,000000.00,01,01,2009,,*6D $GPGGA,235960.00,3507.53830,N,10631.28409,W,1,11,0.98,01719,M,-022,M,,*59 $GPGLL,3507.53830,N,10631.28409,W,235960.00,A,A*7E $GPRMC,235960.00,A,3507.53830,N,10631.28409,W,000.0,000.0,311208,10.6,E,A*1C $GPZDA,000001.00,01,01,2009,,*6C $GPGGA,000000.00,3507.53830,N,10631.28409,W,1,11,0.98,01719,M,-022,M,,*52 $GPGLL,3507.53830,N,10631.28409,W,000000.00,A,A*75 $GPZDA,000003.00,01,01,2009,,*6E $GPGGA,000002.00,3507.53830,N,10631.28409,W,1,11,0.98,01719,M,-022,M,,*50 $GPGLL,3507.53830,N,10631.28409,W,000002.00,A,A*77 $GPRMC,000002.00,A,3507.53830,N,10631.28409,W,000.0,000.0,010109,10.6,E,A*15 I was also listening to WWV at 5 MHz, but I missed the leap second by two seconds. I haven't listened to WWV in a long time; instead of the normal ticking sound, each tick was tripled--sort of a ti-tick tock sound. I know I wasn't hearing WWVH (no female voice announcements). Was I hearing some other time station or is that how WWV sounds now? Brent From jgd at johngsbbq.com Thu Jan 1 00:35:45 2009 From: jgd at johngsbbq.com (Neon John) Date: Wed, 31 Dec 2008 19:35:45 -0500 Subject: [time-nuts] Fw: How to schedule a leap second on 5071A? In-Reply-To: <3839F849FB81414EAADC90C2EED74A5E@pc52> References: <495BF6D3.6080103@rubidium.dyndns.org> <95B4A4FBA9E240F3808BB388FDE2BFF6@pc52> <3839F849FB81414EAADC90C2EED74A5E@pc52> Message-ID: On Wed, 31 Dec 2008 16:12:52 -0800, "Tom Van Baak" wrote: >>> Does your "web nixie clock" display the leap second properly? >> >> Last I remember it did. I guess we'll find out in a few minutes... >> >> http://www.leapsecond.com/java/nixie.htm >> >> /tvb > >Yes, see attached iPod screenshot. But then it started >counting down; a JavaScript bug I now remember that I >need to fix in the next year or two. It's tricky to debug a >event that only happens a few times a decade... > >Attached also is www.time.gov doing the right thing. Tom, Are you going to put those photos on your website? If not, I'd like to put them on mine. I've been explaining leap seconds to some folks and would like to show 'em what it looks like. FWIW, my Magellan Meridian Platinum correctly saw the event but over a minute off. See attached WTF? I knew that the displayed time on a GPS wasn't all that accurate but over a minute? I'm so embarrased. Do I have to turn in my Time Nut badge? -- John De Armond See my website for my current email address http://www.neon-john.com http://www.johndearmond.com <-- best little blog on the net! Tellico Plains, Occupied TN Ignorance more frequently begets confidence than does knowledge. -Darwin -------------- next part -------------- A non-text attachment was scrubbed... Name: GPS_vs_WWV.jpg Type: image/jpeg Size: 49324 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20081231/a6242f62/attachment-0001.jpg From newell at cei.net Thu Jan 1 00:37:43 2009 From: newell at cei.net (Scott Newell) Date: Wed, 31 Dec 2008 18:37:43 -0600 Subject: [time-nuts] Radio clock fails to leap Message-ID: <200901010037.n010bxUh024786@host22.the-web-host.com> My low-end Radio Shack 'atomic clock' did not handle the leap second. I started this evening with a good plan--used a digital camera capable of video (and audio) recording to record the display of the radio clock vs. a hand synchronized 59309A clock (running from internal oscillator), complete with WWV audio in the background. I was hoping to see 59 seconds twice, or 60. I was also hoping to see that the two displays out of sync after the leap. No such luck--the video and audio came out great, but the two displays stay in sync with each other. They're obviously one second off after the leap, so it wasn't a complete waste. -- newell From danrae at verizon.net Thu Jan 1 00:44:21 2009 From: danrae at verizon.net (Dan Rae) Date: Wed, 31 Dec 2008 16:44:21 -0800 Subject: [time-nuts] Loran TOCs this year Message-ID: <495C11E5.8030205@verizon.net> I have reset my Austron 2100 to the new UTC time, but the TOCs given by the USNO seem to be off. Should I maybe assume they have not allowed for the extra second and subtract one second from the posted times? Can the US Navy have got it wrong? Tbolt got it right... Dan From danrae at verizon.net Thu Jan 1 00:47:18 2009 From: danrae at verizon.net (Dan Rae) Date: Wed, 31 Dec 2008 16:47:18 -0800 Subject: [time-nuts] Radio clock fails to leap In-Reply-To: <200901010037.n010bxUh024786@host22.the-web-host.com> References: <200901010037.n010bxUh024786@host22.the-web-host.com> Message-ID: <495C1296.8080901@verizon.net> Scott Newell wrote: > My low-end Radio Shack 'atomic clock' did not handle the leap second. > It will, just give it time. (Sorry!) Those normally sync up once a day around 3AM local, so will catch the daylight savings hour change but not the leap seconds as they happen... dr From paul at greenrover.demon.co.uk Thu Jan 1 00:47:58 2009 From: paul at greenrover.demon.co.uk (paul at greenrover.demon.co.uk) Date: Thu, 01 Jan 2009 00:47:58 +0000 Subject: [time-nuts] Thunderbolt Leapsecond missing In-Reply-To: References: Message-ID: <495C12BE.2000701@greenrover.demon.co.uk> Mark Sims wrote: > My Thunderbolt showed no leap second (set to display GPS time) ... went from 23:59:59 to 00:00:00. 15 seconds after the hour the "Leapsecond Pending" indicator went off. > _________________________________________________________________ > Send e-mail anywhere. No map, no compass. > http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008 > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > exactly same here, maybe a bit frightened to use the term "exactly" here :-) -- 73 de Paul GW8IZR IO73TI http://www.gw8izr.com From chris.kuethe at gmail.com Thu Jan 1 00:48:56 2009 From: chris.kuethe at gmail.com (Chris Kuethe) Date: Wed, 31 Dec 2008 16:48:56 -0800 Subject: [time-nuts] Radio clock fails to leap In-Reply-To: <200901010037.n010bxUh024786@host22.the-web-host.com> References: <200901010037.n010bxUh024786@host22.the-web-host.com> Message-ID: <91981b3e0812311648r17a1aeebva5f46f367d394b01@mail.gmail.com> On Wed, Dec 31, 2008 at 4:37 PM, Scott Newell wrote: > My low-end Radio Shack 'atomic clock' did not handle the leap second. Not surprising. > I started this evening with a good plan--used a digital camera > capable of video (and audio) recording to record the display of the > radio clock vs. a hand synchronized 59309A clock (running from > internal oscillator), complete with WWV audio in the background. I > was hoping to see 59 seconds twice, or 60. I was also hoping to see > that the two displays out of sync after the leap. I had much the same plan with my "atomic" clock, but I didn't bother trying to film since it seemed to be moot. Since my clock only tries to sync between 2am and 5am, i figured it wouldn't see the leap second until tonight. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? From danrae at verizon.net Thu Jan 1 00:50:11 2009 From: danrae at verizon.net (Dan Rae) Date: Wed, 31 Dec 2008 16:50:11 -0800 Subject: [time-nuts] Loran TOCs this year In-Reply-To: <495C11E5.8030205@verizon.net> References: <495C11E5.8030205@verizon.net> Message-ID: <495C1343.1060408@verizon.net> Dan Rae wrote: > I have reset my Austron 2100 to the new UTC time, but the TOCs given by > the USNO seem to be off. Should I maybe assume they have not allowed for > the extra second and subtract one second from the posted times? > Can the US Navy have got it wrong? Tbolt got it right... > Answering my own post, yes, that did it. The Navy got it wrong... dr From newell at cei.net Thu Jan 1 00:53:46 2009 From: newell at cei.net (Scott Newell) Date: Wed, 31 Dec 2008 18:53:46 -0600 Subject: [time-nuts] TBolt leap log Message-ID: <200901010053.n010rsRq027608@host22.the-web-host.com> Here's a snip of my Thunderbolt leap second log. 345614 is the leap second. Looks like the minor alarm 128 went away. I'm pretty sure bit 7 (decimal 128) is the leap second pending bit, so that makes sense... 345610 -1.8 0.04 0.7880974 36.42 0 0 0 128 7 0 345611 -1.8 0.03 0.7880974 36.42 0 0 0 128 7 0 345612 -1.8 -0.03 0.7880974 36.42 0 0 0 128 7 0 345613 -1.9 0.05 0.7881069 36.42 0 0 0 128 7 0 345614 -1.9 -0.01 0.7881069 36.42 0 0 0 128 7 0 345615 -2.1 0.00 0.7881069 36.42 0 0 0 0 7 0 345616 -2.1 -0.02 0.7881069 36.42 0 0 0 0 7 0 345617 -2.1 -0.01 0.7881069 36.42 0 0 0 0 7 0 23:59:60 screenshot attached. -- newell N5TNL -------------- next part -------------- A non-text attachment was scrubbed... Name: thunderbolt_utc_leap.png Type: image/png Size: 27708 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20081231/efb1d176/attachment-0001.png From tvb at LeapSecond.com Thu Jan 1 00:54:42 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 31 Dec 2008 16:54:42 -0800 Subject: [time-nuts] Fw: How to schedule a leap second on 5071A? References: <495BF6D3.6080103@rubidium.dyndns.org><95B4A4FBA9E240F3808BB388FDE2BFF6@pc52><3839F849FB81414EAADC90C2EED74A5E@pc52> Message-ID: <9591C7609A434F7098CD2632557E20E5@pc52> > Tom, > > Are you going to put those photos on your website? If not, I'd like to put > them on mine. I've been explaining leap seconds to some folks and would like > to show 'em what it looks like. http://www.leapsecond.com/notes/2008-time-gov-leap-second.gif http://www.leapsecond.com/notes/2008-ipod-nixie-leapsecond.jpg > FWIW, my Magellan Meridian Platinum correctly saw the event but over a minute > off. See attached WTF? I knew that the displayed time on a GPS wasn't all > that accurate but over a minute? I'm so embarrased. Do I have to turn in my > Time Nut badge? We'll forgive you this time. ;-) > -- > John De Armond > See my website for my current email address > http://www.neon-john.com > http://www.johndearmond.com <-- best little blog on the net! > Tellico Plains, Occupied TN > Ignorance more frequently begets confidence than does knowledge. -Darwin From wa1zms at att.net Thu Jan 1 00:57:08 2009 From: wa1zms at att.net (wa1zms at att.net) Date: Wed, 31 Dec 2008 19:57:08 -0500 Subject: [time-nuts] Z3801A & LED display... In-Reply-To: <495C11E5.8030205@verizon.net> Message-ID: FWIW... I have one of my Z3801A running with an external LED display that's based on one of the Dave Robinson, G4FRE PIC controllers. His design reads the raw binary output from the internal GPS RX. A mini-disc cam-corder was aimed at the display and caught the leapsecond. ie: 23:59:58 23:59:59 23:59:60 00:00:00 00:00:01 I'll try and snag a few seconds of video from the DVD around the event if anybody is interested. Had WWV on in the background but was not mic'ed very well so sound is low. -Brian, WA1ZMS From tvb at LeapSecond.com Thu Jan 1 00:56:40 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 31 Dec 2008 16:56:40 -0800 Subject: [time-nuts] Loran TOCs this year References: <495C11E5.8030205@verizon.net> Message-ID: <6A72939BA85746B89BAAF6BE4C205708@pc52> >I have reset my Austron 2100 to the new UTC time, but the TOCs given by > the USNO seem to be off. Should I maybe assume they have not allowed for > the extra second and subtract one second from the posted times? > Can the US Navy have got it wrong? Tbolt got it right... How do your TOC's compare with the one here: http://www.leapsecond.com/java/gpsclock.htm /tvb From rdarlington at gmail.com Thu Jan 1 00:58:29 2009 From: rdarlington at gmail.com (Robert Darlington) Date: Wed, 31 Dec 2008 17:58:29 -0700 Subject: [time-nuts] Radio clock fails to leap In-Reply-To: <200901010037.n010bxUh024786@host22.the-web-host.com> References: <200901010037.n010bxUh024786@host22.the-web-host.com> Message-ID: I recorded two consumer radio clocks about 30 seconds before out to 20 minutes after the leap second event. One is digital, the other with an analog movement. After 57 minutes still no time correction. We'll see in the morning. On Wed, Dec 31, 2008 at 5:37 PM, Scott Newell wrote: > My low-end Radio Shack 'atomic clock' did not handle the leap second. > > I started this evening with a good plan--used a digital camera > capable of video (and audio) recording to record the display of the > radio clock vs. a hand synchronized 59309A clock (running from > internal oscillator), complete with WWV audio in the background. I > was hoping to see 59 seconds twice, or 60. I was also hoping to see > that the two displays out of sync after the leap. > > No such luck--the video and audio came out great, but the two > displays stay in sync with each other. They're obviously one second > off after the leap, so it wasn't a complete waste. > > > -- > newell > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From imp at bsdimp.com Thu Jan 1 00:59:02 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed, 31 Dec 2008 17:59:02 -0700 (MST) Subject: [time-nuts] Early leap second data In-Reply-To: <20090101000621.GD28788@mail.msys.ch> References: <041b01c96b97$428c6260$0a01a8c0@ATHLONXP1700> <20081231.170205.-1325211413.imp@bsdimp.com> <20090101000621.GD28788@mail.msys.ch> Message-ID: <20081231.175902.1266245959.imp@bsdimp.com> In message: <20090101000621.GD28788 at mail.msys.ch> Marc Balmer writes: : * M. Warner Losh wrote: : > My server, which is slaved to NIST's stratum 1 server, did the leap : > correctly: : : It did not. There can not be two equal times. Yes, it was correct. : > Wed Dec 31 16:59:45 MST 2008 : > Wed Dec 31 16:59:46 MST 2008 : > Wed Dec 31 16:59:47 MST 2008 : > Wed Dec 31 16:59:48 MST 2008 : > Wed Dec 31 16:59:49 MST 2008 : > Wed Dec 31 16:59:50 MST 2008 : > Wed Dec 31 16:59:51 MST 2008 : > Wed Dec 31 16:59:52 MST 2008 : > Wed Dec 31 16:59:53 MST 2008 : > Wed Dec 31 16:59:54 MST 2008 : > Wed Dec 31 16:59:55 MST 2008 : > Wed Dec 31 16:59:56 MST 2008 : > Wed Dec 31 16:59:57 MST 2008 : > Wed Dec 31 16:59:58 MST 2008 : > Wed Dec 31 16:59:59 MST 2008 : > Wed Dec 31 16:59:59 MST 2008 : : this is wrong. No. this is correct. POSIX time_t cannot represent the leap second, since leap seconds aren't in posix time_t's. Therefore, you have to repeat one second, and the typical one to repeat is 59. Warner : > Wed Dec 31 17:00:00 MST 2008 : > Wed Dec 31 17:00:01 MST 2008 : > Wed Dec 31 17:00:02 MST 2008 : > Wed Dec 31 17:00:03 MST 2008 : > Wed Dec 31 17:00:04 MST 2008 : > : > Warner : > : > _______________________________________________ : > time-nuts mailing list -- time-nuts at febo.com : > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : > and follow the instructions there. : -- : Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland : http://www.msys.ch/ http://www.vnode.ch/ "In God we trust, in C we code." : : _______________________________________________ : time-nuts mailing list -- time-nuts at febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : From imp at bsdimp.com Thu Jan 1 00:57:33 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed, 31 Dec 2008 17:57:33 -0700 (MST) Subject: [time-nuts] FreeBSD 7 ntp server In-Reply-To: References: Message-ID: <20081231.175733.-1676911436.imp@bsdimp.com> In message: "Robert Darlington" writes: : Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my : system ticked :59 twice. Here's the output of my not so very : scientific logs (up arrow, enter, over and over): That's the correct output. It isn't possible to tick 60 with a POSIX time_t, so second 59 is replayed so that we don't cross a day boundary. Warner : ntp_gettime() returns code 1 (INS) : time cd0685ff.18496674 Wed, Dec 31 2008 16:59:59.094, (.094870766), : maximum error 4762 us, estimated error 15 us, TAI offset 33 : ntp_adjtime() returns code 1 (INS) : modes 0x0 (), : offset -0.278 us, frequency -0.051 ppm, interval 1 s, : maximum error 4762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 1 (INS) : time cd0685ff.65479d28 Wed, Dec 31 2008 16:59:59.395, (.395624242), : maximum error 4762 us, estimated error 15 us, TAI offset 33 : ntp_adjtime() returns code 1 (INS) : modes 0x0 (), : offset -0.278 us, frequency -0.051 ppm, interval 1 s, : maximum error 4762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 1 (INS) : time cd0685ff.b73eee0c Wed, Dec 31 2008 16:59:59.715, (.715804039), : maximum error 4762 us, estimated error 15 us, TAI offset 33 : ntp_adjtime() returns code 1 (INS) : modes 0x0 (), : offset -0.278 us, frequency -0.051 ppm, interval 1 s, : maximum error 4762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.03fb7a60 Wed, Dec 31 2008 16:59:59.015, (.015556955), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.50d0bb50 Wed, Dec 31 2008 16:59:59.315, (.315685712), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.9d5dc3c8 Wed, Dec 31 2008 16:59:59.614, (.614712868), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.ef985218 Wed, Dec 31 2008 16:59:59.935, (.935918664), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 4 (WAIT) : time cd068600.4e4a6a6c Wed, Dec 31 2008 17:00:00.305, (.305823220), : maximum error 5762 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 4 (WAIT) : modes 0x0 (), : offset -0.276 us, frequency -0.051 ppm, interval 1 s, : maximum error 5762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : : _______________________________________________ : time-nuts mailing list -- time-nuts at febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : From holrum at hotmail.com Thu Jan 1 01:02:16 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 01:02:16 +0000 Subject: [time-nuts] Thunderbolt Leapsecond missing In-Reply-To: References: Message-ID: Well, when you think about it that is exactly what is supposed to happen with GPS time... it is a continuous time scale without those pesky leapy discontinuities. My Tbolt feeds a system that is on GPS time. I did not want to upset it by changing the time to UTC, and I did want to see how the Thunderbolt GPS time scale handled it (and figured most people would be monitoring UTC). At 00:00:15 UTC the leapsecond indicator went off (recorded in the log). Unfortunately Lady Heather's program did not log changes in the UTC offset value (it does now) so I don't know if the UTC offset flag changed from 14 to 15 at 00:00:00 GPS or at 00:00:15 GPS. I suspect that it was the latter. _________________________________________________________________ Send e-mail anywhere. No map, no compass. http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008 From tvb at LeapSecond.com Thu Jan 1 01:07:50 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 31 Dec 2008 17:07:50 -0800 Subject: [time-nuts] Radio clock fails to leap References: <200901010037.n010bxUh024786@host22.the-web-host.com> Message-ID: > My low-end Radio Shack 'atomic clock' did not handle the leap second. Scott, I'm not sure if any of the low-cost radio clocks handle leap seconds correctly. Clearly the analog clocks can't (there is no way to show the 61st second with clock hands). But even the digital ones that could, don't. It's not a matter of reception. The WWVB leap second warning bit is set weeks or months before the event so the clocks have plenty of chances to know that there is an extra second at the end of the month. My guess is it's a matter of firmware or just a low-cost design marketing/engineering decision. If someone from a RC clock company is on the list, now is a good time to explain the reasoning for not handling leap seconds. Or, perhaps someone from NIST, who has contact with all those folks, can give us some insight. Half of them don't even do daylight savng time correctly so it may be a bit much to ask that they handle leap seconds. WWVB receivers made by Spectracom and Ultralink do the right thing; but these aren't around anymore. /tvb From danrae at verizon.net Thu Jan 1 01:09:48 2009 From: danrae at verizon.net (Dan Rae) Date: Wed, 31 Dec 2008 17:09:48 -0800 Subject: [time-nuts] Loran TOCs this year In-Reply-To: <6A72939BA85746B89BAAF6BE4C205708@pc52> References: <495C11E5.8030205@verizon.net> <6A72939BA85746B89BAAF6BE4C205708@pc52> Message-ID: <495C17DC.605@verizon.net> Tom Van Baak wrote: >> I have reset my Austron 2100 to the new UTC time, but the TOCs given by >> the USNO seem to be off. Should I maybe assume they have not allowed for >> the extra second and subtract one second from the posted times? >> Can the US Navy have got it wrong? Tbolt got it right... >> > > How do your TOC's compare with the one here: > http://www.leapsecond.com/java/gpsclock.htm > > /tvb > > > Yes, yours are correct Tom, it shows 01 10 05 for the next; while the USNO has 01 10 06. My Austron is happy now with the 1 second correction. I'll know where to look next time I need one after a power outage... dr From newell at cei.net Thu Jan 1 01:17:29 2009 From: newell at cei.net (Scott Newell) Date: Wed, 31 Dec 2008 19:17:29 -0600 Subject: [time-nuts] Radio clock fails to leap In-Reply-To: References: <200901010037.n010bxUh024786@host22.the-web-host.com> Message-ID: <200901010117.n011HZ2J031908@host22.the-web-host.com> At 07:07 PM 12/31/2008, Tom Van Baak wrote: > > My low-end Radio Shack 'atomic clock' did not handle the leap second. > >Scott, > >I'm not sure if any of the low-cost radio clocks handle leap >seconds correctly. Clearly the analog clocks can't (there is >no way to show the 61st second with clock hands). But even >the digital ones that could, don't. Well, this one certainly didn't. >It's not a matter of reception. The WWVB leap second warning >bit is set weeks or months before the event so the clocks have >plenty of chances to know that there is an extra second at the >end of the month. My guess is it's a matter of firmware or just My point exactly! And I was curious to see if it would do the right thing, since it could have all the needed info from the timecode. I'm sure they just didn't bother to write and test firmware for such an exceptional event. >Half of them don't even do daylight savng time correctly so it >may be a bit much to ask that they handle leap seconds. I think this one gets the daylight shift right, at least every time I've paid attention. >WWVB receivers made by Spectracom and Ultralink do the >right thing; but these aren't around anymore. I'm going to check the timecode to see when the leap second warning bit went off. As I recall, last leap they delayed the leap warning a couple of minutes. -- newell N5TNL From holrum at hotmail.com Thu Jan 1 01:18:04 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 01:18:04 +0000 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: Message-ID: 23:59:56 345596 -4.03678e-009 -0.003678 0.335436 33.993076 5 23:59:57 345597 -4.15043e-009 0.010043 0.335436 33.993092 5 23:59:58 345598 -4.24394e-009 0.015811 0.335436 33.993107 5 23:59:59 345599 -4.36684e-009 0.030786 0.335436 33.993122 5 # # 00:00:00 GPS 01 Jan 2009 - interval 1 seconds # #UTC tow pps(sec) osc(ppb) dac(v) temp(C) sats 00:00:00 345600 -4.4291e-009 0.028364 0.335436 33.992458 5 00:00:01 345601 -4.49405e-009 0.021724 0.335445 33.992538 5 00:00:02 345602 -4.56957e-009 0.022583 0.335445 33.992607 5 00:00:03 345603 -4.58285e-009 0.059188 0.335445 33.992672 5 00:00:04 345604 -4.63155e-009 0.035646 0.335445 33.992729 5 00:00:05 345605 -4.67117e-009 0.046273 0.335445 33.992783 5 00:00:06 345606 -4.70274e-009 0.047748 0.335445 33.992828 5 00:00:07 345607 -4.69422e-009 0.056536 0.335445 33.992195 5 00:00:08 345608 -4.65674e-009 0.020563 0.335445 33.992302 5 00:00:09 345609 -4.67156e-009 0.032311 0.335445 33.992397 5 00:00:10 345610 -4.56375e-009 0.003383 0.335445 33.992481 5 00:00:11 345611 -4.41723e-009 0.014511 0.335445 33.992558 5 00:00:12 345612 -4.29424e-009 0.021960 0.335436 33.991951 5 00:00:13 345613 -4.22418e-009 0.075930 0.335436 33.992081 5 00:00:14 345614 -4.13579e-009 0.035519 0.335436 33.992195 5 00:00:15 345615 -4.0077e-009 0.041159 0.335436 33.992302 5 #! new minor alarm state 0000: No leap second : at tow 345615 00:00:16 345616 -3.91597e-009 0.005888 0.335436 33.991722 5 00:00:17 345617 -3.84582e-009 0.005210 0.335426 33.991199 5 _________________________________________________________________ Life on your PC is safer, easier, and more enjoyable with Windows Vista?. http://clk.atdmt.com/MRT/go/127032870/direct/01/ From jra at febo.com Thu Jan 1 01:20:16 2009 From: jra at febo.com (John Ackermann N8UR) Date: Wed, 31 Dec 2008 20:20:16 -0500 Subject: [time-nuts] CHU 12/31 Frequency Change Message-ID: <495C1A50.2060104@febo.com> Was I the only one monitoring CHU? Things didn't go as I expected. It had been a few months since I had monitored 7335, so was surprised when in mid-afternoon a broadcaster (I think WHRI in Maine) was on frequency and totally obliterating CHU. I was more surprised when CHU was audible on the new 7850 frequency a couple of hours before 0000. Shortly before midnight, the broadcaster was gone, but there was no sign of CHU on 7335. The signal was audible, but not great, on 7850. I recorded both frequencies, but I don't think there's much exciting there. Because of the broadcast interference, I'm not sure if CHU made the frequency change early, or whether they were simulcasting for a few hours (there are notes on their web page about hardware modernization, so it's possible they had a new transmitter/antenna and were able to operate in parallel). John From mark.amos at toast.net Thu Jan 1 01:19:54 2009 From: mark.amos at toast.net (Mark Amos) Date: Wed, 31 Dec 2008 20:19:54 -0500 Subject: [time-nuts] t-bolt off by 3 seconds? Odd, that. Message-ID: <58bb770d422347278dc774f672341242.mark.amos@toast.net> From magnus at rubidium.dyndns.org Thu Jan 1 01:21:30 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 01 Jan 2009 02:21:30 +0100 Subject: [time-nuts] [Fwd: Leapsecond] Message-ID: <495C1A9A.80802@rubidium.dyndns.org> Hi folks! Hank, a not-so-innocent bystander made the attempt to capture the CHU transition, here is his report. Sloppy timing to start transmissions in advance like that... :) Happy new timing year! Cheers, Magnus -------------- next part -------------- An embedded message was scrubbed... From: hank Subject: Leapsecond Date: Wed, 31 Dec 2008 17:28:51 -0700 Size: 2539 Url: http://www.febo.com/pipermail/time-nuts/attachments/20090101/3c158770/attachment.eml From holrum at hotmail.com Thu Jan 1 01:32:29 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 01:32:29 +0000 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: Message-ID: Note that there is an error in the first column heading in Lady Heather's Leap Log. It says UTC... should be GPS. The three line hour timestamp comment is correct (UTC). The distributed version of the program logged only time-of-week. I added the HH:MM:SS yesterday but messed up the column header (boy is Lady Heather gonna be mad when She finds out). The random spacing is due to Billy Gates Quality Control... he still can't figure out where to put CRs and LFs in an email... _________________________________________________________________ It?s the same Hotmail?. If by ?same? you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008 From wbeam at gci.net Thu Jan 1 01:40:44 2009 From: wbeam at gci.net (Bill Beam) Date: Wed, 31 Dec 2008 16:40:44 -0900 Subject: [time-nuts] Thunderbolt Leapsecond missing Message-ID: <0KCR007WIRBAFU80@msgmmp-1.gci.net> This behaviour is exactly correct. GPS time never has a leap second. Leap seconds are only added to UTC. Note that the UTC Offset is now 15 seconds, no longer 14 seconds. Maybe it's time to review Time (nut) keeping 101.... On 12/31/2008 3:06:09 PM, Mark Sims (holrum at hotmail.com) wrote: > My Thunderbolt showed no leap second (set to display GPS time) ... went > from 23:59:59 to 00:00:00. 15 seconds after the hour the > "Leapsecond Pending" indicator went off. > _________________________________________________________________ > Send e-mail anywhere. No map, no compass. > http://windowslive. > com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008 > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time- > nuts > and follow the instructions there. Bill Beam NL7F From vilgotch at bigpond.net.au Thu Jan 1 01:44:52 2009 From: vilgotch at bigpond.net.au (Morris Odell) Date: Thu, 1 Jan 2009 12:44:52 +1100 Subject: [time-nuts] Trimble fails to leap References: Message-ID: <4D95CBBBEFA34AC9B0118C24FB4C581D@Morris1> Hi Nuts, I wasn't sure which of the several GPS receivers here to monitor (the classic time nut conundrum) and of course, picked the wrong one. I have a Trimble Lassen IQ in a disciplined 5061A running in non-Cs mode. Using their IQ monitor program it showed no trace of the leap second - just went from 23:59:59 to 00:00:00. I had a camera set up and everything :-( When's the next one? Morris From normn3ykf at stny.rr.com Thu Jan 1 01:59:21 2009 From: normn3ykf at stny.rr.com (Norman J McSweyn) Date: Wed, 31 Dec 2008 20:59:21 -0500 Subject: [time-nuts] m12+t leap second snippet Message-ID: <495C2379.3090301@stny.rr.com> Thanks to all who have helped me through my coding problems. 12 31 08 23 59 56 42 04.8083 N 075 54.8975 W 00274.9 000.2 236.6 0 2 02.0 08 0000 00 008 12 31 08 23 59 57 42 04.8083 N 075 54.8975 W 00274.9 000.2 228.8 0 2 02.0 08 0000 00 008 12 31 08 23 59 58 42 04.8083 N 075 54.8975 W 00274.9 000.2 251.5 0 2 02.0 08 0000 00 004 12 31 08 23 59 59 42 04.8083 N 075 54.8975 W 00274.8 000.1 240.3 0 2 02.0 08 0000 00 001 12 31 08 23 59 60 42 04.8083 N 075 54.8975 W 00274.9 000.2 239.4 0 2 02.0 08 0000 00 000 01 01 09 00 00 00 42 04.8083 N 075 54.8975 W 00274.9 000.2 231.3 0 2 02.0 08 0000 00 004 01 01 09 00 00 01 42 04.8083 N 075 54.8975 W 00275.0 000.2 241.6 0 2 02.0 08 0000 00 015 HNY ES HH de Norm n3ykf From sar10538 at gmail.com Thu Jan 1 02:00:26 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Thu, 1 Jan 2009 15:00:26 +1300 Subject: [time-nuts] Radio clock fails to leap In-Reply-To: References: <200901010037.n010bxUh024786@host22.the-web-host.com> Message-ID: <1231b6a80812311800k2b9e468dk3f84550900a5a849@mail.gmail.com> Tom, 2009/1/1 Tom Van Baak : >> My low-end Radio Shack 'atomic clock' did not handle the leap second. > > Scott, > > I'm not sure if any of the low-cost radio clocks handle leap > seconds correctly. Clearly the analog clocks can't (there is > no way to show the 61st second with clock hands). But even > the digital ones that could, don't. Surely you mean the 60th second as the convention is to start counting seconds from 0 :-) 73, Steve (been reading too many of Bruce's postings) Rooke -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From sar10538 at gmail.com Thu Jan 1 02:06:02 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Thu, 1 Jan 2009 15:06:02 +1300 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: Message-ID: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> 2009/1/1 Mark Sims : > > Note that there is an error in the first column heading in Lady Heather's Leap Log. It says UTC... should be GPS. The three line hour timestamp comment is correct (UTC). The distributed version of the program logged only time-of-week. I added the HH:MM:SS yesterday but messed up the column header (boy is Lady Heather gonna be mad when She finds out). The random spacing is due to Billy Gates Quality Control... he still can't figure out where to put CRs and LFs in an email... Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge his bets with both LF and CR. It's little wonder I always get a lot of double spacing here then :-) 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From sar10538 at gmail.com Thu Jan 1 02:08:57 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Thu, 1 Jan 2009 15:08:57 +1300 Subject: [time-nuts] Trimble fails to leap In-Reply-To: <4D95CBBBEFA34AC9B0118C24FB4C581D@Morris1> References: <4D95CBBBEFA34AC9B0118C24FB4C581D@Morris1> Message-ID: <1231b6a80812311808t4752e988p8d064e70772578d6@mail.gmail.com> 2009/1/1 Morris Odell : > > I wasn't sure which of the several GPS receivers here to monitor (the > classic time nut conundrum) and of course, picked the wrong one. I have a > Trimble Lassen IQ in a disciplined 5061A running in non-Cs mode. Using their > IQ monitor program it showed no trace of the leap second - just went from > 23:59:59 to 00:00:00. I had a camera set up and everything :-( > > When's the next one? Well, according to http://www.leapsecond.com/java/nixie.htm is seems to be happening right now :-) 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From hmurray at megapathdsl.net Thu Jan 1 02:10:01 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 31 Dec 2008 18:10:01 -0800 Subject: [time-nuts] Radio clock fails to leap In-Reply-To: Message from "Tom Van Baak" of "Wed, 31 Dec 2008 17:07:50 PST." Message-ID: <20090101021002.098B2BCD7@ip-64-139-1-69.sjc.megapath.net> > I'm not sure if any of the low-cost radio clocks handle > leap seconds correctly. > If someone from a RC clock company is on the list, now is a good time > to explain the reasoning for not handling leap seconds. If I was building a low cost radio clock, I'd probably ignore leap seconds. They don't happen very often. The chances of getting it wrong are too high. The customers won't notice a one second error, especially if it gets fixed before too long. > Clearly the analog clocks can't (there is no way to show the 61st > second with clock hands). They could stall the hands for a second at 23:59:59. That's what POSIX does. :) -- These are my opinions, not necessarily my employer's. I hate spam. From k1ggi at arrl.net Thu Jan 1 02:25:21 2009 From: k1ggi at arrl.net (Ed, k1ggi) Date: Wed, 31 Dec 2008 21:25:21 -0500 Subject: [time-nuts] Tbolt and CHU Message-ID: <006b01c96bb8$33676b60$0a01a8c0@ATHLONXP1700> Screen was recording at about 10 frames/sec. Attached image is of two frames, showing the Tbolt at the end of GPS second 14 and the beginning of second 15. These two are about 200msec apart. On the intervening frame (not shown), 100msec after the CHU tone arrived, the Tbolt serial stream hadn't completed and been displayed, but after 200msec, it had. Ignore the envelope and its timescale, it just monitored the audio recording and its length. An hour or so later, CHU on 7850 was audible but weak in eastern MA. Ed, k1ggi -------------- next part -------------- A non-text attachment was scrubbed... Name: leapTbolt.PNG Type: image/png Size: 57420 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20081231/29740ecd/attachment-0001.png From msa at latt.net Thu Jan 1 02:32:29 2009 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 1 Jan 2009 02:32:29 +0000 Subject: [time-nuts] CHU 12/31 Frequency Change In-Reply-To: <495C1A50.2060104@febo.com> References: <495C1A50.2060104@febo.com> Message-ID: <20090101023229.GE89298@mx1.latt.net> On Wed, Dec 31, 2008 at 08:20:16PM -0500, John Ackermann N8UR wrote: > Was I the only one monitoring CHU? I was monitoring CHU and WWV(5), and WWVB. A Dell laptop ate the recording of CHU and WWV audio (drat!), but for approximately 90 minutes before the change I was monitoring CHU on 7850. I also had the broadcast interference on the old frequency, but normally I can hear their audio (especially the ticks) underneath. It looks like they just outright moved a bit early (which makes sense; given the pending leap second, and the BC interference on the old frequency, moving to the new prior to the leap will let folks that are ready for it resync if needed.) > Things didn't go as I expected. It had been a few months since I had > monitored 7335, so was surprised when in mid-afternoon a broadcaster (I > think WHRI in Maine) was on frequency and totally obliterating CHU. And that would be why they are moving...I've heard a few different broadcasters QRMing CHU to the point where it's been difficult to use if not unusable. > of CHU on 7335. The signal was audible, but not great, on 7850. I > recorded both frequencies, but I don't think there's much exciting there. There wasn't. I was more interested in doing a comparison between WWV and CHU audio over the leap, but with that recording eaten, I only have one that extends from 0001 UTC onwards. Well, hopefully there will be another one :) --msa From holrum at hotmail.com Thu Jan 1 02:34:02 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 02:34:02 +0000 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: Message-ID: Sometime in the last month or so Billy G made a mod to Hotmail that totally messed things up. Started out you could not put a CR and/or LF into a message no matter what (they showed on the screen, but didn't arrive at their destination). Lately you can usually get a blank line in by inserting three CR's. All lines of Lady Heather's Leap Log have the three CR's... you can see the typical quality Microsoft software results... Billy must REALLY hate Mac's... I wonder what he is doing with all those CR's and LF's that he is skimming off his customers? Mayby they will show up in Widows 7.-----------Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge his bets with both LF and CR. It's little wonder I always get a lot of double spacing here then :-) _________________________________________________________________ It?s the same Hotmail?. If by ?same? you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008 From ericksonc2 at comcast.net Thu Jan 1 02:34:21 2009 From: ericksonc2 at comcast.net (Chris Erickson) Date: Wed, 31 Dec 2008 18:34:21 -0800 Subject: [time-nuts] Another failed leap second... Message-ID: <000001c96bb9$746cd0e0$5d4672a0$@net> My Traconex Time Source model 1030 rackmount WWV clock failed to catch the leap second. It readjusted to the correct time about an hour later. Not the typical low cost consumer radio clock, but it is about 20 years old. I don't have it hooked up to a computer to monitor the data port, but it obviously wasn't designed for this event. I did notice the second display was no longer in lock step with my other rubidium clocks, so it apparently was trying to handle the error by adjusting its timebase to compensate. It seems to have stabilized now after a couple of hours and is back in sync. Chris From jgd at johngsbbq.com Thu Jan 1 02:42:08 2009 From: jgd at johngsbbq.com (Neon John) Date: Wed, 31 Dec 2008 21:42:08 -0500 Subject: [time-nuts] FreeBSD 7 ntp server In-Reply-To: <20081231.175733.-1676911436.imp@bsdimp.com> References: <20081231.175733.-1676911436.imp@bsdimp.com> Message-ID: On Wed, 31 Dec 2008 17:57:33 -0700 (MST), "M. Warner Losh" wrote: >In message: > "Robert Darlington" writes: >: Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my >: system ticked :59 twice. Here's the output of my not so very >: scientific logs (up arrow, enter, over and over): > >That's the correct output. It isn't possible to tick 60 with a POSIX >time_t, so second 59 is replayed so that we don't cross a day >boundary. > >Warner > I wonder how application software handled that. Say, a transaction processing machine handling a few thousand transactions a second where the time stamp matters. What did the high res timer do? I'm thinking about, for example, stock trading where the first bid wins. Sub-second resolution is needed there, I think. I wonder if this was a mini-Y2K and folks haven't realized it yet? John -- John De Armond See my website for my current email address http://www.neon-john.com http://www.johndearmond.com <-- best little blog on the net! Tellico Plains, Occupied TN Alcohol, Tobacco & Firearms should be a convenience store, not a government agency. From jgd at johngsbbq.com Thu Jan 1 02:48:18 2009 From: jgd at johngsbbq.com (Neon John) Date: Wed, 31 Dec 2008 21:48:18 -0500 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> References: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> Message-ID: On Thu, 1 Jan 2009 15:06:02 +1300, "Steve Rooke" wrote: >2009/1/1 Mark Sims : >> >> Note that there is an error in the first column heading in Lady Heather's Leap Log. It says UTC... should be GPS. The three line hour timestamp comment is correct (UTC). The distributed version of the program logged only time-of-week. I added the HH:MM:SS yesterday but messed up the column header (boy is Lady Heather gonna be mad when She finds out). The random spacing is due to Billy Gates Quality Control... he still can't figure out where to put CRs and LFs in an email... > >Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge >his bets with both LF and CR. It's little wonder I always get a lot of >double spacing here then :-) But billy boy never did anything original. He copied CP/M, Intel ISIS and other early OSs. I argue that THEY got it right, separating a carriage return from a line feed. In the good old days, there were lots of times when one would want to advance a line feed without moving the carriage or vice versa. I know the *nix argument that the line terminator ought to be a single character and can't argue too loudly since I CAN put the port in raw mode. Still, that requires programming, as opposed to just creating or editing files and cat'ing them to the printer port. John -- John De Armond See my website for my current email address http://www.neon-john.com http://www.johndearmond.com <-- best little blog on the net! Tellico Plains, Occupied TN Risk: $20 hooker, year old condom. From hmurray at megapathdsl.net Thu Jan 1 02:49:17 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 31 Dec 2008 18:49:17 -0800 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: Message from Mark Sims of "Thu, 01 Jan 2009 02:34:02 GMT." Message-ID: <20090101024918.9048EBCD7@ip-64-139-1-69.sjc.megapath.net> > Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge > his bets with both LF and CR. It's little wonder I always get a lot of > double spacing here then :-) SMTP (mail transport protocol) does it one way. (It doesn't matter which.) Each system is supposed to translate to/from the network standard. -- These are my opinions, not necessarily my employer's. I hate spam. From sar10538 at gmail.com Thu Jan 1 03:28:06 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Thu, 1 Jan 2009 16:28:06 +1300 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> Message-ID: <1231b6a80812311928o3a31d0c5i98da37fa0f619868@mail.gmail.com> 2009/1/1 Neon John : > On Thu, 1 Jan 2009 15:06:02 +1300, "Steve Rooke" wrote: > >>2009/1/1 Mark Sims : >>> >>> Note that there is an error in the first column heading in Lady Heather's Leap Log. It says UTC... should be GPS. The three line hour timestamp comment is correct (UTC). The distributed version of the program logged only time-of-week. I added the HH:MM:SS yesterday but messed up the column header (boy is Lady Heather gonna be mad when She finds out). The random spacing is due to Billy Gates Quality Control... he still can't figure out where to put CRs and LFs in an email... >> >>Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge >>his bets with both LF and CR. It's little wonder I always get a lot of >>double spacing here then :-) > > But billy boy never did anything original. He copied CP/M, Intel ISIS and > other early OSs. I argue that THEY got it right, separating a carriage return > from a line feed. In the good old days, there were lots of times when one > would want to advance a line feed without moving the carriage or vice versa. > > I know the *nix argument that the line terminator ought to be a single > character and can't argue too loudly since I CAN put the port in raw mode. > Still, that requires programming, as opposed to just creating or editing files > and cat'ing them to the printer port. Programming??? $ cat < /dev/ttyS0 & $ stty raw < /dev/ttyS0 $ cat printer_file.txt >/dev/ttyS0 $ kill %1 I'm assuming your not reading anything meaningful FROM the printer but that is a pretty fair assumption. Obviously you can add any other stty commands to the same line or as separate lines. You can practically do anything from the shell, you only really need to program when things are quite time restrictive or the shell bogs down with to much work. 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From imp at bsdimp.com Thu Jan 1 04:22:53 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed, 31 Dec 2008 21:22:53 -0700 (MST) Subject: [time-nuts] FreeBSD 7 ntp server In-Reply-To: References: <20081231.175733.-1676911436.imp@bsdimp.com> Message-ID: <20081231.212253.-833597454.imp@bsdimp.com> In message: Neon John writes: : On Wed, 31 Dec 2008 17:57:33 -0700 (MST), "M. Warner Losh" : wrote: : : >In message: : > "Robert Darlington" writes: : >: Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my : >: system ticked :59 twice. Here's the output of my not so very : >: scientific logs (up arrow, enter, over and over): : > : >That's the correct output. It isn't possible to tick 60 with a POSIX : >time_t, so second 59 is replayed so that we don't cross a day : >boundary. : > : >Warner : > : : I wonder how application software handled that. Say, a transaction processing : machine handling a few thousand transactions a second where the time stamp : matters. What did the high res timer do? Same thing it normally does... : I'm thinking about, for example, stock trading where the first bid wins. : Sub-second resolution is needed there, I think. That's one of many reasons why I think that leap seconds are fundamentally incompatible with POSIX. : I wonder if this was a mini-Y2K and folks haven't realized it yet? :) Warner : John : -- : John De Armond : See my website for my current email address : http://www.neon-john.com : http://www.johndearmond.com <-- best little blog on the net! : Tellico Plains, Occupied TN : Alcohol, Tobacco & Firearms should be a convenience store, not a government agency. : : : _______________________________________________ : time-nuts mailing list -- time-nuts at febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : From sar10538 at gmail.com Thu Jan 1 04:47:01 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Thu, 1 Jan 2009 17:47:01 +1300 Subject: [time-nuts] FreeBSD 7 ntp server In-Reply-To: <20081231.212253.-833597454.imp@bsdimp.com> References: <20081231.175733.-1676911436.imp@bsdimp.com> <20081231.212253.-833597454.imp@bsdimp.com> Message-ID: <1231b6a80812312047k5d2d702djcdd9610f47bc945a@mail.gmail.com> 2009/1/1 M. Warner Losh : > In message: > Neon John writes: > : On Wed, 31 Dec 2008 17:57:33 -0700 (MST), "M. Warner Losh" > : wrote: > : > : >In message: > : > "Robert Darlington" writes: > : >: Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my > : >: system ticked :59 twice. Here's the output of my not so very > : >: scientific logs (up arrow, enter, over and over): > : > > : >That's the correct output. It isn't possible to tick 60 with a POSIX > : >time_t, so second 59 is replayed so that we don't cross a day > : >boundary. > : > > : >Warner > : > > : > : I wonder how application software handled that. Say, a transaction processing > : machine handling a few thousand transactions a second where the time stamp > : matters. What did the high res timer do? > > Same thing it normally does... > > : I'm thinking about, for example, stock trading where the first bid wins. > : Sub-second resolution is needed there, I think. > > That's one of many reasons why I think that leap seconds are > fundamentally incompatible with POSIX. > > : I wonder if this was a mini-Y2K and folks haven't realized it yet? Seems to have worked perfectly under OpenSUSE 11.1, kernel 2.6.27, with NTP here. It's just the poor Windblows systems that I worry about. 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From mpb45 at clanbaker.org Thu Jan 1 04:48:40 2009 From: mpb45 at clanbaker.org (Michael Baker) Date: Wed, 31 Dec 2008 23:48:40 -0500 Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? Message-ID: <495C4B28.8040107@clanbaker.org> Hello, Time-Nutters-- My LPRO Rb oscillator just arrived and I am looking for a source for a connector to fit it. The user-manual contains some info on the connector, but no info on where to make an actual purchase. Any suggestions from the list members on where to get a couple of these connectors? Jameco part-number? Allied Electronics part-number? Some other source? Any feedback on this would be much appreciated!! Thanks!! Mike Baker WA4HFR Gainesville, FL -------------------- From bruce.griffiths at xtra.co.nz Thu Jan 1 05:01:20 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 01 Jan 2009 18:01:20 +1300 Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? In-Reply-To: <495C4B28.8040107@clanbaker.org> References: <495C4B28.8040107@clanbaker.org> Message-ID: <495C4E20.1030901@xtra.co.nz> Michael Baker wrote: > Hello, Time-Nutters-- > > My LPRO Rb oscillator just arrived and I am > looking for a source for a connector to fit it. > > The user-manual contains some info on the > connector, but no info on where to make an > actual purchase. Any suggestions from the list > members on where to get a couple of these connectors? > > Jameco part-number? Allied Electronics part-number? > > Some other source? Any feedback on this would be > much appreciated!! > > Thanks!! > > Mike Baker > WA4HFR > Gainesville, FL > -------------------- > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > It appears to be a standard 0.1" spacing connector. Digikey have them. Just search for Amp 87165-2(socket inserts) and Amp 87133-2 (shell). Bruce From holrum at hotmail.com Thu Jan 1 05:21:16 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 05:21:16 +0000 Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? In-Reply-To: References: Message-ID: Any standard 10 pin flat ribbon cable header will fit on the pins just fine. You can probably salvage one off an ancient PC motherboard serial port header to DB-9 type RS-232 connector cable. Or see Ebay item 350112294584. The same seller has shorter cables for less. Or search Ebay for "10 pin idc" (without the quotes). _________________________________________________________________ It?s the same Hotmail?. If by ?same? you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008 From imp at bsdimp.com Thu Jan 1 05:37:33 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed, 31 Dec 2008 22:37:33 -0700 (MST) Subject: [time-nuts] FreeBSD 7 ntp server In-Reply-To: <1231b6a80812312047k5d2d702djcdd9610f47bc945a@mail.gmail.com> References: <20081231.212253.-833597454.imp@bsdimp.com> <1231b6a80812312047k5d2d702djcdd9610f47bc945a@mail.gmail.com> Message-ID: <20081231.223733.-484248541.imp@bsdimp.com> In message: <1231b6a80812312047k5d2d702djcdd9610f47bc945a at mail.gmail.com> "Steve Rooke" writes: : 2009/1/1 M. Warner Losh : : > In message: : > Neon John writes: : > : On Wed, 31 Dec 2008 17:57:33 -0700 (MST), "M. Warner Losh" : > : wrote: : > : : > : >In message: : > : > "Robert Darlington" writes: : > : >: Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my : > : >: system ticked :59 twice. Here's the output of my not so very : > : >: scientific logs (up arrow, enter, over and over): : > : > : > : >That's the correct output. It isn't possible to tick 60 with a POSIX : > : >time_t, so second 59 is replayed so that we don't cross a day : > : >boundary. : > : > : > : >Warner : > : > : > : : > : I wonder how application software handled that. Say, a transaction processing : > : machine handling a few thousand transactions a second where the time stamp : > : matters. What did the high res timer do? : > : > Same thing it normally does... : > : > : I'm thinking about, for example, stock trading where the first bid wins. : > : Sub-second resolution is needed there, I think. : > : > That's one of many reasons why I think that leap seconds are : > fundamentally incompatible with POSIX. : > : > : I wonder if this was a mini-Y2K and folks haven't realized it yet? : : Seems to have worked perfectly under OpenSUSE 11.1, kernel 2.6.27, : with NTP here. It's just the poor Windblows systems that I worry : about. Actually, most of the effects on systems that use an absolute time for timeouts. posix threads can cause a stutter of 1s. This can be quite hard to detect in many systems, but very bad in others... Warner From gbusg at comcast.net Thu Jan 1 06:12:20 2009 From: gbusg at comcast.net (Greg Burnett) Date: Wed, 31 Dec 2008 23:12:20 -0700 Subject: [time-nuts] WWVB Outages? References: <6E1D662C04714FEEB9A35778D0D85631@S0028384766><003101c96793$2f0b6860$6501a8c0@gb02> <49553853.9010509@febo.com><003d01c96795$b21f6600$6501a8c0@gb02> <4955626E.5050609@febo.com> Message-ID: <008201c96bd7$e866c640$6501a8c0@gb02> Anybody seeing the WWVB outage right now? It's apparently off the air, but I don't see that fact indicated at NIST's "WWVB Field Strength and Readability..." site: http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5482602 Greg From gbusg at comcast.net Thu Jan 1 06:15:34 2009 From: gbusg at comcast.net (Greg Burnett) Date: Wed, 31 Dec 2008 23:15:34 -0700 Subject: [time-nuts] WWVB Outages? References: <6E1D662C04714FEEB9A35778D0D85631@S0028384766><003101c96793$2f0b6860$6501a8c0@gb02> <49553853.9010509@febo.com><003d01c96795$b21f6600$6501a8c0@gb02><4955626E.5050609@febo.com> <008201c96bd7$e866c640$6501a8c0@gb02> Message-ID: <008601c96bd8$5c01ce60$6501a8c0@gb02> OK, I now see the outage showing on NIST's bar-graph also. (I was on the wrong date and had to scroll up to 2009-01-01.) http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5483202 Greg ----- Original Message ----- From: "Greg Burnett" To: "Discussion of precise time and frequency measurement" Sent: Wednesday, December 31, 2008 11:12 PM Subject: Re: [time-nuts] WWVB Outages? Anybody seeing the WWVB outage right now? It's apparently off the air, but I don't see that fact indicated at NIST's "WWVB Field Strength and Readability..." site: http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5482602 Greg _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From brooke at pacific.net Thu Jan 1 06:21:51 2009 From: brooke at pacific.net (Brooke Clarke) Date: Wed, 31 Dec 2008 22:21:51 -0800 Subject: [time-nuts] WWVB Outages? In-Reply-To: <008201c96bd7$e866c640$6501a8c0@gb02> References: <6E1D662C04714FEEB9A35778D0D85631@S0028384766><003101c96793$2f0b6860$6501a8c0@gb02> <49553853.9010509@febo.com><003d01c96795$b21f6600$6501a8c0@gb02> <4955626E.5050609@febo.com> <008201c96bd7$e866c640$6501a8c0@gb02> Message-ID: <495C60FF.4010806@pacific.net> Hi Greg: It's 5 by 9 here in N. Calif. Have Fun, Brooke Clarke http://www.prc68.com Greg Burnett wrote: > Anybody seeing the WWVB outage right now? It's apparently off the air, but I > don't see that fact indicated at NIST's "WWVB Field Strength and > Readability..." site: http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5482602 > > Greg > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From gbusg at comcast.net Thu Jan 1 06:23:36 2009 From: gbusg at comcast.net (Greg Burnett) Date: Wed, 31 Dec 2008 23:23:36 -0700 Subject: [time-nuts] WWVB Outages? References: <6E1D662C04714FEEB9A35778D0D85631@S0028384766><003101c96793$2f0b6860$6501a8c0@gb02> <49553853.9010509@febo.com><003d01c96795$b21f6600$6501a8c0@gb02><4955626E.5050609@febo.com><008201c96bd7$e866c640$6501a8c0@gb02> <008601c96bd8$5c01ce60$6501a8c0@gb02> Message-ID: <008c01c96bd9$7b4f7550$6501a8c0@gb02> It's now back on the air, both as received at my location, and as indicated by NIST's site: http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5483202 Greg ----- Original Message ----- From: "Greg Burnett" To: "Discussion of precise time and frequency measurement" Sent: Wednesday, December 31, 2008 11:15 PM Subject: Re: [time-nuts] WWVB Outages? OK, I now see the outage showing on NIST's bar-graph also. (I was on the wrong date and had to scroll up to 2009-01-01.) http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5483202 Greg ----- Original Message ----- From: "Greg Burnett" To: "Discussion of precise time and frequency measurement" Sent: Wednesday, December 31, 2008 11:12 PM Subject: Re: [time-nuts] WWVB Outages? Anybody seeing the WWVB outage right now? It's apparently off the air, but I don't see that fact indicated at NIST's "WWVB Field Strength and Readability..." site: http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5482602 Greg _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From gbusg at comcast.net Thu Jan 1 06:27:04 2009 From: gbusg at comcast.net (Greg Burnett) Date: Wed, 31 Dec 2008 23:27:04 -0700 Subject: [time-nuts] WWVB Outages? References: <6E1D662C04714FEEB9A35778D0D85631@S0028384766><003101c96793$2f0b6860$6501a8c0@gb02> <49553853.9010509@febo.com><003d01c96795$b21f6600$6501a8c0@gb02> <4955626E.5050609@febo.com><008201c96bd7$e866c640$6501a8c0@gb02> <495C60FF.4010806@pacific.net> Message-ID: <009001c96bd9$f6d50280$6501a8c0@gb02> Yeah, Brooke, it just came back on. It was off for about an hour. During that hour my Truetime WWVB receiver/comparator accumulated more microseconds of offset than it could store -- when that happens it's display blinks on and off at about a 1 second rate as a warning. Cheers, Greg ----- Original Message ----- From: "Brooke Clarke" To: "Discussion of precise time and frequency measurement" Sent: Wednesday, December 31, 2008 11:21 PM Subject: Re: [time-nuts] WWVB Outages? Hi Greg: It's 5 by 9 here in N. Calif. Have Fun, Brooke Clarke http://www.prc68.com Greg Burnett wrote: > Anybody seeing the WWVB outage right now? It's apparently off the air, but > I > don't see that fact indicated at NIST's "WWVB Field Strength and > Readability..." site: http://tf.nist.gov/tf-cgi/wwvbgraph_e.cgi?5482602 > > Greg > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From hmurray at megapathdsl.net Thu Jan 1 11:33:38 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 01 Jan 2009 03:33:38 -0800 Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? In-Reply-To: Message from Michael Baker of "Wed, 31 Dec 2008 23:48:40 EST." <495C4B28.8040107@clanbaker.org> Message-ID: <20090101113339.22F64BCD7@ip-64-139-1-69.sjc.megapath.net> > The user-manual contains some info on the connector, but no info on > where to make an actual purchase. Any suggestions from the list > members on where to get a couple of these connectors? If the user manual has the manufacturer's part numbers, my first try would be to feed them to the search stuff on my favorite distributor. Tyco gobbled up AMP a while ago, so the manufacturer for the AMP part numbers is now Tyco. That style of connectors is a pain until you fork over the cash for a good crimp tool. Digikey has the 87133-2 (shell) for $1.68 and the 5-87165-2 (pins) for $0.49 each. Note the extra 5- on the front of the part number for the pins. That's the lead free version. If you want lead, the price is a bit higher. 87165-1 is the gold plated version. The drawing for the shell said 87124 was the part number for the pins. That's probably newer/cheaper/better. Digikey says over $500 for the hand tool. That's more than I'm willing to pay. I have the Molex version. Digikey says "please call" for the one I have and over $300 for the alternate. Mumble. I was thinking of $100 or so. Maybe you should hope a nearby buddy has one. -- These are my opinions, not necessarily my employer's. I hate spam. From eric.fort at gmail.com Thu Jan 1 12:02:29 2009 From: eric.fort at gmail.com (Eric Fort) Date: Thu, 1 Jan 2009 04:02:29 -0800 Subject: [time-nuts] radio clocks Message-ID: <2ad2af430901010402r274aa24fm66a61f05d3ebf34b@mail.gmail.com> Does anyone know of a (WWVB) radio controlled clock that meets all the necessary points and many if not most of the optional points listed in the compliance checklist in section 10 of NIST Special Publication 960-14, available for reference here: http://tf.nist.gov/general/pdf/1976.pdf (compliance checklist begins on pdf page 47/64) Thanks, Eric From n1jez at burlingtontelecom.net Thu Jan 1 13:07:32 2009 From: n1jez at burlingtontelecom.net (n1jez at burlingtontelecom.net) Date: Thu, 01 Jan 2009 08:07:32 -0500 Subject: [time-nuts] Z3801A & LED display... Message-ID: <20090101130732.C8A9D35F73E@mail.burlingtontelecom.net> That would be neat to get a copy. I've saved a screen shot of a Thunderbolt at 23:59:60. Thought I'd show it at the 1/10 NEWS meeting. Got our new FM antenna installed for WVTQ-FM on Equinox. http://vprblog.blogspot.com/2008/12/intrepid-engineering.html Mike On Thu Dec 31 19:57 , sent: FWIW... I have one of my Z3801A running with an external LED display that's based on one of the Dave Robinson, G4FRE PIC controllers. His design reads the raw binary output from the internal GPS RX. A mini-disc cam-corder was aimed at the display and caught the leapsecond. ie: 23:59:58 23:59:59 23:59:60 00:00:00 00:00:01 I'll try and snag a few seconds of video from the DVD around the event if anybody is interested. Had WWV on in the background but was not mic'ed very well so sound is low. -Brian, WA1ZMS _______________________________________________ time-nuts mailing list -- [1]time-nuts at febo.com To unsubscribe, go to [2]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ---- Act Locally. Connect Globally. Burlington Telecom: It's Your Network. References 1. javascript:top.opencompose('time-nuts at febo.com','','','') 2. file://localhost/tmp/parse.pl?redirect=https%3A%2F%2Fwww.febo.com%2Fcgi-bin%2Fmailman%2Flistinfo%2Ftime-nuts From jltran at worldnet.att.net Thu Jan 1 13:25:18 2009 From: jltran at worldnet.att.net (J. L. Trantham) Date: Thu, 1 Jan 2009 07:25:18 -0600 Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? In-Reply-To: <20090101113339.22F64BCD7@ip-64-139-1-69.sjc.megapath.net> Message-ID: <9AEEB529233143A89CD1A070394490A3@S0028384766> I hate buying pieces one at a time. These connectors are used in many projects having to do with GPSDO's, oscillators, GPS receivers, Brooks Shera's controller board, etc. I bought a Molex MXKK-100 'Kit' of parts for about $55 that included a workable crimp tool that I have used on other connectors as well. Unfortunately, it did not come with the two row, 5 pin per row housings that are used on the LPRO-101. However, I bet you could use two of the single row, 5 pin per row, housings on the LPRO and do just fine. I ordered spare housings and spare pins in several configurations and materials and used the crimper just fine. There is also a KK-100 Kit but the crimper is not as nice. Just search for MXKK-100 on Digi-Key or Mouser, etc. Joe -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Hal Murray Sent: Thursday, January 01, 2009 5:34 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Connector source for LPRO Rb oscillator...?? > The user-manual contains some info on the connector, but no info on > where to make an actual purchase. Any suggestions from the list > members on where to get a couple of these connectors? If the user manual has the manufacturer's part numbers, my first try would be to feed them to the search stuff on my favorite distributor. Tyco gobbled up AMP a while ago, so the manufacturer for the AMP part numbers is now Tyco. That style of connectors is a pain until you fork over the cash for a good crimp tool. Digikey has the 87133-2 (shell) for $1.68 and the 5-87165-2 (pins) for $0.49 each. Note the extra 5- on the front of the part number for the pins. That's the lead free version. If you want lead, the price is a bit higher. 87165-1 is the gold plated version. The drawing for the shell said 87124 was the part number for the pins. That's probably newer/cheaper/better. Digikey says over $500 for the hand tool. That's more than I'm willing to pay. I have the Molex version. Digikey says "please call" for the one I have and over $300 for the alternate. Mumble. I was thinking of $100 or so. Maybe you should hope a nearby buddy has one. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From bob.paddock at gmail.com Thu Jan 1 13:48:36 2009 From: bob.paddock at gmail.com (Bob Paddock) Date: Thu, 1 Jan 2009 08:48:36 -0500 Subject: [time-nuts] FreeBSD 7 ntp server In-Reply-To: References: <20081231.175733.-1676911436.imp@bsdimp.com> Message-ID: > > > I'm thinking about, for example, stock trading where the first bid wins. > Sub-second resolution is needed there, I think. Advanced Message Queuing Protocol (AMQP) is what is used in some big brokerage firms. http://jira.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol Specs are here: http://jira.amqp.org/confluence/display/AMQP/Download The datetime type encodes a date and time using the 64 bit POSIX time_t format. Also http://cr.yp.to/time.html maybe of interest to Time Nuts. -- http://www.wearablesmartsensors.com/ http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/ From phk at phk.freebsd.dk Thu Jan 1 14:28:04 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 01 Jan 2009 14:28:04 +0000 Subject: [time-nuts] DCF77, HBG, MSF, two out of three Message-ID: <55810.1230820084@critter.freebsd.dk> Here are my preliminary reduction of the VLF recording I made: http://phk.freebsd.dk/Leap/20081231/ DCF77 got right, as always. HBG also got it right this time. MSF still fumbles the DUT1 bits. It could look like all three stations take a S/N hit due to fireworks, both local and remote, but this is purely guesswork. I wish we could persuade PTB to light the leap-pending bit more than one hour in advance, it seems that HBG already do this, so it would be pretty harmless I expect. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From n1jez at burlingtontelecom.net Thu Jan 1 14:48:16 2009 From: n1jez at burlingtontelecom.net (n1jez at burlingtontelecom.net) Date: Thu, 01 Jan 2009 09:48:16 -0500 Subject: [time-nuts] Z3801A & LED display... Message-ID: <20090101144817.7D4F635F773@mail.burlingtontelecom.net> Sorry, meant to send this directly to Brian. Mike On Thu Jan 1 8:07 , sent: That would be neat to get a copy. I've saved a screen shot of a Thunderbolt at 23:59:60. Thought I'd show it at the 1/10 NEWS meeting. Got our new FM antenna installed for WVTQ-FM on Equinox. [1]http://vprblog.blogspot.com/2008/12/intrepid-engineering.html Mike On Thu Dec 31 19:57 , sent: FWIW... I have one of my Z3801A running with an external LED display that's based on one of the Dave Robinson, G4FRE PIC controllers. His design reads the raw binary output from the internal GPS RX. A mini-disc cam-corder was aimed at the display and caught the leapsecond. ie: 23:59:58 23:59:59 23:59:60 00:00:00 00:00:01 I'll try and snag a few seconds of video from the DVD around the event if anybody is interested. Had WWV on in the background but was not mic'ed very well so sound is low. -Brian, WA1ZMS _______________________________________________ time-nuts mailing list -- [1][2]time-nuts at febo.com To unsubscribe, go to [2][3]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ---- Act Locally. Connect Globally. Burlington Telecom: It's Your Network. References 1. javascript:top.opencompose('[4]time-nuts at febo.com','','','') 2. [5]file://localhost/tmp/parse.pl\?redirect=https%3A%2F%2Fwww.febo.c om%2Fcgi-bin%2Fmailman%2Flistinfo%2Ftime-nuts _______________________________________________ time-nuts mailing list -- [6]time-nuts at febo.com To unsubscribe, go to [7]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ---- Act Locally. Connect Globally. Burlington Telecom: It's Your Network. References 1. file://localhost/tmp/parse.pl?redirect=http%3A%2F%2Fvprblog.blogspot.com%2F2008%2F12%2Fintrepid-engineering.html 2. javascript:top.opencompose('time-nuts at febo.com','','','') 3. file://localhost/tmp/parse.pl?redirect=https%3A%2F%2Fwww.febo.com%2Fcgi-bin%2Fmailman%2Flistinfo%2Ftime-nuts 4. javascript:top.opencompose('time-nuts at febo.com','','','') 5. file://localhost/tmp/parse.pl?redirect=file%3A%2F%2Flocalhost%2Ftmp%2Fparse.pl%3Fredirect%3Dhttps%253A%252F%252Fwww.febo.com%252Fcgi-bin%252Fmailman%252Flistinfo%252Ftime-nuts 6. javascript:top.opencompose('time-nuts at febo.com','','','') 7. file://localhost/tmp/parse.pl?redirect=https%3A%2F%2Fwww.febo.com%2Fcgi-bin%2Fmailman%2Flistinfo%2Ftime-nuts From didier at cox.net Thu Jan 1 15:19:27 2009 From: didier at cox.net (Didier) Date: Thu, 1 Jan 2009 09:19:27 -0600 Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? In-Reply-To: <20090101113339.22F64BCD7@ip-64-139-1-69.sjc.megapath.net> References: Message from Michael Baker of "Wed, 31 Dec 2008 23:48:40 EST." <495C4B28.8040107@clanbaker.org> <20090101113339.22F64BCD7@ip-64-139-1-69.sjc.megapath.net> Message-ID: <0B68F7D32B064028A923EB323E764F7D@didierhp> As a crimping tool, I use a small vise I have normally secured to my bench. That works very well. I have used it for about 15 years and made hundreds of cables for that type of connector, up to and including the 40 pin type used for hard drives (the old parallel ATA type). It is too bad that while the 10 pin connector is very common in older PCs to connect the serial ports from the mothercard to the rear panel, in that application they only crimp 9 wires (because there is a 9 pin serial connector at the other end), and the LPRO needs both wires at the end, so while you may reuse the connector itself (they are not too hard to take apart, even though you need to be careful if you intend to reuse the connector), you need to make a new cable. Didier > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Hal Murray > Sent: Thursday, January 01, 2009 5:34 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Connector source for LPRO Rb oscillator...?? > > > > The user-manual contains some info on the connector, but no info on > > where to make an actual purchase. Any suggestions from the list > > members on where to get a couple of these connectors? > > If the user manual has the manufacturer's part numbers, my > first try would be to feed them to the search stuff on my > favorite distributor. > > Tyco gobbled up AMP a while ago, so the manufacturer for the > AMP part numbers is now Tyco. > > That style of connectors is a pain until you fork over the > cash for a good crimp tool. > > Digikey has the 87133-2 (shell) for $1.68 and the 5-87165-2 > (pins) for $0.49 each. > > Note the extra 5- on the front of the part number for the > pins. That's the lead free version. If you want lead, the > price is a bit higher. 87165-1 is the gold plated version. > > The drawing for the shell said 87124 was the part number for > the pins. > That's probably newer/cheaper/better. > > Digikey says over $500 for the hand tool. That's more than > I'm willing to pay. I have the Molex version. Digikey says > "please call" for the one I have and over $300 for the > alternate. Mumble. I was thinking of $100 or so. > Maybe you should hope a nearby buddy has one. > > > > > > > > > -- > These are my opinions, not necessarily my employer's. I hate spam. > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From GandalfG8 at aol.com Thu Jan 1 15:36:11 2009 From: GandalfG8 at aol.com (GandalfG8 at aol.com) Date: Thu, 1 Jan 2009 10:36:11 EST Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? Message-ID: In a message dated 01/01/2009 15:20:12 GMT Standard Time, didier at cox.net writes: As a crimping tool, I use a small vise I have normally secured to my bench. That works very well. I have used it for about 15 years and made hundreds of cables for that type of connector, up to and including the 40 pin type used for hard drives (the old parallel ATA type). It is too bad that while the 10 pin connector is very common in older PCs to connect the serial ports from the mothercard to the rear panel, in that application they only crimp 9 wires (because there is a 9 pin serial connector at the other end), and the LPRO needs both wires at the end, so while you may reuse the connector itself (they are not too hard to take apart, even though you need to be careful if you intend to reuse the connector), you need to make a new cable. -------------- I agree re the vise, having done the same myself, but in this instance why not just cut off part of an old floppy or hard drive cable, enough to leave the 10 sockets and attached wiring? For personal use it's not so important to have a locating lug, and smaller connectors quite often didn't have them anyway. regards Nigel GM8PZR From james.p.lux at jpl.nasa.gov Thu Jan 1 16:10:23 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 1 Jan 2009 08:10:23 -0800 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> Message-ID: On 12/31/08 6:06 PM, "Steve Rooke" wrote: > 2009/1/1 Mark Sims : >> >> Note that there is an error in the first column heading in Lady Heather's >> Leap Log. It says UTC... should be GPS. The three line hour timestamp >> comment is correct (UTC). The distributed version of the program logged only >> time-of-week. I added the HH:MM:SS yesterday but messed up the column header >> (boy is Lady Heather gonna be mad when She finds out). The random spacing is >> due to Billy Gates Quality Control... he still can't figure out where to put >> CRs and LFs in an email... > > Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge > his bets with both LF and CR. It's little wonder I always get a lot of > double spacing here then :-) > Hardly microsoft's fault. Blame the teletype. Or perhaps DEC. RT-11 stored CR/LF in files, and CP/M adopted that convention, followed by DOS, etc. I imagine RT-11 did CR/LF because A) it allows use of unmodified KSR/ASR 33 TTYs without having to worry if the user has the autoLF option B) with ink on paper, the ability to do overprints (CR w/o LF) is actually useful. Them newfangled CRT based terminals can't do this (except for the Tek 401x series) Jim From had at to-way.com Thu Jan 1 16:12:24 2009 From: had at to-way.com (Had) Date: Thu, 01 Jan 2009 08:12:24 -0800 Subject: [time-nuts] Netclock/2 Freeze Message-ID: <20090101161224.E0840D5CAE7@mail-in06.adhost.com> Now that the "Event" has passed I noticed only one weird anomaly; my Spectracom Netcloock/2 (WWVB) display froze at the 59/00 event and required a hard reset to get it back to life. All front panel LEDs stayed green just the display was stuck at xx:xx:59. I was not in the shop yesterday so could not watch things happen as the leap second was added. Anybody else have weirdness to report. Had K7MLR From cfharris at erols.com Thu Jan 1 16:37:29 2009 From: cfharris at erols.com (Chuck Harris) Date: Thu, 01 Jan 2009 11:37:29 -0500 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: Message-ID: <495CF149.5000500@erols.com> Lux, James P wrote: >> Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge >> his bets with both LF and CR. It's little wonder I always get a lot of >> double spacing here then :-) >> > > Hardly microsoft's fault. Blame the teletype. Or perhaps DEC. RT-11 stored > CR/LF in files, and CP/M adopted that convention, followed by DOS, etc. > I imagine RT-11 did CR/LF because > A) it allows use of unmodified KSR/ASR 33 TTYs without having to worry if > the user has the autoLF option > B) with ink on paper, the ability to do overprints (CR w/o LF) is actually > useful. Them newfangled CRT based terminals can't do this (except for the > Tek 401x series) The fault was in the thinking that there would never be more than one or two terminal types used as consoles and I/O devices, so the applications programs should handle I/O directly. That fault was fixed once and for all with unix's termcap... the idea that the driver should present as common as possible of an interface to the application. MS had ample opportunity to follow that example, as it was well established back in the early 1970's. They chose instead to reinvent the wheel, and ignore most of the advances that came before them. They still do. -Chuck Harris From joegwinn at comcast.net Thu Jan 1 16:45:16 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Thu, 1 Jan 2009 11:45:16 -0500 Subject: [time-nuts] Leap seconds and POSIX Message-ID: Having worked in the POSIX committee for many years, I can shed some light on how POSIX handles leap seconds: In short, POSIX adamantly ignores leap seconds. All days in POSIX have the same length, 86,400 seconds. This omission is not by accident, instead having been violently debated at length, and voted upon. The rationale is that one cannot assume that all POSIX systems have access to leap second information, or even the correct time, and yet must work in a reasonable manner. In particular, file modification timestamps must allow one to determine causal order (to within one second in the old days) by comparison of timestamps. (Yes, people do realize that timestamps are not the perfect way to establish causal order, but are nonetheless widely used in non-critical applications. Critical applications instead use some kind of atomic sequence-number scheme.) So, at least in theory, POSIX time is a form of TAI, having a constant offset from TAI. In practice, in platforms that have access to GPS, NTP is used to servo the local computer clock into alignment with UTC (or GPS System Time (UTC without the accumulated leaps) in systems that abhor time steps), and there is a transient error just after a leap second while NTP recovers. Joe From holrum at hotmail.com Thu Jan 1 18:09:48 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 18:09:48 +0000 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: Message-ID: All the CR/LF strangeness that I have been having are absolutely positively Microsoft's fault. Hotmail is a web based email. You enter your text in a standard web form. Words wrap at the right margin. When you get to the end of a paragraph you press RETURN to start a new paragraph and RETURN RETURN to start a new paragraph with a blank line between them. This is the way every web form works. And it is the way Hotmail has worked for the last 10+ years. A couple months ago, Billy G decided to pimp out the Hotmail user interface and in usual Microsoft style totally screwed things up. Besides requiring three times as many clicks to log in, many features either do not work or mess up. The paragraph/RETURN thing is just one. Sometimes you get your paragraph/spacing, other times you don't. Sometimes a button works, sometimes it don't. Sometimes you can log in, sometimes you don't. Sometimes it locks up, sometimes it don't. This occurs with both Firefox and Safari. I don't use Internet Exploder. I doubt that problems that are as apparent as these would have gone unnoticed and unfixed... I can only assume the Microsoft has yet again intentionally hobbled a product so that it does not work with competitors products/browsers. Luckily Hotmail is the sole Microsoft product that I have to use. _________________________________________________________________ Life on your PC is safer, easier, and more enjoyable with Windows Vista?. http://clk.atdmt.com/MRT/go/127032870/direct/01/ From mpb45 at clanbaker.org Thu Jan 1 18:21:58 2009 From: mpb45 at clanbaker.org (Michael Baker) Date: Thu, 01 Jan 2009 13:21:58 -0500 Subject: [time-nuts] Another LPRO-101 Rb Osc question... Message-ID: <495D09C6.1070102@clanbaker.org> Hello, Time-Nutters-- In looking at the LPRO-101 unit I'm holding in my grubby little paw, I note that the base of the case has a thin layer of some sort of pale-green slippery material glued to it. Is this the heat-transfer tape/pad mentioned in the user manual that must be placed on the base before bolting to a heat-sink? I notice six threaded insert holes in the bottom for bolting to a heat sink-- The user's manual gives mounting screw clearance info for the bottom plate. However: I would like to place a small terminal strip on the top of the case with an RF connector and some easy/convenient connection lugs for power and monitoring, etc. Question--: how much clearance is there between the top of the case and internal components? It is not clear to me how to remove the top case section for a look inside to check on component clearance-- The top cover does not appear to be screwed in place, but I am reluctant to just try some experimental prying. Does the case slide off? There appear to be what look like tiny detent-dimples all around the sides of the upper case lid. Is this what retains the upper case in place? Does it lift off with very careful prying? Has anyone done this before? Thanks-- Mike Baker WA4HFR Gainesville, FL ------------------------ From imp at bsdimp.com Thu Jan 1 18:28:03 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu, 01 Jan 2009 11:28:03 -0700 (MST) Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: References: Message-ID: <20090101.112803.179959520.imp@bsdimp.com> In message: Joe Gwinn writes: : Having worked in the POSIX committee for many years, I can shed some : light on how POSIX handles leap seconds: : : In short, POSIX adamantly ignores leap seconds. All days in POSIX : have the same length, 86,400 seconds. : : This omission is not by accident, instead having been violently : debated at length, and voted upon. : : The rationale is that one cannot assume that all POSIX systems have : access to leap second information, or even the correct time, and yet : must work in a reasonable manner. In particular, file modification : timestamps must allow one to determine causal order (to within one : second in the old days) by comparison of timestamps. (Yes, people do : realize that timestamps are not the perfect way to establish causal : order, but are nonetheless widely used in non-critical applications. : Critical applications instead use some kind of atomic sequence-number : scheme.) If POSIX had allowed for the system time to be TAI, and have the offset applied for the display of times, then there would be no ambiguity. However, this is not allowed because one must be able to do math on time_t such that time_t % 86400 is midnight. : So, at least in theory, POSIX time is a form of TAI, having a : constant offset from TAI. Except that the offset isn't constant :(. : In practice, in platforms that have access to GPS, NTP is used to : servo the local computer clock into alignment with UTC (or GPS System : Time (UTC without the accumulated leaps) in systems that abhor time : steps), and there is a transient error just after a leap second while : NTP recovers. When the INS bit is set in the NTP packets, NTP tells the kernel about it, which replays the last second of the day to keep in step. I'm not sure this is a transient error or not, since ntp_gettime can be used to determine that this is the leap second for applications that care. However, it does introduce a glitch in the data produced by system interfaces that don't have leap second indicators... Warner From glennmaillist at bellsouth.net Thu Jan 1 18:32:19 2009 From: glennmaillist at bellsouth.net (Glenn Little WB4UIV) Date: Thu, 01 Jan 2009 13:32:19 -0500 Subject: [time-nuts] Another LPRO-101 Rb Osc question... In-Reply-To: <495D09C6.1070102@clanbaker.org> References: <495D09C6.1070102@clanbaker.org> Message-ID: <6.2.3.4.2.20090101132827.0398a6c0@mail.bellsouth.net> Note the position of the connector. This is really a filter plate with leads that also extend into the connector on the oscillator. Remove the two spacer nuts. Pull the filter plate out. Remove the cover. When you reassemble the cover, make sure that you install the filter plate correctly. I would like to know what the other connector is for and what the headers inside the oscillator are for. These are not mentioned in the manual available on the web. 73 Glenn WB4UIV At 01:21 PM 1/1/2009, you wrote: >Hello, Time-Nutters-- > >In looking at the LPRO-101 unit I'm holding in >my grubby little paw, I note that the base of >the case has a thin layer of some sort of >pale-green slippery material glued to it. > >Is this the heat-transfer tape/pad mentioned in >the user manual that must be placed on the base >before bolting to a heat-sink? > >I notice six threaded insert holes in the bottom >for bolting to a heat sink-- The user's manual >gives mounting screw clearance info for the bottom >plate. However: > >I would like to place a small terminal strip >on the top of the case with an RF connector >and some easy/convenient connection lugs for power >and monitoring, etc. > >Question--: how much clearance is there between >the top of the case and internal components? > >It is not clear to me how to remove the top case >section for a look inside to check on component >clearance-- > >The top cover does not appear to be screwed in place, >but I am reluctant to just try some experimental >prying. Does the case slide off? There appear to >be what look like tiny detent-dimples all around >the sides of the upper case lid. Is this what >retains the upper case in place? Does it lift off >with very careful prying? > >Has anyone done this before? > >Thanks-- > >Mike Baker >WA4HFR >Gainesville, FL >------------------------ > > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From didier at cox.net Thu Jan 1 18:32:03 2009 From: didier at cox.net (Didier) Date: Thu, 1 Jan 2009 12:32:03 -0600 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> Message-ID: <50B3BAE5E2BC47E2AF56372625FCF0E5@didierhp> The reason for CR/LF is that CR takes a while on a teletype, while LF is fast, so sending both allowed enough time for the paper/print head to be in the right place before printing the next char. If you sent LF/CR on a teletype instead of CR/LF, you could see right away the reason :-) Didier PS: while writing this, I suddenly realized that it really dates me, doesn't it? > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Lux, James P > Sent: Thursday, January 01, 2009 10:10 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Lady Heather's Leap Log > > > > > On 12/31/08 6:06 PM, "Steve Rooke" wrote: > > > 2009/1/1 Mark Sims : > >> > >> Note that there is an error in the first column heading in Lady > >> Heather's Leap Log. It says UTC... should be GPS. The > three line > >> hour timestamp comment is correct (UTC). The distributed > version of > >> the program logged only time-of-week. I added the > HH:MM:SS yesterday > >> but messed up the column header (boy is Lady Heather gonna be mad > >> when She finds out). The random spacing is due to Billy Gates > >> Quality Control... he still can't figure out where to put > CRs and LFs in an email... > > > > Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge > > his bets with both LF and CR. It's little wonder I always > get a lot of > > double spacing here then :-) > > > > Hardly microsoft's fault. Blame the teletype. Or perhaps DEC. > RT-11 stored CR/LF in files, and CP/M adopted that > convention, followed by DOS, etc. > I imagine RT-11 did CR/LF because > A) it allows use of unmodified KSR/ASR 33 TTYs without having > to worry if the user has the autoLF option > B) with ink on paper, the ability to do overprints (CR w/o > LF) is actually useful. Them newfangled CRT based terminals > can't do this (except for the Tek 401x series) > > > Jim > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com To unsubscribe, > go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From imp at bsdimp.com Thu Jan 1 18:34:09 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu, 01 Jan 2009 11:34:09 -0700 (MST) Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: <20090101.112803.179959520.imp@bsdimp.com> References: <20090101.112803.179959520.imp@bsdimp.com> Message-ID: <20090101.113409.-961691822.imp@bsdimp.com> In message: <20090101.112803.179959520.imp at bsdimp.com> "M. Warner Losh" writes: : If POSIX had allowed for the system time to be TAI, and have the : offset applied for the display of times, then there would be no : ambiguity. However, this is not allowed because one must be able to : do math on time_t such that time_t % 86400 is midnight. time_t %86400 == 0 is midnight I should have said... Warner From wb6bnq at cox.net Thu Jan 1 18:39:37 2009 From: wb6bnq at cox.net (WB6BNQ) Date: Thu, 01 Jan 2009 10:39:37 -0800 Subject: [time-nuts] Lady Heather's Leap Log References: Message-ID: <495D0DE9.CD97630E@cox.net> Mark, First, I do not like Billy Gate either. But I find your insistence that all you have is HOTMAIL for your email facilities a bit disingenuous. Your message header indicates you are getting to the WEB through Southwest Bell, a division of AT&T Internet services. If that is correct, then you have the ability to have a normal Email service account through AT&T. So my question is why are you restricting yourself to such limited means as WEB mail ? Particularly when better processes are available no matter how F-upped Billy G and Microsoft are. Bill....WB6BNQ Mark Sims wrote: > All the CR/LF strangeness that I have been having are absolutely positively Microsoft's fault. Hotmail is a web based email. You enter your text in a standard web form. Words wrap at the right margin. When you get to the end of a paragraph you press RETURN to start a new paragraph and RETURN RETURN to start a new paragraph with a blank line between them. This is the way every web form works. And it is the way Hotmail has worked for the last 10+ years. > > A couple months ago, Billy G decided to pimp out the Hotmail user interface and in usual Microsoft style totally screwed things up. Besides requiring three times as many clicks to log in, many features either do not work or mess up. The paragraph/RETURN thing is just one. Sometimes you get your paragraph/spacing, other times you don't. Sometimes a button works, sometimes it don't. Sometimes you can log in, sometimes you don't. Sometimes it locks up, sometimes it don't. This occurs with both Firefox and Safari. I don't use Internet Exploder. I doubt that problems that are as apparent as these would have gone unnoticed and unfixed... I can only assume the Microsoft has yet again intentionally hobbled a product so that it does not work with competitors products/browsers. Luckily Hotmail is the sole Microsoft product that I have to use. > _________________________________________________________________ > Life on your PC is safer, easier, and more enjoyable with Windows Vista?. > http://clk.atdmt.com/MRT/go/127032870/direct/01/ > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From akbiocca at comcast.net Thu Jan 1 18:47:45 2009 From: akbiocca at comcast.net (Alan Biocca) Date: Thu, 1 Jan 2009 10:47:45 -0800 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: <50B3BAE5E2BC47E2AF56372625FCF0E5@didierhp> References: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> <50B3BAE5E2BC47E2AF56372625FCF0E5@didierhp> Message-ID: Seems to me that CR CR LF was often used to leave a bit more time. Was a long time ago, but we were very young then :) -- Alan, wb6zqz On Thu, Jan 1, 2009 at 10:32 AM, Didier wrote: > The reason for CR/LF is that CR takes a while on a teletype, while LF is > fast, so sending both allowed enough time for the paper/print head to be in > the right place before printing the next char. If you sent LF/CR on a > teletype instead of CR/LF, you could see right away the reason :-) > > Didier > > PS: while writing this, I suddenly realized that it really dates me, > doesn't > it? > > > -----Original Message----- > > From: time-nuts-bounces at febo.com > > [mailto:time-nuts-bounces at febo.com] On Behalf Of Lux, James P > > Sent: Thursday, January 01, 2009 10:10 AM > > To: Discussion of precise time and frequency measurement > > Subject: Re: [time-nuts] Lady Heather's Leap Log > > > > > > > > > > On 12/31/08 6:06 PM, "Steve Rooke" wrote: > > > > > 2009/1/1 Mark Sims : > > >> > > >> Note that there is an error in the first column heading in Lady > > >> Heather's Leap Log. It says UTC... should be GPS. The > > three line > > >> hour timestamp comment is correct (UTC). The distributed > > version of > > >> the program logged only time-of-week. I added the > > HH:MM:SS yesterday > > >> but messed up the column header (boy is Lady Heather gonna be mad > > >> when She finds out). The random spacing is due to Billy Gates > > >> Quality Control... he still can't figure out where to put > > CRs and LFs in an email... > > > > > > Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge > > > his bets with both LF and CR. It's little wonder I always > > get a lot of > > > double spacing here then :-) > > > > > > > Hardly microsoft's fault. Blame the teletype. Or perhaps DEC. > > RT-11 stored CR/LF in files, and CP/M adopted that > > convention, followed by DOS, etc. > > I imagine RT-11 did CR/LF because > > A) it allows use of unmodified KSR/ASR 33 TTYs without having > > to worry if the user has the autoLF option > > B) with ink on paper, the ability to do overprints (CR w/o > > LF) is actually useful. Them newfangled CRT based terminals > > can't do this (except for the Tek 401x series) > > > > > > Jim > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com To unsubscribe, > > go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From james.p.lux at jpl.nasa.gov Thu Jan 1 19:02:17 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 1 Jan 2009 11:02:17 -0800 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: <495CF149.5000500@erols.com> Message-ID: On 1/1/09 8:37 AM, "Chuck Harris" wrote: > Lux, James P wrote: > > > The fault was in the thinking that there would never be more than one or > two terminal types used as consoles and I/O devices, so the applications > programs should handle I/O directly. > > That fault was fixed once and for all with unix's termcap... the idea that > the driver should present as common as possible of an interface to the > application. MSDOS was a microcomputer OS and inherited most of the features of other microcomputer OSes at the time. Termcap was a royal pain in the rear to deal with, and consumed significant (scarce) resources on machines where 32K of RAM was the whole load. I can't fault MS for the choice they made back then. And, in a small resource system that's talking to a glass TTY as a console, why not just code for what's out there. (after all, all you had between your application and the hardware was a BIOS call.. CP/M provided almost nothing between file and console, e.g. PIP) Granted, by the time they were building "real" operating systems (say, from NT onwards) they should and did have a more sophisticated scheme. But by that time, lots of folks had invested in compatibility with the earlier MSDOS,CP/M style stuff. And, besides, MS was already heading towards windowing environments where the OS would manage the video display directly with bitblts etc, rather than worrying about supporting hundreds of different serial console hardware and terminals. I remember looking at various Unix implementations in the mid 80s for microcomputers (remember Charles River Data Systems, for example), as well as Unix-like implementations (Cromix).. My roommate at the time was toiling on 68k systems, including porting the original SUN workstation stuff to another 68k platform, and I well remember his comments that the curses package (which uses termcap) was well named. I think there were also some licensing/copyright issues with the plethora of Unixes around at the time. > > MS had ample opportunity to follow that example, as it was well established > back in the early 1970's. They chose instead to reinvent the wheel, and > ignore > most of the advances that came before them. Not really.. I'd venture that MS has NEVER aimed their OS towards supporting serial consoles in any serious manner, so why would they care about termcap and all it's associated cruft. They've always worked in terms of a memory mapped display of some sort (viz the horrible serial port support in the IBM PC BIOS and Int14 in MS-DOS). > > They still do. As do lots of other folks. You choose what works for you in your situation as you have it. Sometimes, a Unix derivative works best, other times, something else does. > > -Chuck Harris > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From warrensjmail-one at yahoo.com Thu Jan 1 19:17:08 2009 From: warrensjmail-one at yahoo.com (WarrenS) Date: Thu, 1 Jan 2009 11:17:08 -0800 Subject: [time-nuts] Count up/down DAC circuit References: <1231b6a80812302031j76fec7bt664e6d67c573d932@mail.gmail.com> Message-ID: <005401c96c45$8ae97a30$6401a8c0@WSOffice> Steve Here is another opinion to help add to your choices. The hunting problem is EASY to fix many different ways. It is basically done by anticipating what is going to happen next. If it is done wrong It would indeed: "exasperate any problems trying to lock a fast moving oxco or achieving lock in the first place" If done correct, that does not need to be an issue. To do it 'right' may not be easer to implement than something with a dead-zone BUT more accurate. As far "As for achieving lock in the first place with this idea" This need not be a big issue, It needs to only depend on what the uncertainty of the 1PPS sync signal is, so as not to resync on the wrong clock. That is max Jitter plus the down time phase error time. As far as down time hold-over, It need not be a big problem as long as you have something in there that is digital such as the DAC. Just detect the fact that the GPS is down someway and shut down the Dac updates, but don't try to use an analog holdover circuit if you want to hold more than a few minutes. And I must agree mostly with what "Said" said: "implementing a standard PI controller (in a micro etc), and calculating it's stability etc is much easier than getting this to work properly" That is it is easier IF you are good at using micro's, mostly because that is the way it is usually done. If you don't or can't use a micro, then its easier to do it without one. The real problem is just how do you get an accurate signal to lock on to in the first place? WarrenS *************** ----- Original Message ----- From: "Steve Rooke" To: "Discussion of precise time and frequency measurement" Sent: Tuesday, December 30, 2008 8:31 PM Subject: Re: [time-nuts] Count up/down DAC circuit > Hi Said, > > Yes, I could see that my idea would suffer from this hunting in the > locked state problem an was wondering if this could be perhaps 'cured' > with a simple low-pass filter stage between the count up/down DAC and > the EFC, IE, the DAC would hunt up and down with a duty cycle equal to > the difference between the two DAC levels filtered by the LPF, thereby > giving a constant frequency. > > This, of course, would further exasperate any problems trying to lock > a fast moving oxco or achieving lock in the first place. Some tuning > of the LPF time constant would be required to stop ringing as the PLL > moved into lock. > > Do you think that would work as it would probably be easier to > implement than something to implement a dead-zone? > > As for achieving lock in the first place with this idea, I'm thinking > now that it could take a very lon time for the DAC to count up/down > with output from a phase detector at 1PPS. I was really only thinking > about this whole idea as it seemed to be a natural to hold the EFC > voltage during lack of PPS if the GPS goes down. Without the PPS, the > phase detector will output no pulses so the DAC would remain frozen in > it's last state. Implementing a GPSDO via a phase detector followed by > a LPF would obviously be easier but in the absence of the PPS, I > imagine that leakage in the circuit would make the EFC voltage drift. > I guess I could buffer it with a source-follower or something like > that, or perhaps some form of sample and hokld circuit. > > I was just bouncing around ideas as I know there are a lot of great > brains on this list. > > 73, Steve > > 2008/12/31 : >> Hi Steve, >> >> I played with such a circuit a long time ago. >> >> The slope is limited to the clocking of your circuit (one LSB digit per >> clock typ), which can present an issue if you cannot follow the OCXO's EFC >> changes fast enough. You could be chasing the OCXO voltage and this may lead to >> instability. >> >> Even if it is "locked", the circuit will constantly be "chasing" the OCXO, >> unless you implement a dead-zone where the circuit stops counting up/down when >> you are close enough to your target frequency. >> >> This chasing may cause the frequency to modulate up and down, and could lead >> to large-scale oscillations. >> >> Tough to get this to work properly, but with circuitry to add a deadzone, >> and to dampen the lock, and maybe to introduce gain (jump more than one LSB when >> far off etc) it may work. Then again implementing a standard PI controller >> (in a micro etc), and calculating it's stability etc is much easier than >> getting this to work properly. >> >> bye, >> Said >> >> >> In a message dated 12/29/2008 21:30:54 Pacific Standard Time, >> sar10538 at gmail.com writes: >> >> As part of the current idea I have with the hockey-pucks, I'm thinking >> about feeding the D1 and U1 phase difference pulses out of an MC4044 >> out to some circuit that could clock up and down an analog output >> which would ultimately go to the EFC of a ocxo, IE D1 pulses when the >> phase of one input signal is advanced and visa versa for the U1 pin. >> Anyone seen a circuit like that please? >> >> Thanks & 73, Steve >> -- >> Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW >> Omnium finis imminet >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > > > -- > Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW > Omnium finis imminet > > > From holrum at hotmail.com Thu Jan 1 19:20:00 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 19:20:00 +0000 Subject: [time-nuts] Another LPRO-101 Rb Osc question... In-Reply-To: References: Message-ID: Do NOT drill, distort, or otherwise manipulate the LPRO case. It is actually a mu-metal magnetic shield. These are fabricated and then specially annealed. If you bend it, etc you can destroy the shielding properties. If you want to mount a terminal strip, etc to the case use something like double sided tape. The case top does just snap onto the base. Remove the hex jack screws on the interface connector. Gently pry the top cover off... beware of the above warning. It is very easy to bend the case getting it off. Yes, the rubbery film on the bottom of the case is a silicone rubber heat transfer pad. If you mess yours up you can use regular heat sink grease (well known for mysteriously coating everything within a 10 foot radius with white goo once you open the container) ----------------- I would like to place a small terminal strip on the top of the case with an RF connector and some easy/convenient connection lugs for power and monitoring, etc. _________________________________________________________________ It?s the same Hotmail?. If by ?same? you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008 From james.p.lux at jpl.nasa.gov Thu Jan 1 19:21:04 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 1 Jan 2009 11:21:04 -0800 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: <50B3BAE5E2BC47E2AF56372625FCF0E5@didierhp> Message-ID: On 1/1/09 10:32 AM, "Didier" wrote: > The reason for CR/LF is that CR takes a while on a teletype, while LF is > fast, so sending both allowed enough time for the paper/print head to be in > the right place before printing the next char. If you sent LF/CR on a > teletype instead of CR/LF, you could see right away the reason :-) > > Didier > > PS: while writing this, I suddenly realized that it really dates me, doesn't > it? > Only if you're generating the 50/60 Hz for your TTYs synchronous motor from dividing down your 10 MHz house standard... A new timenuts thing... Does the slight frequency error from an integer division from 10MHz to 60.00024 affect the CR/LF timing... Clearly, the folks using 50Hz and the corresponding gearing in the TTY have it better, because it's an exact division. From holrum at hotmail.com Thu Jan 1 19:29:59 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 19:29:59 +0000 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: Message-ID: I use web based email services for two main reasons. First is that I know I can (and do) access my email from anywhere in the world . Second is that it does not lock me into a particular ISP. I am currently using SBC DSL for my home internet access. Like every broadband supplier, they keep raising their rates thinking that you will either not notice or that switching to a new supplier (and having to change email addresses) is too much of a hassle. The next time SBC attempts to raise my rates, they lose me as a customer and I switch to a different supplier and the cycle repeats. I have had the same Hotmail addresses for over 10 years... makes it easy for people to keep in touch. Yes, I could get my own domain name and set up a permanent email address that way, but that can make reason #1 more difficult. ---------- So my question is why are you restricting yourself to such limited means as WEB mail ? _________________________________________________________________ It?s the same Hotmail?. If by ?same? you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008 From phk at phk.freebsd.dk Thu Jan 1 19:47:05 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 01 Jan 2009 19:47:05 +0000 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: Your message of "Thu, 01 Jan 2009 11:21:04 PST." Message-ID: <58522.1230839225@critter.freebsd.dk> In message , "Lux, James P" writes: >A new timenuts thing... Does the slight frequency error from an integer >division from 10MHz to 60.00024 [...] Real timenuts use a synthesizer or PLL to get the correct 60.00... Hz :-) (See Toms nixe-clock :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From joegwinn at comcast.net Thu Jan 1 19:57:11 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Thu, 1 Jan 2009 14:57:11 -0500 Subject: [time-nuts] Leap seconds and POSIX Message-ID: Warner, At 6:35 PM +0000 1/1/09, time-nuts-request at febo.com wrote: > >Message: 6 >Date: Thu, 01 Jan 2009 11:28:03 -0700 (MST) >From: "M. Warner Losh" >Subject: Re: [time-nuts] Leap seconds and POSIX >To: time-nuts at febo.com, joegwinn at comcast.net >Message-ID: <20090101.112803.179959520.imp at bsdimp.com> >Content-Type: Text/Plain; charset=us-ascii > >In message: > Joe Gwinn writes: >: Having worked in the POSIX committee for many years, I can shed some >: light on how POSIX handles leap seconds: >: >: In short, POSIX adamantly ignores leap seconds. All days in POSIX >: have the same length, 86,400 seconds. >: >: This omission is not by accident, instead having been violently >: debated at length, and voted upon. >: >: The rationale is that one cannot assume that all POSIX systems have >: access to leap second information, or even the correct time, and yet >: must work in a reasonable manner. In particular, file modification >: timestamps must allow one to determine causal order (to within one >: second in the old days) by comparison of timestamps. (Yes, people do >: realize that timestamps are not the perfect way to establish causal >: order, but are nonetheless widely used in non-critical applications. >: Critical applications instead use some kind of atomic sequence-number >: scheme.) > >If POSIX had allowed for the system time to be TAI, and have the >offset applied for the display of times, then there would be no >ambiguity. However, this is not allowed because one must be able to >do math on time_t such that time_t % 86400 is midnight. Defining a formal equivalence of some kind to TAI was proposed, but was not accepted, largely because they had were not linked at the beginning, and there would be many details that were not quite right. >: So, at least in theory, POSIX time is a form of TAI, having a >: constant offset from TAI. > >Except that the offset isn't constant :(. True, as discussed next. >: In practice, in platforms that have access to GPS, NTP is used to >: servo the local computer clock into alignment with UTC (or GPS System >: Time (UTC without the accumulated leaps) in systems that abhor time >: steps), and there is a transient error just after a leap second while >: NTP recovers. > >When the INS bit is set in the NTP packets, NTP tells the kernel about >it, which replays the last second of the day to keep in step. I'm not >sure this is a transient error or not, since ntp_gettime can be used >to determine that this is the leap second for applications that care. >However, it does introduce a glitch in the data produced by system >interfaces that don't have leap second indicators... Platforms vary because NTP is at the mercy of the kernel developers. From the standpoint of the average user, there is a transient error. Not that many average users will notice, so long as nothing crashes or hangs. In systems where the transient error and possibility of a crash or hang cannot be tolerated, one common dodge is to lie to NTP by configuring the GPS receiver and NTP timeserver to emit GPS System Time, and live with the fact that the local computer clocks are ~14+ seconds off of UTC. Purpose-built user displays are programmed to compute and use the correct time. Joe From phk at phk.freebsd.dk Thu Jan 1 20:03:14 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 01 Jan 2009 20:03:14 +0000 Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: Your message of "Thu, 01 Jan 2009 14:57:11 EST." Message-ID: <58677.1230840194@critter.freebsd.dk> In message , Joe Gwinn writes: >Not that many average users will notice, so long as nothing crashes >or hangs. If the above statement reflects the POSIX attitude to operating system quality and reliability, then I understand, for the first time, how POSIX can contain so many mistakes, omissions and bad ideas usually terribly executed. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From hmurray at megapathdsl.net Thu Jan 1 20:20:15 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 01 Jan 2009 12:20:15 -0800 Subject: [time-nuts] Leap quirks Message-ID: <20090101202016.CAC11BCDA@ip-64-139-1-69.sjc.megapath.net> Two of my Linux systems hung. One was running a 2.6.25 kernel and one 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes on comp.protocols.time.ntp about Linux systems locking up. One said that it was a kernel bug in ntp.c but I haven't seen any details. My Garmin GPS 18x USB was off by a second for about 2.5 hours. I thought it had fixed itself, but it's still bouncing around between reasonably close and off by a second. I'll get a graph one of these days. (Poke me off list if you want to see it before I get around to it.) Hopefully it will fix itself soon. My 18 LVC and 18 USB (no x) both did the right thing. The 18x is the new version. Physically, it looks the same. The receiver is much more sensitive, but the timing has lots more jitter. [My 18x LVC died a while ago so I didn't get any leap data from it.] A couple of SiRF systems are off by a second now. These are the systems that got confused when the leap second announcement started back in Aug. http://www.megapathdsl.net/~hmurray/ntp/leap-gps2.gif They were clean for the first 18 hours of this year. Mumble. I'll have to wait for more data. -- These are my opinions, not necessarily my employer's. I hate spam. From didier at cox.net Thu Jan 1 21:12:36 2009 From: didier at cox.net (Didier) Date: Thu, 1 Jan 2009 15:12:36 -0600 Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: <58677.1230840194@critter.freebsd.dk> References: Your message of "Thu, 01 Jan 2009 14:57:11 EST." <58677.1230840194@critter.freebsd.dk> Message-ID: <1C1598944F0C49FB94B45173823E74C4@didierhp> > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Poul-Henning Kamp > Sent: Thursday, January 01, 2009 2:03 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Leap seconds and POSIX > > In message , Joe Gwinn writes: > > >Not that many average users will notice, so long as nothing > >crashes or hangs. > > If the above statement reflects the POSIX attitude to > operating system quality and reliability, then I understand, > for the first time, how POSIX can contain so many mistakes, > omissions and bad ideas usually terribly executed. > > Poul-Henning > I take this as being one user's pragmatic opinion, not a statement of policy. Not that I would disagree with you if it were. POSIX is like the government in a democracy: necessary evil. Didier From m0ycm at veenstras.com Thu Jan 1 21:34:19 2009 From: m0ycm at veenstras.com (Lester Veenstra) Date: Thu, 1 Jan 2009 21:34:19 -0000 Subject: [time-nuts] Lady Heather's Leap Log In-Reply-To: References: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> Message-ID: And at full CR/LF has been standard practice on mechanical printers (teleprinters) from the beginning, to give the carriage time to return to the left position. Otherwise, you can wind up with the first character of the new line being printed in the middle of the line, as it tried to print with the carriage in flight to the starting position. Lester B Veenstra M?YCM K1YCM lester at veenstras.com m0ycm at veenstras.com k1ycm at veenstras.com US Postal Address: PSC 45 Box 781 APO AE 09468 USA UK Postal Address: Dawn Cottage Norwood, Harrogate HG3 1SD, UK Telephones: Office: +44-(0)1423-846-385 Home: +44-(0)1943-880-963 Guam Cell: +1-671-788-5654 UK Cell: +44-(0)7716-298-224 US Cell: +1-240-425-7335 Jamaica: +1-876-352-7504 This e-mail and any documents attached hereto contain confidential or privileged information. The information is intended to be for use only by the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail or any documents attached hereto is prohibited. -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Lux, James P Sent: Thursday, January 01, 2009 4:10 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Lady Heather's Leap Log On 12/31/08 6:06 PM, "Steve Rooke" wrote: > 2009/1/1 Mark Sims : >> >> Note that there is an error in the first column heading in Lady Heather's >> Leap Log. It says UTC... should be GPS. The three line hour timestamp >> comment is correct (UTC). The distributed version of the program logged only >> time-of-week. I added the HH:MM:SS yesterday but messed up the column header >> (boy is Lady Heather gonna be mad when She finds out). The random spacing is >> due to Billy Gates Quality Control... he still can't figure out where to put >> CRs and LFs in an email... > > Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge > his bets with both LF and CR. It's little wonder I always get a lot of > double spacing here then :-) > Hardly microsoft's fault. Blame the teletype. Or perhaps DEC. RT-11 stored CR/LF in files, and CP/M adopted that convention, followed by DOS, etc. I imagine RT-11 did CR/LF because A) it allows use of unmodified KSR/ASR 33 TTYs without having to worry if the user has the autoLF option B) with ink on paper, the ability to do overprints (CR w/o LF) is actually useful. Them newfangled CRT based terminals can't do this (except for the Tek 401x series) Jim _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From holrum at hotmail.com Thu Jan 1 22:01:34 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 1 Jan 2009 22:01:34 +0000 Subject: [time-nuts] Leap quirks In-Reply-To: References: Message-ID: My friend has a sealed GPS puck made by what looks like "GreenLeaf" (apparently an anonymous Chinese company). It totally locked up at leap time. It had to be power cycled to resume operations. Unknown as to what's inside the puck. Voltage in, RS-232 out. He is thinking that it is still a second off. _________________________________________________________________ Life on your PC is safer, easier, and more enjoyable with Windows Vista?. http://clk.atdmt.com/MRT/go/127032870/direct/01/ From stanley_reynolds at yahoo.com Thu Jan 1 22:05:36 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Thu, 1 Jan 2009 14:05:36 -0800 (PST) Subject: [time-nuts] Lady Heather's Leap Log References: <1231b6a80812311806k65d8ce94q6c053200eeea0ca2@mail.gmail.com> Message-ID: <40356.79418.qm@web30302.mail.mud.yahoo.com> At 110 baud the ASR-33 needed a null charter or two as well or you would get the first two charters on top of each other. So it was CR,LF,Null,Null. Stanley http://www.pdp8.net/asr33/asr33.shtml ________________________________ From: Lester Veenstra To: Discussion of precise time and frequency measurement Sent: Thursday, January 1, 2009 4:34:19 PM Subject: Re: [time-nuts] Lady Heather's Leap Log And at full CR/LF has been standard practice on mechanical printers (teleprinters) from the beginning, to give the carriage time to return to the left position. Otherwise, you can wind up with the first character of the new line being printed in the middle of the line, as it tried to print with the carriage in flight to the starting position. Lester B Veenstra M?YCM K1YCM lester at veenstras.com m0ycm at veenstras.com k1ycm at veenstras.com US Postal Address: PSC 45 Box 781 APO AE 09468 USA UK Postal Address: Dawn Cottage Norwood, Harrogate HG3 1SD, UK Telephones: Office: +44-(0)1423-846-385 Home: +44-(0)1943-880-963 Guam Cell: +1-671-788-5654 UK Cell: +44-(0)7716-298-224 US Cell: +1-240-425-7335 Jamaica: +1-876-352-7504 This e-mail and any documents attached hereto contain confidential or privileged information. The information is intended to be for use only by the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail or any documents attached hereto is prohibited. -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Lux, James P Sent: Thursday, January 01, 2009 4:10 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Lady Heather's Leap Log On 12/31/08 6:06 PM, "Steve Rooke" wrote: > 2009/1/1 Mark Sims : >> >> Note that there is an error in the first column heading in Lady Heather's >> Leap Log. It says UTC... should be GPS. The three line hour timestamp >> comment is correct (UTC). The distributed version of the program logged only >> time-of-week. I added the HH:MM:SS yesterday but messed up the column header >> (boy is Lady Heather gonna be mad when She finds out). The random spacing is >> due to Billy Gates Quality Control... he still can't figure out where to put >> CRs and LFs in an email... > > Well, POSIX decided on LF, Mac on CR and Billy Boy decided to hedge > his bets with both LF and CR. It's little wonder I always get a lot of > double spacing here then :-) > Hardly microsoft's fault. Blame the teletype. Or perhaps DEC. RT-11 stored CR/LF in files, and CP/M adopted that convention, followed by DOS, etc. I imagine RT-11 did CR/LF because A) it allows use of unmodified KSR/ASR 33 TTYs without having to worry if the user has the autoLF option B) with ink on paper, the ability to do overprints (CR w/o LF) is actually useful. Them newfangled CRT based terminals can't do this (except for the Tek 401x series) Jim _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From iovane at inwind.it Thu Jan 1 22:44:41 2009 From: iovane at inwind.it (iovane at inwind.it) Date: Thu, 1 Jan 2009 23:44:41 +0100 Subject: [time-nuts] Colima GPSDO stopped working? Message-ID: Perfect since I discovered it two months back, the online plot is no longer updated since this morning. http://resco.ucol.mx/Fury/gpsstat.htm Does anybody know what's happening? Thanks, Antonio I8IOV From ptdeboer at cs.utwente.nl Thu Jan 1 23:22:54 2009 From: ptdeboer at cs.utwente.nl (Pieter-Tjerk de Boer) Date: Fri, 2 Jan 2009 00:22:54 +0100 Subject: [time-nuts] leapsecond on long-, medium- and shortwave Message-ID: <20090101232254.GF30557@cs.utwente.nl> During the leap second, I recorded 6 parts of the radio spectrum, containing a few time and frequency stations, and a lot of AM broadcast stations. An analysis of these recordings is now here: http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/leapsecond-2008.html Out of 33 long- and mediumwave broadcasters that transmitted some sort of time signal (e.g., a few 1 kHz beeps near the top of the hour), only 17 got the leap second right. In fact, it turned out that several of the signals are not just off by the leapsecond, but by several seconds more. Also, many are off by a fraction of a second, presumably due to delays between the studio and the transmitter, e.g. via a satellite link. Regards, Pieter-Tjerk From iovane at inwind.it Thu Jan 1 23:43:50 2009 From: iovane at inwind.it (iovane at inwind.it) Date: Fri, 2 Jan 2009 00:43:50 +0100 Subject: [time-nuts] Another LPRO-101 Rb Osc question... Message-ID: These pictures could suggest an idea: http://fotoalbum.alice.it/iovane/LPRO Antonio I8IOV From tvb at LeapSecond.com Thu Jan 1 23:55:43 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Thu, 1 Jan 2009 15:55:43 -0800 Subject: [time-nuts] Motorola M12+T - On board oscillator phase noise specand/or part number References: Message-ID: <0D7331CE7C5E487B8FABE2B150220045@pc52> > Hi All, > > Has anyone been able to figure out the part number and/or measured the > phase noise of the quartz oscillator on board the Motorola M12+T? > > This will be an interesting figure to see. > > Regards, > > Stephan. This is an ADEV+MDEV plot for the 100 Hz output of an M12+ in free-run mode (no gps lock). http://www.leapsecond.com/pages/m12-adev/m12-free.gif If you want more data let me know. /tvb From garnere at gmail.com Fri Jan 2 00:22:40 2009 From: garnere at gmail.com (Eric Garner) Date: Thu, 1 Jan 2009 16:22:40 -0800 Subject: [time-nuts] Connector source for LPRO Rb oscillator...?? In-Reply-To: References: Message-ID: Winford Engineering seems to be the cheapest I've ever found: http://www.winfordeng.com/products/dsi.php this assumes that you have 10 (or more) conductor ribbon cable laying around -Eric On Wed, Dec 31, 2008 at 9:21 PM, Mark Sims wrote: > > Any standard 10 pin flat ribbon cable header will fit on the pins just fine. You can probably salvage one off an ancient PC motherboard serial port header to DB-9 type RS-232 connector cable. Or see Ebay item 350112294584. The same seller has shorter cables for less. Or search Ebay for "10 pin idc" (without the quotes). > _________________________________________________________________ > It's the same Hotmail(R). If by "same" you mean up to 70% faster. > http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008 > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- --Eric _________________________________________ Eric Garner From sar10538 at gmail.com Fri Jan 2 01:00:56 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Fri, 2 Jan 2009 14:00:56 +1300 Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: References: Message-ID: <1231b6a80901011700xb3a1cffwe6cd13a3639be237@mail.gmail.com> 2009/1/2 Joe Gwinn : > Platforms vary because NTP is at the mercy of the kernel developers. > From the standpoint of the average user, there is a transient error. > Not that many average users will notice, so long as nothing crashes > or hangs. > > In systems where the transient error and possibility of a crash or > hang cannot be tolerated, one common dodge is to lie to NTP by > configuring the GPS receiver and NTP timeserver to emit GPS System > Time, and live with the fact that the local computer clocks are ~14+ > seconds off of UTC. Purpose-built user displays are programmed to > compute and use the correct time. Examples please. 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From SAIDJACK at aol.com Fri Jan 2 02:01:06 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Thu, 1 Jan 2009 21:01:06 EST Subject: [time-nuts] Count up/down DAC circuit Message-ID: Hi Steve, not sure if the LPF would help, some issues with analog sample and holds with long time-constants were recently discussed on this group. I am not a fan of these to implement a GPSDO loop. I guess it depends on your dac steps too. If you have a 16 bit dac over a 5V EFC, then you have +/-32K steps, or 32K seconds to adjust.That's a very slow slope. Also, take into consideration that the GPS and the OCXO will "jump" over the course of a typical day, and you need to track these jumps. Your tracking speed may not be fast enough here. Our best double-oven OCXO's still have ~+/-50 microvolt variations, and a typical single oven may have +/-15mV variations over a 24 hour period. If you don't have enough resolution, you will unnecessarily introduce quantization noise, and if you do you would be lagging behind these natural changes. What would probably work is if you over-sample the counter circuit to say 100x to 1000x (or in other words being able to take 100 to 1000 LSB steps per second). That may prove to work out ok, and give you enough DAC resolution and DAC speed. With an M12+ set to 100PPS you may just make this work well enough! My gut feeling is it won't work with 1PPS, but may work with 100PPS. And if your DAC LSB step is very small, say 5E-013, then your tracking noise would be quite small. Let's see, 100 steps per second, at 5E-13 per step would give you a tracking speed of 5E-011 per second. That's probably good enough. A typical crystal jump of ~1E-09 would thus take only 20 seconds to correct. Sounds reasonable to me. Note that this is a frequency locked loop rather than a phase locked loop. Let me know if you try it, and if you get it to work. bye, Said In a message dated 12/30/2008 20:32:50 Pacific Standard Time, sar10538 at gmail.com writes: Hi Said, Yes, I could see that my idea would suffer from this hunting in the locked state problem an was wondering if this could be perhaps 'cured' with a simple low-pass filter stage between the count up/down DAC and the EFC, IE, the DAC would hunt up and down with a duty cycle equal to the difference between the two DAC levels filtered by the LPF, thereby giving a constant frequency. This, of course, would further exasperate any problems trying to lock a fast moving oxco or achieving lock in the first place. Some tuning of the LPF time constant would be required to stop ringing as the PLL moved into lock. Do you think that would work as it would probably be easier to implement than something to implement a dead-zone? As for achieving lock in the first place with this idea, I'm thinking now that it could take a very lon time for the DAC to count up/down with output from a phase detector at 1PPS. I was really only thinking about this whole idea as it seemed to be a natural to hold the EFC voltage during lack of PPS if the GPS goes down. Without the PPS, the phase detector will output no pulses so the DAC would remain frozen in it's last state. Implementing a GPSDO via a phase detector followed by a LPF would obviously be easier but in the absence of the PPS, I imagine that leakage in the circuit would make the EFC voltage drift. I guess I could buffer it with a source-follower or something like that, or perhaps some form of sample and hokld circuit. I was just bouncing around ideas as I know there are a lot of great brains on this list. 73, Steve 2008/12/31 : > Hi Steve, > > I played with such a circuit a long time ago. > > The slope is limited to the clocking of your circuit (one LSB digit per > clock typ), which can present an issue if you cannot follow the OCXO's EFC > changes fast enough. You could be chasing the OCXO voltage and this may lead to > instability. > > Even if it is "locked", the circuit will constantly be "chasing" the OCXO, > unless you implement a dead-zone where the circuit stops counting up/down when > you are close enough to your target frequency. > > This chasing may cause the frequency to modulate up and down, and could lead > to large-scale oscillations. > > Tough to get this to work properly, but with circuitry to add a deadzone, > and to dampen the lock, and maybe to introduce gain (jump more than one LSB when > far off etc) it may work. Then again implementing a standard PI controller > (in a micro etc), and calculating it's stability etc is much easier than > getting this to work properly. > > bye, > Said > > > In a message dated 12/29/2008 21:30:54 Pacific Standard Time, > sar10538 at gmail.com writes: > > As part of the current idea I have with the hockey-pucks, I'm thinking > about feeding the D1 and U1 phase difference pulses out of an MC4044 > out to some circuit that could clock up and down an analog output > which would ultimately go to the EFC of a ocxo, IE D1 pulses when the > phase of one input signal is advanced and visa versa for the U1 pin. > Anyone seen a circuit like that please? > > Thanks & 73, Steve > -- > Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW > Omnium finis imminet > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From kc0ukk at msosborn.com Fri Jan 2 03:05:51 2009 From: kc0ukk at msosborn.com (Matt Osborn) Date: Thu, 01 Jan 2009 21:05:51 -0600 Subject: [time-nuts] Motorola M12+T - On board oscillator phase noise spec and/or part number In-Reply-To: References: Message-ID: The crystal on my M12+T is marked top to bottom: 32.768 KDS0530 I would imagine it is a custom device from KDS On Tue, 23 Dec 2008 11:06:30 +0200, "Stephan Sandenbergh" wrote: >Hi All, > >Has anyone been able to figure out the part number and/or measured the >phase noise of the quartz oscillator on board the Motorola M12+T? -- kc0ukk at msosborn dot com From magnus at rubidium.dyndns.org Fri Jan 2 08:35:59 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 02 Jan 2009 09:35:59 +0100 Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: References: Message-ID: <495DD1EF.7030904@rubidium.dyndns.org> Joe Gwinn skrev: > Having worked in the POSIX committee for many years, I can shed some > light on how POSIX handles leap seconds: > > In short, POSIX adamantly ignores leap seconds. All days in POSIX > have the same length, 86,400 seconds. > > This omission is not by accident, instead having been violently > debated at length, and voted upon. > > The rationale is that one cannot assume that all POSIX systems have > access to leap second information, or even the correct time, and yet > must work in a reasonable manner. In particular, file modification > timestamps must allow one to determine causal order (to within one > second in the old days) by comparison of timestamps. (Yes, people do > realize that timestamps are not the perfect way to establish causal > order, but are nonetheless widely used in non-critical applications. > Critical applications instead use some kind of atomic sequence-number > scheme.) > > So, at least in theory, POSIX time is a form of TAI, having a > constant offset from TAI. > > In practice, in platforms that have access to GPS, NTP is used to > servo the local computer clock into alignment with UTC (or GPS System > Time (UTC without the accumulated leaps) in systems that abhor time > steps), and there is a transient error just after a leap second while > NTP recovers. The problem with the POSIX time is that it can't be UTC but fails to identify itself as either TAI, UT1 or even UT2. If it clearly identified itself as being one of those, or similar (say GPS time) then things would be much improved. However, it is being interprented as being UTC which it fails to handle. I think the UT1 and UT2 alternatives would be best suited. I don't mind that the default time in POSIX remains there, but I don't think it helps that there is no way to get propper UTC time by a standardized interface. Attempting to say "It's UTC, except on leap seconds" is not a workable solution if you are locked up and a leap-second do occur. It only works if you are not locked up and free runs on whatever you have. However, more and more systems actually needs to be locked up and they may also need to have propper UTC. We see needs to have logs in UTC and coordinated over many countries and time-zones. This is not only a matter of how we deal with leap-seconds, but how we deal with time. We need to be able to actually deal with propper UTC regardless, and we need to know it is UTC "traceable" (in a wider sense most of the time, but occasionally in propper sense) or not. I find the current situation unsatisfactory. Cheers, Magnus From magnus at rubidium.dyndns.org Fri Jan 2 08:45:23 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 02 Jan 2009 09:45:23 +0100 Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: References: Message-ID: <495DD423.6040903@rubidium.dyndns.org> >> : In practice, in platforms that have access to GPS, NTP is used to >> : servo the local computer clock into alignment with UTC (or GPS System >> : Time (UTC without the accumulated leaps) in systems that abhor time >> : steps), and there is a transient error just after a leap second while >> : NTP recovers. >> >> When the INS bit is set in the NTP packets, NTP tells the kernel about >> it, which replays the last second of the day to keep in step. I'm not >> sure this is a transient error or not, since ntp_gettime can be used >> to determine that this is the leap second for applications that care. >> However, it does introduce a glitch in the data produced by system >> interfaces that don't have leap second indicators... > > Platforms vary because NTP is at the mercy of the kernel developers. > From the standpoint of the average user, there is a transient error. > Not that many average users will notice, so long as nothing crashes > or hangs. For many of the places where POSIX is being used these days, this kind of reasoning is not helpful to say the least. For instance, it is being used in many systems where high availability as well as propper logging is concerned. In addition to that, UTC may very well be the time-scale of choice, thought TAI could be used if properly identified as such. If POSIX standard time where TAI and NTP was steering it as TAI in all the boxes, then things would work. We would need to convert into UTC and then into local time-zone as part of presentation. If POSIX standard time where UTC and NTP was steering it as UTC in all the boxes, then things would work. We would need to convert into local time-zone as part of presentation. Oh, time-zone is a presentation issue and not a "box" issue. Cheers, Magnus From joegwinn at comcast.net Fri Jan 2 16:31:51 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Fri, 2 Jan 2009 11:31:51 -0500 Subject: [time-nuts] Leap seconds and POSIX Message-ID: Steve, At 8:39 AM +0000 1/2/09, time-nuts-request at febo.com wrote: > >Message: 6 >Date: Fri, 2 Jan 2009 14:00:56 +1300 >From: "Steve Rooke" >Subject: Re: [time-nuts] Leap seconds and POSIX >To: "Discussion of precise time and frequency measurement" > > >2009/1/2 Joe Gwinn : > >> Platforms vary because NTP is at the mercy of the kernel developers. >> From the standpoint of the average user, there is a transient error. >> Not that many average users will notice, so long as nothing crashes >> or hangs. >> >> In systems where the transient error and possibility of a crash or >> hang cannot be tolerated, one common dodge is to lie to NTP by >> configuring the GPS receiver and NTP timeserver to emit GPS System >> Time, and live with the fact that the local computer clocks are ~14+ >> seconds off of UTC. Purpose-built user displays are programmed to >> compute and use the correct time. > >Examples please. Examples of what? The systems of my direct experience are radars and the like. Such systems always include trackers, and having a time step or a re-lived second can really destabilize things. To avoid all such problems, one common approach is to create a uniform and smooth timescale for use by the radar software. This was done long before GPS was invented, or NTP for that matter. Now days, the same smooth and uniform timescale is often implemented using a GPS receiver set to emit GPS System Time and NTP to distribute this time to the rest of the radar system. Joe From joegwinn at comcast.net Fri Jan 2 16:45:54 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Fri, 2 Jan 2009 11:45:54 -0500 Subject: [time-nuts] Leap seconds and POSIX Message-ID: Magnus, At 8:39 AM +0000 1/2/09, time-nuts-request at febo.com wrote: > >Message: 9 >Date: Fri, 02 Jan 2009 09:35:59 +0100 >From: Magnus Danielson >Subject: Re: [time-nuts] Leap seconds and POSIX >To: Discussion of precise time and frequency measurement > >Message-ID: <495DD1EF.7030904 at rubidium.dyndns.org> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Joe Gwinn skrev: >> Having worked in the POSIX committee for many years, I can shed some >> light on how POSIX handles leap seconds: >> >> In short, POSIX adamantly ignores leap seconds. All days in POSIX >> have the same length, 86,400 seconds. >> >> This omission is not by accident, instead having been violently >> debated at length, and voted upon. >> >> The rationale is that one cannot assume that all POSIX systems have >> access to leap second information, or even the correct time, and yet >> must work in a reasonable manner. In particular, file modification >> timestamps must allow one to determine causal order (to within one >> second in the old days) by comparison of timestamps. (Yes, people do >> realize that timestamps are not the perfect way to establish causal >> order, but are nonetheless widely used in non-critical applications. >> Critical applications instead use some kind of atomic sequence-number >> scheme.) >> >> So, at least in theory, POSIX time is a form of TAI, having a >> constant offset from TAI. >> >> In practice, in platforms that have access to GPS, NTP is used to >> servo the local computer clock into alignment with UTC (or GPS System >> Time (UTC without the accumulated leaps) in systems that abhor time >> steps), and there is a transient error just after a leap second while >> NTP recovers. > >The problem with the POSIX time is that it can't be UTC but fails to >identify itself as either TAI, UT1 or even UT2. If it clearly identified >itself as being one of those, or similar (say GPS time) then things >would be much improved. However, it is being interprented as being UTC >which it fails to handle. I think the UT1 and UT2 alternatives would be >best suited. > >I don't mind that the default time in POSIX remains there, but I don't >think it helps that there is no way to get proper UTC time by a >standardized interface. Actually, this isn't quite true, as POSIX provides a standard (POSIX) Re: [time-nuts] Leap seconds and POSIX way to define non-standard (to POSIX) clocks. So, if a vendor felt the need, they could define and provide a real TAI clock for instance. That said, I don't know of anybody having done this, but I have not looked either. >Attempting to say "It's UTC, except on leap seconds" is not a workable >solution if you are locked up and a leap-second do occur. It only works >if you are not locked up and free runs on whatever you have. However, >more and more systems actually needs to be locked up and they may also >need to have propper UTC. We see needs to have logs in UTC and >coordinated over many countries and time-zones. > >This is not only a matter of how we deal with leap-seconds, but how we >deal with time. We need to be able to actually deal with propper UTC >regardless, and we need to know it is UTC "traceable" (in a wider sense >most of the time, but occasionally in propper sense) or not. There are something like 20 named timescales at the international level, most being paper clocks to be sure, but each has a purpose and a set of properties, and serves some need. By implication, there is no single One True Clock. A better way to approach this is to see that POSIX time is yet another timescale, with a purpose and a set of properties. >I find the current situation unsatisfactory. It is what it is. Computer platform vendors traditionally cared little about time, and about realtime. The rise of interest in audio and video media caused the vendors to become interested in realtime issues and performance, and thus indirectly about time. But only to the degree needed to support handling of such media. Joe From tvb at LeapSecond.com Fri Jan 2 16:57:57 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Fri, 2 Jan 2009 08:57:57 -0800 Subject: [time-nuts] Leap seconds and POSIX References: <495DD423.6040903@rubidium.dyndns.org> Message-ID: Hi Magnus, Joe, et al, Please move the "leap seconds and POSIX" thread over to the LEAPSECS list. /tvb From joegwinn at comcast.net Fri Jan 2 17:32:51 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Fri, 2 Jan 2009 12:32:51 -0500 Subject: [time-nuts] Leap seconds and POSIX Message-ID: Magnus, At 12:00 PM +0000 1/2/09, time-nuts-request at febo.com wrote: >Message: 1 >Date: Fri, 02 Jan 2009 09:45:23 +0100 >From: Magnus Danielson >Subject: Re: [time-nuts] Leap seconds and POSIX >To: Discussion of precise time and frequency measurement > > >>> : In practice, in platforms that have access to GPS, NTP is used to >>> : servo the local computer clock into alignment with UTC (or GPS System >>> : Time (UTC without the accumulated leaps) in systems that abhor time >>> : steps), and there is a transient error just after a leap second while >>> : NTP recovers. >>> >>> When the INS bit is set in the NTP packets, NTP tells the kernel about >>> it, which replays the last second of the day to keep in step. I'm not >>> sure this is a transient error or not, since ntp_gettime can be used >>> to determine that this is the leap second for applications that care. >>> However, it does introduce a glitch in the data produced by system >>> interfaces that don't have leap second indicators... >> >> Platforms vary because NTP is at the mercy of the kernel developers. >> From the standpoint of the average user, there is a transient error. >> Not that many average users will notice, so long as nothing crashes >> or hangs. > >For many of the places where POSIX is being used these days, this kind >of reasoning is not helpful to say the least. But is it correct? Remember, most people understand little and care less about time, except insomuch as it affects something they do care about. There has been a flurry of reports of leap-second induced failures on "comp.protocols.time.ntp". This is precisely why some systems must avoid UTC. >For instance, it is being used in many systems where high availability >as well as propper logging is concerned. In addition to that, UTC may >very well be the time-scale of choice, thought TAI could be used if >properly identified as such. In the financial and legal worlds, UTC is the standard choice, and many GPS receivers are purchased for legally-tracable timestamping. >If POSIX standard time were TAI and NTP was steering it as TAI in all >the boxes, then things would work. We would need to convert into UTC and >then into local time-zone as part of presentation. I recall Dave Mills discussing this as a possibility, but being unable to achieve it, for reasons I don't recall. >If POSIX standard time were UTC and NTP was steering it as UTC in all >the boxes, then things would work. We would need to convert into local >time-zone as part of presentation. > >Oh, time-zone is a presentation issue and not a "box" issue. There is also a move afoot to cease to have leap seconds , instead correcting UTC manually every ten or more years. If this were done, then UTC would become uniform and smooth, and the TAI possibility would be eclipsed. The first possible ITU vote on this would be at their 2010 meeting, the ITU isn't likely to approve something that large the first time, and the DoD proposes that the change not be effective before 2018 at the earliest. Ref: "Discontinuance of Leap Second Adjustments", John G. Grimes, Assistant [US] Secretary of Defense, Networks and Information Integration, 3 September 2008, 3 pages. Joe From hmurray at megapathdsl.net Fri Jan 2 19:22:52 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 02 Jan 2009 11:22:52 -0800 Subject: [time-nuts] Early leap from SiRF chipset, BU-353 Message-ID: <20090102192253.C3FE2BCDA@ip-64-139-1-69.sjc.megapath.net> The first column is MJD. The second column is seconds within that day. (I chopped off the right end to avoid line wrap.) 54831 86384.488 $GPRMC,235944.000,A,3726.0731,N,12212.2624,W,0.30, 54831 86385.489 $GPRMC,235945.000,A,3726.0738,N,12212.2624,W,0.45, 54831 86386.489 $GPRMC,235946.000,A,3726.0743,N,12212.2624,W,0.19, 54831 86387.493 $GPRMC,235946.000,A,3726.0749,N,12212.2625,W,0.13, 54831 86388.489 $GPRMC,235947.000,A,3726.0752,N,12212.2625,W,0.46, 54831 86389.489 $GPRMC,235948.000,A,3726.0758,N,12212.2624,W,1.10, It took me a while to figure out what was going on. I got confused when didn't see anything interesting at midnight. 23:59:46 is 14 seconds early. I guess they inserted the leap second at midnight GPS time rather than midnight UTC. -- These are my opinions, not necessarily my employer's. I hate spam. From phk at phk.freebsd.dk Fri Jan 2 19:52:34 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 02 Jan 2009 19:52:34 +0000 Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: Your message of "Fri, 02 Jan 2009 11:31:51 EST." Message-ID: <99172.1230925954@critter.freebsd.dk> In message , Joe Gwinn writes: >This was done long before GPS was invented, or NTP for that matter. You should check the age of NTP, it is one of the oldest protocols around being initially standardized in september 1985, but inhereting most of its features from "ICS" which were first standardized in RFC778 in April 1981. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From tvb at LeapSecond.com Fri Jan 2 20:13:32 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Fri, 2 Jan 2009 12:13:32 -0800 Subject: [time-nuts] GPS12 leap second error Message-ID: I was sent a NMEA log of a Garmin GPS12 (f/w 4.60) showing the strangest leap second trace yet. Has anyone else see this before? In the ~15 seconds below, note: - double 235957 - missing 235958 for the RMC sentence - no second 235960 for either sentence - strange 000059 for the BWC sentence - missing 000008 BWC sentence - gps lock lost from 235957 to 000043 $GPBWC,235955,,, $GPRMC,235955,A, $GPBWC,235956,,, $GPRMC,235956,A, $GPBWC,235957,,, $GPRMC,235957,A, $GPBWC,235957,,, $GPRMC,235957,V, $GPBWC,235958,,, $GPRMC,235959,V, $GPBWC,000059,,, $GPRMC,000000,V, $GPBWC,000000,,, $GPRMC,000001,V, $GPBWC,000001,,, $GPRMC,000002,V, $GPBWC,000002,,, $GPRMC,000003,V, $GPBWC,000003,,, $GPRMC,000004,V, $GPBWC,000004,,, $GPRMC,000005,V, $GPBWC,000005,,, $GPRMC,000006,V, $GPBWC,000006,,, $GPRMC,000007,V, $GPBWC,000007,,, $GPRMC,000008,V, $GPBWC,000009,,, $GPRMC,000009,V, $GPBWC,000010,,, $GPRMC,000010,V, What a mess. /tvb From magnus at rubidium.dyndns.org Fri Jan 2 22:34:04 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 02 Jan 2009 23:34:04 +0100 Subject: [time-nuts] Leap seconds and POSIX In-Reply-To: <99172.1230925954@critter.freebsd.dk> References: <99172.1230925954@critter.freebsd.dk> Message-ID: <495E965C.6060709@rubidium.dyndns.org> Poul-Henning Kamp skrev: > In message , Joe Gwinn writes: > >> This was done long before GPS was invented, or NTP for that matter. > > You should check the age of NTP, it is one of the oldest protocols > around being initially standardized in september 1985, but inhereting > most of its features from "ICS" which were first standardized in > RFC778 in April 1981. > The first GPS Block I bird flew in 1978, but the project had been ongoing for considerable time. The GPS time coincided with UTC at 6 Jan 1980. Regardless, it is meaningless to even attempt to play the "I was here first" game. Now, let's take this elsewhere, OK? Cheers, Magnus From msa at latt.net Fri Jan 2 22:47:19 2009 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 2 Jan 2009 22:47:19 +0000 Subject: [time-nuts] GPS12 leap second error In-Reply-To: References: Message-ID: <20090102224719.GJ89298@mx1.latt.net> On Fri, Jan 02, 2009 at 12:13:32PM -0800, Tom Van Baak wrote: > I was sent a NMEA log of a Garmin GPS12 (f/w 4.60) showing > the strangest leap second trace yet. Has anyone else see this > before? In the ~15 seconds below, note: > > - double 235957 > - missing 235958 for the RMC sentence > - no second 235960 for either sentence > - strange 000059 for the BWC sentence > - missing 000008 BWC sentence > - gps lock lost from 235957 to 000043 Tom, Keep in mind the GPS12 (and I still have mine) is about 12-13 years old, and was a handheld navigational receiver. No mapping support, no timing support, no WAAS, no DGPS, proprietary Garmin serial + power connector on the back. It's a very basic receiver. It was never, ever intended to be used for timing, and attempting to use it for such results in amusement. I agree the behavior is very odd indeed, so yes, it's an oversight on their part, but I'm not surprised. I didn't even bother to observe mine. --msa From ch at murgatroid.com Sat Jan 3 06:34:18 2009 From: ch at murgatroid.com (christopher hoover) Date: Fri, 2 Jan 2009 22:34:18 -0800 Subject: [time-nuts] Leap Quirks In-Reply-To: References: Message-ID: <00f201c96d6d$4e640390$eb2c0ab0$@com> Hal Murray wrote: > Two of my Linux systems hung. One was running a 2.6.25 kernel and one > 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes > on > comp.protocols.time.ntp about Linux systems locking up. One said that > it was > a kernel bug in ntp.c but I haven't seen any details. None of mine (many dozens) hung. This is typical: ch at snaggle:~$ uname -a Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC 2008 x86_64 GNU/Linux ch at snaggle:~$ dmesg | grep leap [844362.415072] Clock: inserting leap second 23:59:60 UTC ch at snaggle:~$ -ch From sar10538 at gmail.com Sat Jan 3 06:40:39 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Sat, 3 Jan 2009 19:40:39 +1300 Subject: [time-nuts] Leap Quirks In-Reply-To: <00f201c96d6d$4e640390$eb2c0ab0$@com> References: <00f201c96d6d$4e640390$eb2c0ab0$@com> Message-ID: <1231b6a80901022240n76d3ac3ew5f1121343f25996d@mail.gmail.com> 2009/1/3 christopher hoover : > Hal Murray wrote: >> Two of my Linux systems hung. One was running a 2.6.25 kernel and one >> 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes >> on >> comp.protocols.time.ntp about Linux systems locking up. One said that >> it was >> a kernel bug in ntp.c but I haven't seen any details. > > None of mine (many dozens) hung. This is typical: > > ch at snaggle:~$ uname -a > Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC > 2008 x86_64 GNU/Linux > ch at snaggle:~$ dmesg | grep leap > [844362.415072] Clock: inserting leap second 23:59:60 UTC > ch at snaggle:~$ Same here with OpenSUSE 11.1 running 2.6.27.7-9-default willow:/home/steve # uname -a Linux willow 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64 x86_64 x86_64 GNU/Linux willow:/home/steve # grep leap /var/log/messages Jan 1 12:59:59 willow kernel: Clock: inserting leap second 23:59:60 UTC 73, Steve --- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From hmurray at megapathdsl.net Sat Jan 3 10:24:16 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 03 Jan 2009 02:24:16 -0800 Subject: [time-nuts] Leap Quirks In-Reply-To: Message from "Steve Rooke" of "Sat, 03 Jan 2009 19:40:39 +1300." <1231b6a80901022240n76d3ac3ew5f1121343f25996d@mail.gmail.com> Message-ID: <20090103102417.8A856BCD8@ip-64-139-1-69.sjc.megapath.net> [Linux systems hanging] >> None of mine (many dozens) hung. This is typical: >> [844362.415072] Clock: inserting leap second 23:59:60 UTC > Jan 1 12:59:59 willow kernel: Clock: inserting leap second 23:59:60 UTC It got slashdotted: http://ask.slashdot.org/article.pl?sid=09/01/01/1930202 I got bored before I found anything interesting. It's a locking bug in the kernel. That message gets printed with a lock held and sometimes that calls a routine that needs the lock... If you feed >linux hang ntp leap-second< to google-groups, the top hit is a thread in fa.linux.kernel with all the details. http://tinyurl.com/8juphd http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/474eef5d80898411?q=linux+hang+ntp+leap-second#f3fc957cad4d3001 -- These are my opinions, not necessarily my employer's. I hate spam. From cfharris at erols.com Sat Jan 3 14:13:25 2009 From: cfharris at erols.com (Chuck Harris) Date: Sat, 03 Jan 2009 09:13:25 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <00f201c96d6d$4e640390$eb2c0ab0$@com> References: <00f201c96d6d$4e640390$eb2c0ab0$@com> Message-ID: <495F7285.3040003@erols.com> christopher hoover wrote: > Hal Murray wrote: >> Two of my Linux systems hung. One was running a 2.6.25 kernel and one >> 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes >> on >> comp.protocols.time.ntp about Linux systems locking up. One said that >> it was >> a kernel bug in ntp.c but I haven't seen any details. > > None of mine (many dozens) hung. This is typical: > > ch at snaggle:~$ uname -a > Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC > 2008 x86_64 GNU/Linux > ch at snaggle:~$ dmesg | grep leap > [844362.415072] Clock: inserting leap second 23:59:60 UTC > ch at snaggle:~$ > > > -ch None of my linux systems hung either! My typical message was: $ dmesg | grep leap [6181904.453104] Clock: inserting leap second 23:59:60 UTC The message implies that linux clocks counted: 58..59..60..00..01 Which would not be the POSIX way. -Chuck Harris From magnus at rubidium.dyndns.org Sat Jan 3 16:09:39 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 03 Jan 2009 17:09:39 +0100 Subject: [time-nuts] Leap Quirks In-Reply-To: <495F7285.3040003@erols.com> References: <00f201c96d6d$4e640390$eb2c0ab0$@com> <495F7285.3040003@erols.com> Message-ID: <495F8DC3.9060805@rubidium.dyndns.org> Chuck Harris skrev: > christopher hoover wrote: >> Hal Murray wrote: >>> Two of my Linux systems hung. One was running a 2.6.25 kernel and one >>> 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes >>> on >>> comp.protocols.time.ntp about Linux systems locking up. One said that >>> it was >>> a kernel bug in ntp.c but I haven't seen any details. >> None of mine (many dozens) hung. This is typical: >> >> ch at snaggle:~$ uname -a >> Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC >> 2008 x86_64 GNU/Linux >> ch at snaggle:~$ dmesg | grep leap >> [844362.415072] Clock: inserting leap second 23:59:60 UTC >> ch at snaggle:~$ >> >> >> -ch > > None of my linux systems hung either! My typical message was: > > $ dmesg | grep leap > [6181904.453104] Clock: inserting leap second 23:59:60 UTC > > The message implies that linux clocks counted: > > 58..59..60..00..01 > > Which would not be the POSIX way. I just checked. Two of my linux machines happilly chewed on and they both display the same thing magda-gw:/etc# dmesg | grep leap [3672744.988878] Clock: inserting leap second 23:59:60 UTC magnus at heaven:~$ dmesg | grep leap [2382608.682165] Clock: inserting leap second 23:59:60 UTC I have not heard any screems of terror from my neck of the woods either. So what ever it is, few was actually affected. I am actually curious about where this happens and the answer is found in /usr/src/linux-source-2.6.26/kernel/time/ntp.c: /* * Leap second processing. If in leap-insert state at the end of the * day, the system clock is set back one second; if in leap-delete * state, the system clock is set ahead one second. */ static enum hrtimer_restart ntp_leap_second(struct hrtimer *timer) { enum hrtimer_restart res = HRTIMER_NORESTART; write_seqlock_irq(&xtime_lock); switch (time_state) { case TIME_OK: break; case TIME_INS: xtime.tv_sec--; wall_to_monotonic.tv_sec++; time_state = TIME_OOP; printk(KERN_NOTICE "Clock: " "inserting leap second 23:59:60 UTC\n"); leap_timer.expires = ktime_add_ns(leap_timer.expires, NSEC_PER_SEC); res = HRTIMER_RESTART; break; case TIME_DEL: xtime.tv_sec++; time_tai--; wall_to_monotonic.tv_sec--; time_state = TIME_WAIT; printk(KERN_NOTICE "Clock: " "deleting leap second 23:59:59 UTC\n"); break; case TIME_OOP: time_tai++; time_state = TIME_WAIT; /* fall through */ case TIME_WAIT: if (!(time_status & (STA_INS | STA_DEL))) time_state = TIME_OK; break; } update_vsyscall(&xtime, clock); write_sequnlock_irq(&xtime_lock); return res; } So the log message 23:59:60 is actually static value. This mechanism is what Dave Mills describes on his NTP page. The time calculations otherwise follow POSIX. Cheers, Magnus From imp at bsdimp.com Sat Jan 3 17:21:29 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 10:21:29 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: <495F7285.3040003@erols.com> References: <00f201c96d6d$4e640390$eb2c0ab0$@com> <495F7285.3040003@erols.com> Message-ID: <20090103.102129.-1947355854.imp@bsdimp.com> In message: <495F7285.3040003 at erols.com> Chuck Harris writes: : christopher hoover wrote: : > Hal Murray wrote: : >> Two of my Linux systems hung. One was running a 2.6.25 kernel and one : >> 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes : >> on : >> comp.protocols.time.ntp about Linux systems locking up. One said that : >> it was : >> a kernel bug in ntp.c but I haven't seen any details. : > : > None of mine (many dozens) hung. This is typical: : > : > ch at snaggle:~$ uname -a : > Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC : > 2008 x86_64 GNU/Linux : > ch at snaggle:~$ dmesg | grep leap : > [844362.415072] Clock: inserting leap second 23:59:60 UTC : > ch at snaggle:~$ : > : > : > -ch : : None of my linux systems hung either! My typical message was: : : $ dmesg | grep leap : [6181904.453104] Clock: inserting leap second 23:59:60 UTC : : The message implies that linux clocks counted: : : 58..59..60..00..01 : : Which would not be the POSIX way. That message doesn't imply that at all... Well, maybe it is the implication, but POSIX *CANNOT* count that way. It is number where 23:59:60 maps to, through normalization and *mktime, 00:00:00 (or maps to 23:59:59 if you are ticking time, which isn't required to do the mktime stuff). Warner From cloos at jhcloos.com Sat Jan 3 17:30:30 2009 From: cloos at jhcloos.com (James Cloos) Date: Sat, 03 Jan 2009 12:30:30 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <495F7285.3040003@erols.com> (Chuck Harris's message of "Sat, 03 Jan 2009 09:13:25 -0500") References: <00f201c96d6d$4e640390$eb2c0ab0$@com> <495F7285.3040003@erols.com> Message-ID: >>>>> "Chuck" == Chuck Harris writes: Chuck> The message implies that linux clocks counted: Chuck> 58..59..60..00..01 Chuck> Which would not be the POSIX way. No, the linux clocks counted: 1230768021..1230768022..1230768023..1230768024..1230768025 where 1230768024 is 2009-01-01 00:00:00 UTC. What gets output by any given userland apps depends on those apps. If one uses the Olsen tz database, the right zonefiles rather than the posix zonefiles, and a libc such as glibc, then one will have seen the seconds tick off 58..59..60..00..01. But that is purely a userland issue. If one uses the (lobotomized) posix zonefiles, one will have seen the seconds tick off 21..22..23..24..25. (Interesting coincidence there, that 1970 through 2008 (inclusive) has a number of days divisible by 5. Which makes for a nice, even 1230768000 seconds, were there no leap seconds.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From imp at bsdimp.com Sat Jan 3 17:37:25 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 10:37:25 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: References: <00f201c96d6d$4e640390$eb2c0ab0$@com> <495F7285.3040003@erols.com> Message-ID: <20090103.103725.-1622602415.imp@bsdimp.com> In message: James Cloos writes: : >>>>> "Chuck" == Chuck Harris writes: : : Chuck> The message implies that linux clocks counted: : : Chuck> 58..59..60..00..01 : : Chuck> Which would not be the POSIX way. : : No, the linux clocks counted: : : 1230768021..1230768022..1230768023..1230768024..1230768025 : : where 1230768024 is 2009-01-01 00:00:00 UTC. : : What gets output by any given userland apps depends on those apps. : : If one uses the Olsen tz database, the right zonefiles rather than the : posix zonefiles, and a libc such as glibc, then one will have seen the : seconds tick off 58..59..60..00..01. : : But that is purely a userland issue. : : If one uses the (lobotomized) posix zonefiles, one will have seen the : seconds tick off 21..22..23..24..25. : : (Interesting coincidence there, that 1970 through 2008 (inclusive) has a : number of days divisible by 5. Which makes for a nice, even 1230768000 : seconds, were there no leap seconds.) That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 at midnight is an invariant that's violated by the above sequence. Warner From cloos at jhcloos.com Sat Jan 3 18:24:54 2009 From: cloos at jhcloos.com (James Cloos) Date: Sat, 03 Jan 2009 13:24:54 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <20090103.103725.-1622602415.imp@bsdimp.com> (M. Warner Losh's message of "Sat, 03 Jan 2009 10:37:25 -0700 (MST)") References: <00f201c96d6d$4e640390$eb2c0ab0$@com> <495F7285.3040003@erols.com> <20090103.103725.-1622602415.imp@bsdimp.com> Message-ID: >>>>> "Warner" == M Warner Losh writes: Warner> That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 Warner> at midnight is an invariant that's violated by the above sequence. By which sequence? At every point in time where time_t % 86400 == 0 is true gmtime(2), when using no zoneinfo file or when using a posix zoneinfo file, will return a struct tm where the time of day is 00:00:00. (time_t)1230768024 was 2009-01-01 00:00:00 right/UTC (time_t)1230768000 was 2009-01-01 00:00:00 posix/UTC and the real 2009-01-01 00:00:00 UTC was exacly 1230768024 si seconds after 1970-01-01 00:00:00 UTC. That this leap second was (time_t)1230768023 is is a simple fact of how long it has been since the start of 1970. That POSIX pretends that 2009 UTC started 24 seconds earlier than it did is a bug. Anyone who has some requirement to exactly match POSIX as published can use the posix zoneinfo files and have time_t % 86400 == 0 as midnight ?UTC? every day. Their idea of time will be off, but they get to keep their fixed-sized intervals. Anyone who wants to track the real UTC can do so using the right zoneinfo files. By doing so they explicitly choose to ignore that particular bit of nonsense in POSIX, but that is OK since it is their choice. Everyone gets to choose which they prefer. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cfharris at erols.com Sat Jan 3 18:26:22 2009 From: cfharris at erols.com (Chuck Harris) Date: Sat, 03 Jan 2009 13:26:22 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <20090103.103725.-1622602415.imp@bsdimp.com> References: <00f201c96d6d$4e640390$eb2c0ab0$@com> <495F7285.3040003@erols.com> <20090103.103725.-1622602415.imp@bsdimp.com> Message-ID: <495FADCE.9060206@erols.com> M. Warner Losh wrote: > In message: > James Cloos writes: > : >>>>> "Chuck" == Chuck Harris writes: > : > : Chuck> The message implies that linux clocks counted: > : > : Chuck> 58..59..60..00..01 > : > : Chuck> Which would not be the POSIX way. > : > : No, the linux clocks counted: > : > : 1230768021..1230768022..1230768023..1230768024..1230768025 > : > : where 1230768024 is 2009-01-01 00:00:00 UTC. > : > : What gets output by any given userland apps depends on those apps. > : > : If one uses the Olsen tz database, the right zonefiles rather than the > : posix zonefiles, and a libc such as glibc, then one will have seen the > : seconds tick off 58..59..60..00..01. > : > : But that is purely a userland issue. > : > : If one uses the (lobotomized) posix zonefiles, one will have seen the > : seconds tick off 21..22..23..24..25. > : > : (Interesting coincidence there, that 1970 through 2008 (inclusive) has a > : number of days divisible by 5. Which makes for a nice, even 1230768000 > : seconds, were there no leap seconds.) > > That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 > at midnight is an invariant that's violated by the above sequence. > > Warner Which is what my message was saying. If linux does count 58..59..60..0 instead of 58..59..59..0, then it isn't following POSIX. [I have no interest in getting into an argument over whether linux, or POSIX should count that way.] Having a message from ntp.c that says there was a leap to HH:MM:60 implies that HH:MM:60 is a valid time as far as ntp.c's author is concerned. Having used unix since edition V, I am also aware of how unix systems count off seconds since the epoch 1/1/1970. But that really is immaterial to the discussion. -Chuck Harris From magnus at rubidium.dyndns.org Sat Jan 3 19:01:41 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 03 Jan 2009 20:01:41 +0100 Subject: [time-nuts] Leap Quirks In-Reply-To: <495FADCE.9060206@erols.com> References: <00f201c96d6d$4e640390$eb2c0ab0$@com> <495F7285.3040003@erols.com> <20090103.103725.-1622602415.imp@bsdimp.com> <495FADCE.9060206@erols.com> Message-ID: <495FB615.9080200@rubidium.dyndns.org> Chuck Harris skrev: > M. Warner Losh wrote: >> In message: >> James Cloos writes: >> : >>>>> "Chuck" == Chuck Harris writes: >> : >> : Chuck> The message implies that linux clocks counted: >> : >> : Chuck> 58..59..60..00..01 >> : >> : Chuck> Which would not be the POSIX way. >> : >> : No, the linux clocks counted: >> : >> : 1230768021..1230768022..1230768023..1230768024..1230768025 >> : >> : where 1230768024 is 2009-01-01 00:00:00 UTC. >> : >> : What gets output by any given userland apps depends on those apps. >> : >> : If one uses the Olsen tz database, the right zonefiles rather than the >> : posix zonefiles, and a libc such as glibc, then one will have seen the >> : seconds tick off 58..59..60..00..01. >> : >> : But that is purely a userland issue. >> : >> : If one uses the (lobotomized) posix zonefiles, one will have seen the >> : seconds tick off 21..22..23..24..25. >> : >> : (Interesting coincidence there, that 1970 through 2008 (inclusive) has a >> : number of days divisible by 5. Which makes for a nice, even 1230768000 >> : seconds, were there no leap seconds.) >> >> That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 >> at midnight is an invariant that's violated by the above sequence. >> >> Warner > > Which is what my message was saying. If linux does count 58..59..60..0 > instead of 58..59..59..0, then it isn't following POSIX. [I have no > interest in getting into an argument over whether linux, or POSIX > should count that way.] > > Having a message from ntp.c that says there was a leap > to HH:MM:60 implies that HH:MM:60 is a valid time as far > as ntp.c's author is concerned. It is valid UTC time, not valid POSIX time, which are two different things. > Having used unix since edition V, I am also aware of how unix > systems count off seconds since the epoch 1/1/1970. But that > really is immaterial to the discussion. No, since that is what POSIX says and Linux honours unless running NTP. Cheers, Magnus From imp at bsdimp.com Sat Jan 3 19:01:43 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 12:01:43 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: References: <20090103.103725.-1622602415.imp@bsdimp.com> Message-ID: <20090103.120143.1639455110.imp@bsdimp.com> In message: James Cloos writes: : >>>>> "Warner" == M Warner Losh writes: : : Warner> That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 : Warner> at midnight is an invariant that's violated by the above sequence. : : By which sequence? The sequence where midnight % 86400 isn't 0. : At every point in time where time_t % 86400 == 0 is true gmtime(2), when : using no zoneinfo file or when using a posix zoneinfo file, will return : a struct tm where the time of day is 00:00:00. : : (time_t)1230768024 was 2009-01-01 00:00:00 right/UTC : (time_t)1230768000 was 2009-01-01 00:00:00 posix/UTC : : and the real 2009-01-01 00:00:00 UTC was exacly 1230768024 si seconds : after 1970-01-01 00:00:00 UTC. Correct. The 'right' way here isn't POSIX compliant. POSIX has no leap seconds at all. They don't exist. : That this leap second was (time_t)1230768023 is is a simple fact of how : long it has been since the start of 1970. : : That POSIX pretends that 2009 UTC started 24 seconds earlier than it : did is a bug. It is the standard. It isn't desirable behavior, but it is what is mandated by the standard. You can argue it is a bug, and I might agree with you, but that won't make it any less the standard. And explicitly part of the standard after much arguments in committee. It is one of the things horribly broken by POSIX. Also, you need to run a hacked ntpd, because the ntp time stamps follow the posix mandate, not the TAI-like second count... : Anyone who has some requirement to exactly match POSIX as published can : use the posix zoneinfo files and have time_t % 86400 == 0 as midnight : ?UTC? every day. Their idea of time will be off, but they get to keep : their fixed-sized intervals. The trouble is that there's a lot of code that depends on this behavior... : Anyone who wants to track the real UTC can do so using the right : zoneinfo files. By doing so they explicitly choose to ignore : that particular bit of nonsense in POSIX, but that is OK since it : is their choice. : : Everyone gets to choose which they prefer. Correct. Of course, how do programs that run for years get updated leap second information so they continue to produce the correct times? I've never understood how that part of the 'right' files works... Warner From w1ksz at earthlink.net Sat Jan 3 20:09:00 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Sat, 3 Jan 2009 13:09:00 -0700 (GMT-07:00) Subject: [time-nuts] QUALCOMM Q3036I-16N Info Needed Message-ID: <32918895.1231013341182.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Does anyone have or know a source for a datasheet on a Qualcomm Q3036I-16N Synthesizer chip ? I picked up two "things" from "over there". They looked interesting and were rather cheap. These "things" had 4 SMA connectors, marked: 10 MHz 72.5 MHz 725 MHz 7.975 GHz and had three wires going to a power connector. I applied +15vdc to 2 of the three wires and got an output on one connector (72.5 MHz) around 71 MHz. When I applied a 10 MHz reference from one of my GPSDO's, the frequency shifted to 72.5 MHz and was quite stable. Similarly the outputs at 725 MHz and 7.975 GHz were also quite stable. More precise measurements to come. Now, if I can get the pinout of the Qualcomm chip, perhaps I can figure out how to move the output freq's. Who says there are no bargains "over there". 73, Dick, W1KSZ From imp at bsdimp.com Sat Jan 3 20:16:14 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 13:16:14 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: References: <20090103.103725.-1622602415.imp@bsdimp.com> Message-ID: <20090103.131614.1467006951.imp@bsdimp.com> This is a minor little pedantic followup from an answer I gave before to correct a minor little quibble about the historic UTC. If you are uninterested, hit 'd' now :) In message: James Cloos writes: : >>>>> "Warner" == M Warner Losh writes: : : Warner> That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 : Warner> at midnight is an invariant that's violated by the above sequence. : : By which sequence? : : At every point in time where time_t % 86400 == 0 is true gmtime(2), when : using no zoneinfo file or when using a posix zoneinfo file, will return : a struct tm where the time of day is 00:00:00. : : (time_t)1230768024 was 2009-01-01 00:00:00 right/UTC : (time_t)1230768000 was 2009-01-01 00:00:00 posix/UTC : : and the real 2009-01-01 00:00:00 UTC was exacly 1230768024 si seconds : after 1970-01-01 00:00:00 UTC. Except I don't think that 1970-01-01 00:00:00 UTC isn't what you think it is. While there have been 24 leap seconds since 1972-01-01 when the practice started, the divergence between TAI and UTC at 1970-01-01 00:00:00 was more like 8.1s[*] (it was fixed at 10.0 exactly in 1972). So there really have been an additional 1.9s since then. So the number is closer to 1230768025.9s since 1970-01-01 00:00:00 UTC for the second after the last leap second. The time before 1972 was when the atomic clocks were run a little slow to account for the variations in the earth's orbit. See for example the table from: http://maia.usno.navy.mil/ser7/tai-utc.dat So what you've done is created a new time scale that is a UTC from 1972 forward, but a simplified form of UTC prior to 1972 that didn't match what UTC was doing then. Yet another hazard of high precision time keeping that few people get right (to pound on my leap seconds are hard drum again). An understandable simplification, to be true, and one that's often made... Warner [*] I didn't do the math today, and the 8.1s figure is from my memory only. Someone with more time on their hands than I can compute the exact offset... From phk at phk.freebsd.dk Sat Jan 3 20:42:18 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 03 Jan 2009 20:42:18 +0000 Subject: [time-nuts] Leap Quirks In-Reply-To: Your message of "Sat, 03 Jan 2009 20:01:41 +0100." <495FB615.9080200@rubidium.dyndns.org> Message-ID: <26842.1231015338@critter.freebsd.dk> In message <495FB615.9080200 at rubidium.dyndns.org>, Magnus Danielson writes: >> Having a message from ntp.c that says there was a leap >> to HH:MM:60 implies that HH:MM:60 is a valid time as far >> as ntp.c's author is concerned. > >It is valid UTC time, not valid POSIX time, which are two different things. Well, it is a valid POSIX time, but it means a second later than desired in this case, because the 60 is taken as 60 seconds, and folded into a minute-roll-over. >> Having used unix since edition V, I am also aware of how unix >> systems count off seconds since the epoch 1/1/1970. But that >> really is immaterial to the discussion. No, that is actually the crux of the matter... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From cloos at jhcloos.com Sat Jan 3 21:10:32 2009 From: cloos at jhcloos.com (James Cloos) Date: Sat, 03 Jan 2009 16:10:32 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <20090103.120143.1639455110.imp@bsdimp.com> (M. Warner Losh's message of "Sat, 03 Jan 2009 12:01:43 -0700 (MST)") References: <20090103.103725.-1622602415.imp@bsdimp.com> <20090103.120143.1639455110.imp@bsdimp.com> Message-ID: >>>>> "Warner" == M Warner Losh writes: Jim> By which sequence? Warner> The sequence where midnight % 86400 isn't 0. MY appologies, but that isn't narrowing it for me. POSIX only cares about POSIX midnight, not UTC midnight, so the fact that it was already past PODIX midnight when the leap second and UTC midnight happened is irrelevant to POSIX. Warner> Also, you need to run a hacked ntpd, because the ntp time stamps Warner> follow the posix mandate, not the TAI-like second count... Huh? rfc1305 says 32.32 bit fixed point seconds since 1900-01-01 00:00:00, and of course there is the newer 64.64 bit fixed point. The only question, then, is whether ntp and UTC agree on just when 1900-01-01T00:00:00 was. ;^) Warner> how do programs that run for years get updated leap second Warner> information so they continue to produce the correct times? I've Warner> never understood how that part of the 'right' files works... That is libc-dependent. I've not looked at the src in a while (many months), but IIRC glibc opens the file every time it needs it, so it will see a new zoneinfo database as soon as they are written to the filesystem. Other libcs might do things differently. As an example, I don't think klibc uses the zoneinfo files at all; dietlibc and uclibc may not either. And obviously the BSDs' libcs handle things quite differently than glibc. (GNU on BSD kernels is not uncommon; I'm sure I've read about people doing one of the BSD userlands on a linux kernel, too.) But at least for glibc it just works. And, of course, said zoneinfo updates are needed anyway every time the politicians muck with the timezones. Libc also has to deal with changes to the TZ environmental variable. Another reason to re-read the zoneinfo files as necessary. (It is possible that glibc only reopens if the stat(2) data changes; again, it has been a *long* time since I last read that part of the glibc src.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cfharris at erols.com Sat Jan 3 21:18:47 2009 From: cfharris at erols.com (Chuck Harris) Date: Sat, 03 Jan 2009 16:18:47 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <26842.1231015338@critter.freebsd.dk> References: <26842.1231015338@critter.freebsd.dk> Message-ID: <495FD637.5030105@erols.com> Poul-Henning Kamp wrote: > In message <495FB615.9080200 at rubidium.dyndns.org>, Magnus Danielson writes: > >>> Having a message from ntp.c that says there was a leap >>> to HH:MM:60 implies that HH:MM:60 is a valid time as far >>> as ntp.c's author is concerned. >> It is valid UTC time, not valid POSIX time, which are two different things. > > Well, it is a valid POSIX time, but it means a second later than > desired in this case, because the 60 is taken as 60 seconds, and > folded into a minute-roll-over. > >>> Having used unix since edition V, I am also aware of how unix >>> systems count off seconds since the epoch 1/1/1970. But that >>> really is immaterial to the discussion. > > No, that is actually the crux of the matter... Ok, that is news to me. Are you saying that (pulling a number out of the air) time_t = 21120123 could be followed by 21120123 on a year where we added a leap second? It is my understanding that it cannot. I believe that time_t must increment by one as each second passes, and must contain the number of seconds that have passed since the unix epoch on 1/1/1970... without regard for leap seconds. I was of the understanding that the problem was in how the UTC time was calculated from time_t, and the converse. Do tell! -Chuck Harris From imp at bsdimp.com Sat Jan 3 21:18:17 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 14:18:17 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: <26842.1231015338@critter.freebsd.dk> References: <495FB615.9080200@rubidium.dyndns.org> <26842.1231015338@critter.freebsd.dk> Message-ID: <20090103.141817.1172763476.imp@bsdimp.com> In message: <26842.1231015338 at critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <495FB615.9080200 at rubidium.dyndns.org>, Magnus Danielson writes: : : >> Having a message from ntp.c that says there was a leap : >> to HH:MM:60 implies that HH:MM:60 is a valid time as far : >> as ntp.c's author is concerned. : > : >It is valid UTC time, not valid POSIX time, which are two different things. : : Well, it is a valid POSIX time, but it means a second later than : desired in this case, because the 60 is taken as 60 seconds, and : folded into a minute-roll-over. It is a valid POSIX struct tm time. But it doesn't represent a leap second. Instead, like you say, it wraps to the next minute. There are not POSIXly compliant time_t values that will map to the leap second value (23:59:60). It is not possible to represent the leap second in a time_t. : >> Having used unix since edition V, I am also aware of how unix : >> systems count off seconds since the epoch 1/1/1970. But that : >> really is immaterial to the discussion. : : No, that is actually the crux of the matter... Yes. Such a simple definition gives so many possible ways to interpret it. The POSIX "there are no leap seconds" way. The prior + accumulated leap seconds. And also the prior, plus the extra time that accumulated between 1970 and 1972 in the UTC time scale... But that last one is kinda hard since it isn't an whole number of seconds. I've seen timescales try to use all of these definitions at one point in my career or another (plus a boatload of others that seemed like a good idea at the time to the inventors). Warner From phk at phk.freebsd.dk Sat Jan 3 21:24:24 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 03 Jan 2009 21:24:24 +0000 Subject: [time-nuts] Leap Quirks In-Reply-To: Your message of "Sat, 03 Jan 2009 16:18:47 EST." <495FD637.5030105@erols.com> Message-ID: <28089.1231017864@critter.freebsd.dk> In message <495FD637.5030105 at erols.com>, Chuck Harris writes: >Ok, that is news to me. Are you saying that (pulling a number out of >the air) time_t = 21120123 could be followed by 21120123 on a year where >we added a leap second? Apart from the number, that is exactly what happens: The last second of the (UTC) day is recycled twice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From imp at bsdimp.com Sat Jan 3 21:23:26 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 14:23:26 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: References: <20090103.120143.1639455110.imp@bsdimp.com> Message-ID: <20090103.142326.1179135003.imp@bsdimp.com> In message: James Cloos writes: : >>>>> "Warner" == M Warner Losh writes: : : Jim> By which sequence? : : Warner> The sequence where midnight % 86400 isn't 0. : : MY appologies, but that isn't narrowing it for me. POSIX only cares : about POSIX midnight, not UTC midnight, so the fact that it was already : past PODIX midnight when the leap second and UTC midnight happened is : irrelevant to POSIX. posix midnight and utc midnight are the same things. You had said that the system time was returned as ....24 at UTC 2009-01-01 00:00:00, which isn't posixly correct. : Warner> Also, you need to run a hacked ntpd, because the ntp time stamps : Warner> follow the posix mandate, not the TAI-like second count... : : Huh? rfc1305 says 32.32 bit fixed point seconds since 1900-01-01 : 00:00:00, and of course there is the newer 64.64 bit fixed point. : : The only question, then, is whether ntp and UTC agree on just when : 1900-01-01T00:00:00 was. ;^) ntpd needs to convert the time from the kernel to the 32.32 number. To do that, by default it assumes a POSIXly correct time_t. That's the only point I was making. If a different number is returned (one with leap seconds added in), then ntpd has to cope. : Warner> how do programs that run for years get updated leap second : Warner> information so they continue to produce the correct times? I've : Warner> never understood how that part of the 'right' files works... : : That is libc-dependent. I've not looked at the src in a while (many : months), but IIRC glibc opens the file every time it needs it, so it : will see a new zoneinfo database as soon as they are written to the : filesystem. : : Other libcs might do things differently. As an example, I don't think : klibc uses the zoneinfo files at all; dietlibc and uclibc may not : either. And obviously the BSDs' libcs handle things quite differently : than glibc. (GNU on BSD kernels is not uncommon; I'm sure I've read : about people doing one of the BSD userlands on a linux kernel, too.) : But at least for glibc it just works. : : And, of course, said zoneinfo updates are needed anyway every time the : politicians muck with the timezones. Libc also has to deal with changes : to the TZ environmental variable. Another reason to re-read the : zoneinfo files as necessary. (It is possible that glibc only reopens if : the stat(2) data changes; again, it has been a *long* time since I last : read that part of the glibc src.) Yea, I was wondering if it did a stat on every time conversion, or if it batched them somehow. Doing one on every conversion seems very heavy-weight to me... Hence my question of how do the updated zoneinfo files happen, and how does the application get notified of the changed of leap info in case they have already computed a time that would be affected by the new leap information. Warner From imp at bsdimp.com Sat Jan 3 21:27:30 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 14:27:30 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: <495FD637.5030105@erols.com> References: <26842.1231015338@critter.freebsd.dk> <495FD637.5030105@erols.com> Message-ID: <20090103.142730.-828690956.imp@bsdimp.com> In message: <495FD637.5030105 at erols.com> Chuck Harris writes: : Poul-Henning Kamp wrote: : > In message <495FB615.9080200 at rubidium.dyndns.org>, Magnus Danielson writes: : > : >>> Having a message from ntp.c that says there was a leap : >>> to HH:MM:60 implies that HH:MM:60 is a valid time as far : >>> as ntp.c's author is concerned. : >> It is valid UTC time, not valid POSIX time, which are two different things. : > : > Well, it is a valid POSIX time, but it means a second later than : > desired in this case, because the 60 is taken as 60 seconds, and : > folded into a minute-roll-over. : > : >>> Having used unix since edition V, I am also aware of how unix : >>> systems count off seconds since the epoch 1/1/1970. But that : >>> really is immaterial to the discussion. : > : > No, that is actually the crux of the matter... : : Ok, that is news to me. Are you saying that (pulling a number out of : the air) time_t = 21120123 could be followed by 21120123 on a year where : we added a leap second? Yes. Leap seconds don't exist in POSIX time_t, so the pedantically proper value is undefined. Most implementations repeat a second (either 59 or the 00 second) to cope with this omission. : It is my understanding that it cannot. I believe that time_t must : increment by one as each second passes, and must contain the number of : seconds that have passed since the unix epoch on 1/1/1970... without : regard for leap seconds. That isn't what POSIX says. POSIX is very clear that leap seconds do not exist, and therefore the correct answer for the first second of a year (or of any day) always ends in '00'. : I was of the understanding that the problem was in how the UTC time was : calculated from time_t, and the converse. The problem is that the conversion of time_t to a 'broken down' UTC time isn't 1:1 or onto. Warner From henk at deriesp.demon.nl Sat Jan 3 21:38:12 2009 From: henk at deriesp.demon.nl (Henk ten Pierick) Date: Sat, 3 Jan 2009 22:38:12 +0100 Subject: [time-nuts] opto coupler isolation? Message-ID: <494882EB-D714-49B4-A7E2-BEF04509D7F4@deriesp.demon.nl> Hi, An opto coupler seems good idea for an isolation amplifier but maybe not for the phase noise. Any experience? regards, henk From bruce.griffiths at xtra.co.nz Sat Jan 3 21:52:25 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 04 Jan 2009 10:52:25 +1300 Subject: [time-nuts] opto coupler isolation? In-Reply-To: <494882EB-D714-49B4-A7E2-BEF04509D7F4@deriesp.demon.nl> References: <494882EB-D714-49B4-A7E2-BEF04509D7F4@deriesp.demon.nl> Message-ID: <495FDE19.6000203@xtra.co.nz> Henk ten Pierick wrote: > Hi, > > An opto coupler seems good idea for an isolation amplifier but maybe > not for the phase noise. > Any experience? > > regards, > > henk > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Henk The better optoisolators typically have a random jitter on the order of 50-100ps rms. This is considerably more than that for ACMOS logic (~1ps rms). Consequently the phase noise floor will be about 34 to 40dB higher than that when using ACMOS logic. Thus for low phase noise OCXOs using an optical isolator will significantly degrade the phase noise. An RF transformer is a lower phase noise solution to providing low frequency ground isolation. Achieving a reverse isolation of more than 140dB isnt too difficult with a few cascaded CB stages and a good layout combined with apprpriate shielding. Bruce From phk at phk.freebsd.dk Sat Jan 3 22:27:00 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 03 Jan 2009 22:27:00 +0000 Subject: [time-nuts] opto coupler isolation? In-Reply-To: Your message of "Sat, 03 Jan 2009 22:38:12 +0100." <494882EB-D714-49B4-A7E2-BEF04509D7F4@deriesp.demon.nl> Message-ID: <28987.1231021620@critter.freebsd.dk> In message <494882EB-D714-49B4-A7E2-BEF04509D7F4 at deriesp.demon.nl>, Henk ten Pi erick writes: >Hi, > >An opto coupler seems good idea for an isolation amplifier but maybe >not for the phase noise. Optocouplers have lousy dV/dt performance, so the jitter is horrible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bruce.griffiths at xtra.co.nz Sat Jan 3 22:33:38 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 04 Jan 2009 11:33:38 +1300 Subject: [time-nuts] opto coupler isolation? In-Reply-To: <28987.1231021620@critter.freebsd.dk> References: <28987.1231021620@critter.freebsd.dk> Message-ID: <495FE7C2.4000601@xtra.co.nz> Poul-Henning Kamp wrote: > In message <494882EB-D714-49B4-A7E2-BEF04509D7F4 at deriesp.demon.nl>, Henk ten Pi > erick writes: > >> Hi, >> >> An opto coupler seems good idea for an isolation amplifier but maybe >> not for the phase noise. >> > > Optocouplers have lousy dV/dt performance, so the jitter is > horrible. > > Not true for the higher speed optoisolators (eg Avago's HCPL9000 series) In any case its more a matter of noise to slew rate ratio. The issue is really that the signal to noise ratio of the internal optical signal is relatively low. For better performance you need to use a higher power optical signal such as that from a single mode laser. However by the time you factor in the cost of the modulator etc its usually better to revert to a conventional design. Bruce From magnus at rubidium.dyndns.org Sat Jan 3 22:42:16 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 03 Jan 2009 23:42:16 +0100 Subject: [time-nuts] opto coupler isolation? In-Reply-To: <28987.1231021620@critter.freebsd.dk> References: <28987.1231021620@critter.freebsd.dk> Message-ID: <495FE9C8.5050202@rubidium.dyndns.org> Poul-Henning Kamp skrev: > In message <494882EB-D714-49B4-A7E2-BEF04509D7F4 at deriesp.demon.nl>, Henk ten Pi > erick writes: >> Hi, >> >> An opto coupler seems good idea for an isolation amplifier but maybe >> not for the phase noise. > > Optocouplers have lousy dV/dt performance, so the jitter is > horrible. > Some optocouplers can be pretty good. Some even have 10s of km of pulled silica glas between the two sides. Some even have 1000s of km of pulled silica glas between them, and still have pretty OK dV/dt and noise. The cheap onces are really lousy thought. Cheers, Magnus - using several opto-couplers to get the message through From henk at deriesp.demon.nl Sat Jan 3 22:53:44 2009 From: henk at deriesp.demon.nl (Henk ten Pierick) Date: Sat, 3 Jan 2009 23:53:44 +0100 Subject: [time-nuts] opto coupler isolation? In-Reply-To: <495FE7C2.4000601@xtra.co.nz> References: <28987.1231021620@critter.freebsd.dk> <495FE7C2.4000601@xtra.co.nz> Message-ID: <253C7A81-5A31-491D-AF05-F6B299E40461@deriesp.demon.nl> Hi, Thanks for the response, I did expect this. It saves me the experiment. henk On Jan 3, 2009, at 23:33, Bruce Griffiths wrote: > Poul-Henning Kamp wrote: >> In message <494882EB-D714-49B4-A7E2- >> BEF04509D7F4 at deriesp.demon.nl>, Henk ten Pi >> erick writes: >> >>> Hi, >>> >>> An opto coupler seems good idea for an isolation amplifier but >>> maybe >>> not for the phase noise. >>> >> >> Optocouplers have lousy dV/dt performance, so the jitter is >> horrible. >> >> > Not true for the higher speed optoisolators (eg Avago's HCPL9000 > series) > In any case its more a matter of noise to slew rate ratio. > > The issue is really that the signal to noise ratio of the internal > optical signal is relatively low. > For better performance you need to use a higher power optical signal > such as that from a single mode laser. > However by the time you factor in the cost of the modulator etc its > usually better to revert to a conventional design. > > Bruce > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ > time-nuts > and follow the instructions there. From magnus at rubidium.dyndns.org Sat Jan 3 23:47:40 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sun, 04 Jan 2009 00:47:40 +0100 Subject: [time-nuts] Leap Quirks In-Reply-To: <20090103.142326.1179135003.imp@bsdimp.com> References: <20090103.120143.1639455110.imp@bsdimp.com> <20090103.142326.1179135003.imp@bsdimp.com> Message-ID: <495FF91C.60401@rubidium.dyndns.org> M. Warner Losh skrev: > In message: > James Cloos writes: > : >>>>> "Warner" == M Warner Losh writes: > : > : Jim> By which sequence? > : > : Warner> The sequence where midnight % 86400 isn't 0. > : > : MY appologies, but that isn't narrowing it for me. POSIX only cares > : about POSIX midnight, not UTC midnight, so the fact that it was already > : past PODIX midnight when the leap second and UTC midnight happened is > : irrelevant to POSIX. > > posix midnight and utc midnight are the same things. You had said > that the system time was returned as ....24 at UTC 2009-01-01 > 00:00:00, which isn't posixly correct. Um... no. That's the hacked POSIX interpretation, not the POSIX standard. We have at least three POSIX interpretations here. One which has UTC rubber seconds from 1970 to 1972 and from then true SI seconds from 1972. One which has true SI seconds from 1970. One which has UTC tracking in pieces and is slid "sideways" to make midnight match UTC midnight. The two first ones is interpretations of POSIX over UTC variations. The third one is a hack of POSIX to make it kind of work anyway with NTP. Only with the third interpretation POSIX midnight and UTC midnight is the same. Now, which of them is "right"? Cheers, Magnus From phk at phk.freebsd.dk Sun Jan 4 00:11:12 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 04 Jan 2009 00:11:12 +0000 Subject: [time-nuts] Leap Quirks In-Reply-To: Your message of "Sun, 04 Jan 2009 00:47:40 +0100." <495FF91C.60401@rubidium.dyndns.org> Message-ID: <35285.1231027872@critter.freebsd.dk> In message <495FF91C.60401 at rubidium.dyndns.org>, Magnus Danielson writes: >We have at least three POSIX interpretations here. > >One which has UTC rubber seconds from 1970 to 1972 and from then true SI >seconds from 1972. >One which has true SI seconds from 1970. >One which has UTC tracking in pieces and is slid "sideways" to make >midnight match UTC midnight. > >The two first ones is interpretations of POSIX over UTC variations. The >third one is a hack of POSIX to make it kind of work anyway with NTP. >Only with the third interpretation POSIX midnight and UTC midnight is >the same. > >Now, which of them is "right"? Strictly speaking none of them. Instead of thinking of POSIX "wall-clock" facilities as a timekeeping mechanism, think of them as asking the next stranger you meet what time it is. POSIX only offers you the ability to get an estimate of "wall-clock" time, it does not guarantee that the such estimates will not represent time going backwards, or that the amount of time between the two requests will correspond to the difference between them. The trouble is, obviously, that people pressume these properties. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From cfharris at erols.com Sun Jan 4 00:27:42 2009 From: cfharris at erols.com (Chuck Harris) Date: Sat, 03 Jan 2009 19:27:42 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <28089.1231017864@critter.freebsd.dk> References: <28089.1231017864@critter.freebsd.dk> Message-ID: <4960027E.1000103@erols.com> Poul-Henning Kamp wrote: > In message <495FD637.5030105 at erols.com>, Chuck Harris writes: > >> Ok, that is news to me. Are you saying that (pulling a number out of >> the air) time_t = 21120123 could be followed by 21120123 on a year where >> we added a leap second? > > Apart from the number, that is exactly what happens: The last > second of the (UTC) day is recycled twice. As far as I remember, and as far as I can tell, what you are saying violates both the unix and POSIX definition of time_t. So to check, I pulled out both of my K&R editions of "The C programming Language" and I did a quick google on time_t, and all of the sources I have found concur that time_t is the number of seconds since 1/1/1970 UTC without regard to leap seconds. When did this change? -Chuck Harris From magnus at rubidium.dyndns.org Sun Jan 4 00:39:14 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sun, 04 Jan 2009 01:39:14 +0100 Subject: [time-nuts] Leap Quirks In-Reply-To: <35285.1231027872@critter.freebsd.dk> References: <35285.1231027872@critter.freebsd.dk> Message-ID: <49600532.6050503@rubidium.dyndns.org> Poul-Henning Kamp skrev: > In message <495FF91C.60401 at rubidium.dyndns.org>, Magnus Danielson writes: > >> We have at least three POSIX interpretations here. >> >> One which has UTC rubber seconds from 1970 to 1972 and from then true SI >> seconds from 1972. >> One which has true SI seconds from 1970. >> One which has UTC tracking in pieces and is slid "sideways" to make >> midnight match UTC midnight. >> >> The two first ones is interpretations of POSIX over UTC variations. The >> third one is a hack of POSIX to make it kind of work anyway with NTP. >> Only with the third interpretation POSIX midnight and UTC midnight is >> the same. >> >> Now, which of them is "right"? > > Strictly speaking none of them. > > Instead of thinking of POSIX "wall-clock" facilities as a timekeeping > mechanism, think of them as asking the next stranger you meet what > time it is. > > POSIX only offers you the ability to get an estimate of "wall-clock" > time, it does not guarantee that the such estimates will not represent > time going backwards, or that the amount of time between the two > requests will correspond to the difference between them. > > The trouble is, obviously, that people pressume these properties. > Which is more or less what I also think nowdays. The trouble is that it looks like time, feels like time and people try to make it behave like time, but isn't that. The monotonicity increasing aspect comes to mind as well, as you indicated. Do you agree with my possible interpretations by the way? Cheers, Magnus From magnus at rubidium.dyndns.org Sun Jan 4 00:49:35 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sun, 04 Jan 2009 01:49:35 +0100 Subject: [time-nuts] Leap Quirks In-Reply-To: <4960027E.1000103@erols.com> References: <28089.1231017864@critter.freebsd.dk> <4960027E.1000103@erols.com> Message-ID: <4960079F.1030803@rubidium.dyndns.org> Chuck Harris skrev: > Poul-Henning Kamp wrote: >> In message <495FD637.5030105 at erols.com>, Chuck Harris writes: >> >>> Ok, that is news to me. Are you saying that (pulling a number out of >>> the air) time_t = 21120123 could be followed by 21120123 on a year where >>> we added a leap second? >> Apart from the number, that is exactly what happens: The last >> second of the (UTC) day is recycled twice. > > As far as I remember, and as far as I can tell, what you are saying > violates both the unix and POSIX definition of time_t. > > So to check, I pulled out both of my K&R editions of "The C programming Language" > and I did a quick google on time_t, and all of the sources I have found > concur that time_t is the number of seconds since 1/1/1970 UTC without > regard to leap seconds. > > When did this change? Depends on which interpretation of POSIX you are making... how you "fit" your UTC time onto the POSIX scale. This page can serve as some aid in that puzzle: http://www.cis.udel.edu/~mills/leap.html If you want POSIX midnight to fit UTC midnight, then a piece-wise mapping must be maintained. Another way would be to just keep POSIX time as SI seconds (or UTC rubber until 1972 and SI from there on, which is more practical if you care about details) and solve the UTC issue "outside" the core. Which is fine too. Cheers, Magnus From cloos at jhcloos.com Sat Jan 3 21:34:24 2009 From: cloos at jhcloos.com (James Cloos) Date: Sat, 03 Jan 2009 16:34:24 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <20090103.131614.1467006951.imp@bsdimp.com> (M. Warner Losh's message of "Sat, 03 Jan 2009 13:16:14 -0700 (MST)") References: <20090103.103725.-1622602415.imp@bsdimp.com> <20090103.131614.1467006951.imp@bsdimp.com> Message-ID: >>>>> "Warner" == M Warner Losh writes: Warner> So what you've done is created a new time scale that is a UTC Warner> from 1972 forward, but a simplified form of UTC prior to 1972 Warner> that didn't match what UTC was doing then. Grrr! Except s/you/they/; I didn't invent. So right isn't quite, err, right. I wonder whether the Olsen db can be fixed to account for that? right/UTC and posix/UTC currently are identical for all (time_t)LONG_MIN <= time_t < 78796800. Thanks for the reminder. I had forgotten that entirely. (And am only just vaguely remembering that I used to know that fact. [SIGH]) Warner> Yet another hazard of high precision time keeping that few Warner> people get right Part of what makes this list's name so appropriate is just how hard it is, all things considered. That is also what makes it enjoyable. Warner> An understandable simplification, to be true, and one that's Warner> often made... Often, I'm sure, because not all sources document/remember that fact. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From james.p.lux at jpl.nasa.gov Sun Jan 4 04:46:36 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Sat, 3 Jan 2009 20:46:36 -0800 Subject: [time-nuts] Leap Quirks In-Reply-To: Message-ID: On 1/3/09 1:34 PM, "James Cloos" wrote: > Warner> Yet another hazard of high precision time keeping that few > Warner> people get right > > Part of what makes this list's name so appropriate is just how hard > it is, all things considered. That is also what makes it enjoyable. > And, now, add in trying to synchronize clocks on moving platforms where the platforms move fast enough (or the relative timing requirements) are such that relativistic effects are important. I'm working with developing a "standard" for timekeeping for spacecraft radios (since the radio receives the sync signal (e.g. GPS, TDRSS, or DSN), and often has a very good oscillator (e.g. A USO) connected to it, it makes sense to do time keeping there..) You'd think that you could just do something like TAI, but there's a long, long heritage of using other time scales of one sort or another, referenced to various things. All well and good for situations where you can dereference the difference between spacecraft time and "whatever" time after the fact (e.g. When you're looking at radar returns, or radio science data), but kind of a pain when you're looking to do things in real time. Jim From imp at bsdimp.com Sun Jan 4 05:54:35 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 22:54:35 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: <495FF91C.60401@rubidium.dyndns.org> References: <20090103.142326.1179135003.imp@bsdimp.com> <495FF91C.60401@rubidium.dyndns.org> Message-ID: <20090103.225435.778152699.imp@bsdimp.com> In message: <495FF91C.60401 at rubidium.dyndns.org> Magnus Danielson writes: : M. Warner Losh skrev: : > In message: : > James Cloos writes: : > : >>>>> "Warner" == M Warner Losh writes: : > : : > : Jim> By which sequence? : > : : > : Warner> The sequence where midnight % 86400 isn't 0. : > : : > : MY appologies, but that isn't narrowing it for me. POSIX only cares : > : about POSIX midnight, not UTC midnight, so the fact that it was already : > : past PODIX midnight when the leap second and UTC midnight happened is : > : irrelevant to POSIX. : > : > posix midnight and utc midnight are the same things. You had said : > that the system time was returned as ....24 at UTC 2009-01-01 : > 00:00:00, which isn't posixly correct. : : Um... no. That's the hacked POSIX interpretation, not the POSIX standard. : : We have at least three POSIX interpretations here. : : One which has UTC rubber seconds from 1970 to 1972 and from then true SI : seconds from 1972. : One which has true SI seconds from 1970. : One which has UTC tracking in pieces and is slid "sideways" to make : midnight match UTC midnight. : : The two first ones is interpretations of POSIX over UTC variations. The : third one is a hack of POSIX to make it kind of work anyway with NTP. : Only with the third interpretation POSIX midnight and UTC midnight is : the same. : : Now, which of them is "right"? Midnight must be xxxx00. POSIX says so explicitly because leap seconds do not exist in POSIX. The committee has issued a very explicit addendum to this effect. Which one is more desirable? Well, that's a matter of debate, but which one is POSIXly correct isn't. Warner From imp at bsdimp.com Sun Jan 4 05:56:53 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 03 Jan 2009 22:56:53 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: <4960027E.1000103@erols.com> References: <28089.1231017864@critter.freebsd.dk> <4960027E.1000103@erols.com> Message-ID: <20090103.225653.1346820994.imp@bsdimp.com> In message: <4960027E.1000103 at erols.com> Chuck Harris writes: : Poul-Henning Kamp wrote: : > In message <495FD637.5030105 at erols.com>, Chuck Harris writes: : > : >> Ok, that is news to me. Are you saying that (pulling a number out of : >> the air) time_t = 21120123 could be followed by 21120123 on a year where : >> we added a leap second? : > : > Apart from the number, that is exactly what happens: The last : > second of the (UTC) day is recycled twice. : : As far as I remember, and as far as I can tell, what you are saying : violates both the unix and POSIX definition of time_t. : : So to check, I pulled out both of my K&R editions of "The C programming Language" : and I did a quick google on time_t, and all of the sources I have found : concur that time_t is the number of seconds since 1/1/1970 UTC without : regard to leap seconds. That's exactly what Poul is saying. Without regard to leap seconds means that they don't exist and do not count in POSIX. A midnight time_t % 86400 must == 0, or it isn't POSIX. : When did this change? It never was clearly defined before POSIX, and POSIX made at least 4 muddled attempts to define it. Warner From imp at bsdimp.com Sun Jan 4 08:14:32 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sun, 04 Jan 2009 01:14:32 -0700 (MST) Subject: [time-nuts] Leap Quirks In-Reply-To: References: <20090103.131614.1467006951.imp@bsdimp.com> Message-ID: <20090104.011432.-1470509191.imp@bsdimp.com> In message: James Cloos writes: : >>>>> "Warner" == M Warner Losh writes: : : Warner> So what you've done is created a new time scale that is a UTC : Warner> from 1972 forward, but a simplified form of UTC prior to 1972 : Warner> that didn't match what UTC was doing then. : : Grrr! Except s/you/they/; I didn't invent. Yea, I was speaking a bit rhetorically :-) : So right isn't quite, err, right. I wonder whether the Olsen db can : be fixed to account for that? right/UTC and posix/UTC currently are : identical for all (time_t)LONG_MIN <= time_t < 78796800. Yes. I'd forgotten that the Olsen db doesn't deal with rubber seconds at all. It is a pain in the *** to try to do that, and of dubious value. I tried once to create a library that coped with them, but gave up when I realized it wasn't a useful problem to solve. : Thanks for the reminder. I had forgotten that entirely. (And am : only just vaguely remembering that I used to know that fact. [SIGH]) It is certainly underdocumented... : Warner> Yet another hazard of high precision time keeping that few : Warner> people get right : : Part of what makes this list's name so appropriate is just how hard : it is, all things considered. That is also what makes it enjoyable. Yes. Very enjoyable. Of course, I could live without all this complexity, frankly, and be happier. : Warner> An understandable simplification, to be true, and one that's : Warner> often made... : : Often, I'm sure, because not all sources document/remember that fact. Yea. In another life, I defined a datum as 'number of SI seconds since 01-01-1972 00:00:00 UTC + 63072000'. Which is what we're talking about here, no? This is number of seconds since 1970, with the 'oddball' rubber seconds counting as SI seconds. Warner From phk at phk.freebsd.dk Sun Jan 4 09:44:33 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 04 Jan 2009 09:44:33 +0000 Subject: [time-nuts] Leap Quirks In-Reply-To: Your message of "Sat, 03 Jan 2009 19:27:42 EST." <4960027E.1000103@erols.com> Message-ID: <38461.1231062273@critter.freebsd.dk> In message <4960027E.1000103 at erols.com>, Chuck Harris writes: >Poul-Henning Kamp wrote: >>> Ok, that is news to me. Are you saying that (pulling a number out of >>> the air) time_t = 21120123 could be followed by 21120123 on a year where >>> we added a leap second? >> >> Apart from the number, that is exactly what happens: The last >> second of the (UTC) day is recycled twice. > >[...] and all of the sources I have found >concur that time_t is the number of seconds since 1/1/1970 UTC without >regard to leap seconds. > >When did this change? Never, that's the trouble. time_t is better defined as: d * 86400 + min(rs, 86399) where: d = Number of complete days since 1970-01-01H00:00:00Z rs = number of seconds since UTC midnight. Eliminating leapseconds would make it correct however. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From cfharris at erols.com Sun Jan 4 14:36:56 2009 From: cfharris at erols.com (Chuck Harris) Date: Sun, 04 Jan 2009 09:36:56 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <4960079F.1030803@rubidium.dyndns.org> References: <28089.1231017864@critter.freebsd.dk> <4960027E.1000103@erols.com> <4960079F.1030803@rubidium.dyndns.org> Message-ID: <4960C988.6090005@erols.com> One of us is confused about what time_t is... I think it is you. time_t is a 32 bit (depreciated), or 64 bit integer that contains the number of seconds since the epoch. It is not to be adjusted for leap seconds according to POSIX, and unix convention. Everything to do with UTC and leap seconds is a library function in most unixes that translates the leap second free time_t into the leap second adjusted UTC. Again, are you telling me that time_t is getting adjusted for leap seconds? If so, when did this change? -Chuck Harris Magnus Danielson wrote: > Chuck Harris skrev: >> Poul-Henning Kamp wrote: >>> In message <495FD637.5030105 at erols.com>, Chuck Harris writes: >>> >>>> Ok, that is news to me. Are you saying that (pulling a number out of >>>> the air) time_t = 21120123 could be followed by 21120123 on a year where >>>> we added a leap second? >>> Apart from the number, that is exactly what happens: The last >>> second of the (UTC) day is recycled twice. >> As far as I remember, and as far as I can tell, what you are saying >> violates both the unix and POSIX definition of time_t. >> >> So to check, I pulled out both of my K&R editions of "The C programming Language" >> and I did a quick google on time_t, and all of the sources I have found >> concur that time_t is the number of seconds since 1/1/1970 UTC without >> regard to leap seconds. >> >> When did this change? > > Depends on which interpretation of POSIX you are making... how you "fit" > your UTC time onto the POSIX scale. > > This page can serve as some aid in that puzzle: > http://www.cis.udel.edu/~mills/leap.html > > If you want POSIX midnight to fit UTC midnight, then a piece-wise > mapping must be maintained. > > Another way would be to just keep POSIX time as SI seconds (or UTC > rubber until 1972 and SI from there on, which is more practical if you > care about details) and solve the UTC issue "outside" the core. Which is > fine too. > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From cfharris at erols.com Sun Jan 4 14:57:01 2009 From: cfharris at erols.com (Chuck Harris) Date: Sun, 04 Jan 2009 09:57:01 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <38461.1231062273@critter.freebsd.dk> References: <38461.1231062273@critter.freebsd.dk> Message-ID: <4960CE3D.4080005@erols.com> Poul-Henning Kamp wrote: > In message <4960027E.1000103 at erols.com>, Chuck Harris writes: >> Poul-Henning Kamp wrote: > >>>> Ok, that is news to me. Are you saying that (pulling a number out of >>>> the air) time_t = 21120123 could be followed by 21120123 on a year where >>>> we added a leap second? >>> Apart from the number, that is exactly what happens: The last >>> second of the (UTC) day is recycled twice. >> [...] and all of the sources I have found >> concur that time_t is the number of seconds since 1/1/1970 UTC without >> regard to leap seconds. >> >> When did this change? > > Never, that's the trouble. > > time_t is better defined as: > > d * 86400 + min(rs, 86399) > > where: > d = Number of complete days since 1970-01-01H00:00:00Z > rs = number of seconds since UTC midnight. > > Eliminating leapseconds would make it correct however. Language is such a problem with these discussions. Your equation says exactly what I believe to be true, but your use of the word correct muddles everything for me. POSIXly correct, and unixly correct is when time_t follows your equation. Following UTC is another kind of correct: politically correct. I believe your use of the phrase "make it correct" shows your bias towards removing the leap second corrections from UTC. This is my bias as well. -Chuck Harris From phk at phk.freebsd.dk Sun Jan 4 16:18:37 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 04 Jan 2009 16:18:37 +0000 Subject: [time-nuts] Leap Quirks In-Reply-To: Your message of "Sun, 04 Jan 2009 09:57:01 EST." <4960CE3D.4080005@erols.com> Message-ID: <64927.1231085917@critter.freebsd.dk> In message <4960CE3D.4080005 at erols.com>, Chuck Harris writes: >> time_t is better defined as: >> >> d * 86400 + min(rs, 86399) >> >> where: >> d = Number of complete days since 1970-01-01H00:00:00Z >> rs = number of seconds since UTC midnight. >> >> Eliminating leapseconds would make it correct however. > >I believe your use of the phrase "make it correct" shows your bias >towards removing the leap second corrections from UTC. This is my >bias as well. Correct, I don't think leap seconds provide any benefit that come close to the problems they cause, and I see the cost of fixing POSIX and auditing all relevant apps after such a change as totally pointless time & effort spent. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From magnus at rubidium.dyndns.org Sun Jan 4 21:55:28 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sun, 04 Jan 2009 22:55:28 +0100 Subject: [time-nuts] Leap Quirks In-Reply-To: <4960C988.6090005@erols.com> References: <28089.1231017864@critter.freebsd.dk> <4960027E.1000103@erols.com> <4960079F.1030803@rubidium.dyndns.org> <4960C988.6090005@erols.com> Message-ID: <49613050.6030503@rubidium.dyndns.org> Chuck Harris skrev: > One of us is confused about what time_t is... I think it is > you. I know of three different ways to interpret it. They fit different purposes. > time_t is a 32 bit (depreciated), or 64 bit integer that contains > the number of seconds since the epoch. It is not to be adjusted > for leap seconds according to POSIX, and unix convention. This is one, no two, of the interpretations I know of. > Everything to do with UTC and leap seconds is a library function > in most unixes that translates the leap second free time_t into > the leap second adjusted UTC. Exactly where? Do please tell me what the unified way of getting UTC time is. Oh, when there is a leap second it needs to give correct counting as well. Joe has in private conversations pointed out a POSIX interface which could be used. > Again, are you telling me that time_t is getting adjusted for leap > seconds? If so, when did this change? To the best of _my_ knowledge (which can be wrong) this is what is being done in practice, which is outside of the POSIX standard, but has the effect that 00:00:00 always midnight, which POSIX needs. This is a third interpretation... If somebody (say PHK) got out and slapped my face and say this is a total misunderstanding, this is pretty good after all. If this practice does exist, then we still have three interpretations and they are in conflict with each other even after giving up on introducing leap seconds. So we have two or three interpretation of the POSIX timescale, one with pure SI seconds, one with rubber seconds up till 1972-00-00T00:00:00Z and then SI seconds and a third which is like the second but re-aligned on each leap second event so that midnights match. This is only an issue if the POSIX scale is under external control. And yes, do tell me how I get UTC on all platforms. Regardless, this just shows how complex the issue is. There seems that there is no "correct" interpretation that everyone can agree with as a basis. If there is I'll be much happier and go away a bit wiser. Cheers, Magnus From tvb at LeapSecond.com Sun Jan 4 23:39:07 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Sun, 4 Jan 2009 15:39:07 -0800 Subject: [time-nuts] Leap Quirks References: <28089.1231017864@critter.freebsd.dk><4960027E.1000103@erols.com> <4960079F.1030803@rubidium.dyndns.org><4960C988.6090005@erols.com> <49613050.6030503@rubidium.dyndns.org> Message-ID: Now that the Leap Quirks thread has also morphed into a discussion about UTC, time_t, and POSIX it should really be moved over to the LEAPSECS list. The postings are good, don't get me wrong, and that's all the more reason they should be posted there instead of time-nuts. Please? /tvb From eric.fort at gmail.com Mon Jan 5 00:27:13 2009 From: eric.fort at gmail.com (Eric Fort) Date: Sun, 4 Jan 2009 16:27:13 -0800 Subject: [time-nuts] Leap Quirks In-Reply-To: References: <28089.1231017864@critter.freebsd.dk> <4960027E.1000103@erols.com> <4960079F.1030803@rubidium.dyndns.org> <4960C988.6090005@erols.com> <49613050.6030503@rubidium.dyndns.org> Message-ID: <2ad2af430901041627j6d25dcadq91709be2926eba79@mail.gmail.com> I've seen many referencecs to the leapsecs list. would someone please tell where to find out more about and subscribe to this list? Thanks, Eric On Sun, Jan 4, 2009 at 3:39 PM, Tom Van Baak wrote: > Now that the Leap Quirks thread has also morphed into a > discussion about UTC, time_t, and POSIX it should really > be moved over to the LEAPSECS list. The postings are > good, don't get me wrong, and that's all the more reason > they should be posted there instead of time-nuts. Please? > > /tvb > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From cfharris at erols.com Mon Jan 5 00:43:48 2009 From: cfharris at erols.com (Chuck Harris) Date: Sun, 04 Jan 2009 19:43:48 -0500 Subject: [time-nuts] Leap Quirks In-Reply-To: <49613050.6030503@rubidium.dyndns.org> References: <28089.1231017864@critter.freebsd.dk> <4960027E.1000103@erols.com> <4960079F.1030803@rubidium.dyndns.org> <4960C988.6090005@erols.com> <49613050.6030503@rubidium.dyndns.org> Message-ID: <496157C4.2050300@erols.com> Magnus Danielson wrote: > Chuck Harris skrev: >> One of us is confused about what time_t is... I think it is >> you. > > I know of three different ways to interpret it. They fit different purposes. > >> time_t is a 32 bit (depreciated), or 64 bit integer that contains >> the number of seconds since the epoch. It is not to be adjusted >> for leap seconds according to POSIX, and unix convention. > > This is one, no two, of the interpretations I know of. Good! >> Everything to do with UTC and leap seconds is a library function >> in most unixes that translates the leap second free time_t into >> the leap second adjusted broken-down-time UTC. > > Exactly where? Do please tell me what the unified way of getting UTC > time is. Oh, when there is a leap second it needs to give correct > counting as well. If the unix supports leap second, which usually requires ntp, gmtime() should report the UTC time correctly. > Joe has in private conversations pointed out a POSIX interface which > could be used. > >> Again, are you telling me that time_t is getting adjusted for leap >> seconds? If so, when did this change? > > To the best of _my_ knowledge (which can be wrong) this is what is being > done in practice, which is outside of the POSIX standard, but has the > effect that 00:00:00 always midnight, which POSIX needs. This is a third > interpretation... Yes, but this is not UTC midnight, but unix time or POSIX time midnight. Unix time midnight, and POSIX time midnight drift from UTC midnight as the leap seconds get added or removed. Some of the libc functions that convert time_t to broken down time convert to UTC, and others convert to POSIX/Unix time... which is, I guess 24 seconds fast? Ntpd doesn't mess with time_t when it makes its leap second corrections, but rather messes with tables and counters used by gmtime(), etal.. The only time that ntpd messes with time_t is to slew it so that your system's time_t is the same as everyone elses... (The number of si seconds since the epoch without adjustments for leap seconds.) > If somebody (say PHK) got out and slapped my face and say this is a > total misunderstanding, this is pretty good after all. If this practice > does exist, then we still have three interpretations and they are in > conflict with each other even after giving up on introducing leap > seconds. So we have two or three interpretation of the POSIX timescale, > one with pure SI seconds, one with rubber seconds up till > 1972-00-00T00:00:00Z and then SI seconds and a third which is like the > second but re-aligned on each leap second event so that midnights match. > > This is only an issue if the POSIX scale is under external control. > > And yes, do tell me how I get UTC on all platforms. On all platforms? Even my VCR? That's a tall order. On unix platforms, gmtime() will do the trick... assuming that leap seconds are supported. > > Regardless, this just shows how complex the issue is. There seems that > there is no "correct" interpretation that everyone can agree with as a > basis. If there is I'll be much happier and go away a bit wiser. The only interpretation that would make me happy is one where UTC no longer requires leap seconds... but that is a different subject. -Chuck Harris From bruce.griffiths at xtra.co.nz Mon Jan 5 01:00:25 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 05 Jan 2009 14:00:25 +1300 Subject: [time-nuts] Leap Quirks In-Reply-To: <2ad2af430901041627j6d25dcadq91709be2926eba79@mail.gmail.com> References: <28089.1231017864@critter.freebsd.dk> <4960027E.1000103@erols.com> <4960079F.1030803@rubidium.dyndns.org> <4960C988.6090005@erols.com> <49613050.6030503@rubidium.dyndns.org> <2ad2af430901041627j6d25dcadq91709be2926eba79@mail.gmail.com> Message-ID: <49615BA9.3090905@xtra.co.nz> Eric Fort wrote: > I've seen many referencecs to the leapsecs list. would someone please > tell where to find out more about and subscribe to this list? > > Thanks, > > Eric > > On Sun, Jan 4, 2009 at 3:39 PM, Tom Van Baak wrote: > >> Now that the Leap Quirks thread has also morphed into a >> discussion about UTC, time_t, and POSIX it should really >> be moved over to the LEAPSECS list. The postings are >> good, don't get me wrong, and that's all the more reason >> they should be posted there instead of time-nuts. Please? >> >> /tvb >> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Subscribe at: http://six.pairlist.net/mailman/listinfo/leapsecs Bruce From ch at murgatroid.com Mon Jan 5 02:56:53 2009 From: ch at murgatroid.com (christopher hoover) Date: Sun, 4 Jan 2009 18:56:53 -0800 Subject: [time-nuts] good book on the history of calendars? Message-ID: <01e701c96ee1$43f77e80$cbe67b80$@com> We have the wonderful Dava Sobel book on longitude and Harrison. I'm hoping to find something equally as excellent and accessible on calendars. Can anyone recommend a good book on the development of calendars, ideally from Caesar on? -ch From rdarlington at gmail.com Mon Jan 5 03:16:18 2009 From: rdarlington at gmail.com (Robert Darlington) Date: Sun, 4 Jan 2009 20:16:18 -0700 Subject: [time-nuts] good book on the history of calendars? In-Reply-To: <01e701c96ee1$43f77e80$cbe67b80$@com> References: <01e701c96ee1$43f77e80$cbe67b80$@com> Message-ID: So you want to exclude all of the interesting parts of calendar history? I personally think most of the fun stuff happened 6-10 thousand years before that period. On Sun, Jan 4, 2009 at 7:56 PM, christopher hoover wrote: > We have the wonderful Dava Sobel book on longitude and Harrison. I'm > hoping to find something equally as excellent and accessible on calendars. > > > > Can anyone recommend a good book on the development of calendars, ideally > from Caesar on? > > > > -ch > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From magnus at rubidium.dyndns.org Mon Jan 5 04:08:22 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Mon, 05 Jan 2009 05:08:22 +0100 Subject: [time-nuts] good book on the history of calendars? In-Reply-To: <01e701c96ee1$43f77e80$cbe67b80$@com> References: <01e701c96ee1$43f77e80$cbe67b80$@com> Message-ID: <496187B6.1000303@rubidium.dyndns.org> christopher hoover skrev: > We have the wonderful Dava Sobel book on longitude and Harrison. I'm > hoping to find something equally as excellent and accessible on calendars. > > > > Can anyone recommend a good book on the development of calendars, ideally > from Caesar on? There is one by Lance Latham called "Standard C Date/Time Library; Programming the World's Calendars and Clocks" ISBN 0-87930-496-0 While I am quite sure this book can be shot down for many reasons, it does attempts to cover many calendars and their revisions. It also attempts to do this in such a detail that a software implementation is possible and then do it. Target is in C and there is a companion CDROM. Just to give you a hint, it describes subjects such as the Khwarizmian Calendar (structure 12x30 + 5 days) and Alexandrian Style calendars (structure 12x30 + 5 or 6 days, forming a quad of 365 + 365 + 366 + 365 years, thus including leap year). etc. The book has a rather lengthy reference list in the back and discusses to some extent the mappings. It attempts to use Julian dates as reference between various calender dates. If you wish to implement a varity of calendars, this book should be a good startingpoint, if nothing else. Cheers, Magnus From swingbyte at exemail.com.au Mon Jan 5 12:22:26 2009 From: swingbyte at exemail.com.au (swingbyte) Date: Mon, 05 Jan 2009 23:22:26 +1100 Subject: [time-nuts] good book on the history of calendars? In-Reply-To: <496187B6.1000303@rubidium.dyndns.org> References: <01e701c96ee1$43f77e80$cbe67b80$@com> <496187B6.1000303@rubidium.dyndns.org> Message-ID: <4961FB82.8060906@exemail.com.au> > christopher hoover skrev: > >> We have the wonderful Dava Sobel book on longitude and Harrison. I'm >> hoping to find something equally as excellent and accessible on calendars. >> >> >> >> Can anyone recommend a good book on the development of calendars, ideally >> from Caesar on? >> Another book you might like to look into is one in the series of books about China written by Joeseph Neadham. He wrote huge volumes about Chinese technology and inventions with a book about astronomy and calenders. To the ancient Chinese the calender was very important for the mainly agrarian society and so the emperor in power issued very precise calenders. You mat find something on Gutenberg. Tim From w3kl at w3kl.com Mon Jan 5 15:23:04 2009 From: w3kl at w3kl.com (w3kl at w3kl.com) Date: Mon, 5 Jan 2009 07:23:04 -0800 (PST) Subject: [time-nuts] Synthesizer Unit (A1) For An HP 8061B Message-ID: <935295.73170.qm@web35407.mail.mud.yahoo.com> All: ? You may recall that I posted a series of questions several months ago regarding my HP 8061B. ? In summary, I was finding that the system would appear to lock but the continuous operation LED would not come on. ? Several people who frequent this board offered some very good suggestions.? Over the holiday, I immersed myself in the problem and have finally narrowed down the part of the system that isn't operaing: ? I am finding that, based on the manual, the synthesizer is locking but the circuit used to report a synthesizer lock to the logic board is not behaving properly. ? I don't have the schematic in front of me, but the circuit involves Q23 (a JFET) used to amplify the error signal in the loop followed by Q24, Q25, and Q27 (all NPNs).? If the system locks, Q27 (emitter follower) is supposed to go "low" (<1.5 V) but in my case, despite the fact that the input to Q23 appears to be DC (indicating a lock), Q27 is actually at 6V. ? I have not dived into diagnosing the problem in detail (will try to get to it this weekend). ? However, has anyone else seen this problem?? If so, what did you do to resolve? ? Finally, does anyone have a spare A1 board for an 8061B that they would be willing to sell me? ? Thanks! ? Jeff Jeffrey K. Okamitsu, PhD, MBA +1-609-638-5402 From boyscout at gmail.com Mon Jan 5 19:31:18 2009 From: boyscout at gmail.com (Matt Ettus) Date: Mon, 5 Jan 2009 11:31:18 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? Message-ID: I am working with someone who needs to have time synchronized reception of signals in various locations which are separated by less than 100 km. This is a situation similar to VLBI, but since the distances are shorter, the center frequencies are lower, and the integration times are much shorter, we probably don't need a Hydrogen Maser, and the application can't afford one. The real question is whether we can get away with a GPS disciplined OCXO or whether we would need to use a Rubidium. Does anyone have any data on the relative frequency and/or phase errors of the 10 MHz reference out, and relative PPS time errors of any commonly available GPSDOs? Absolute error to UTC and true 10 MHz don't really matter, as long as both devices have the same error. Just data comparing 2 units with antennas right next to each other would probably be fine. The other concern, of course, is that even if both units were very close, they will be exposed to slightly different environmental conditions (different A/C settings, different cycling times, etc.). Are there any good papers discussing this subject? Any data out there? Said -- have you measured this sort of thing on the Fury? Thanks, Matt From james.p.lux at jpl.nasa.gov Mon Jan 5 20:13:00 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Mon, 5 Jan 2009 12:13:00 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus > Sent: Monday, January 05, 2009 11:31 AM > To: Discussion of precise time and frequency measurement > Subject: [time-nuts] Common sky pps errors for any GPSDOs? > > I am working with someone who needs to have time synchronized > reception of signals in various locations which are separated > by less than 100 km. This is a situation similar to VLBI, > but since the distances are shorter, the center frequencies > are lower, and the integration times are much shorter, we > probably don't need a Hydrogen Maser, and the application > can't afford one. > > The real question is whether we can get away with a GPS > disciplined OCXO or whether we would need to use a Rubidium. > Does anyone have any data on the relative frequency and/or > phase errors of the 10 MHz reference out, and relative PPS > time errors of any commonly available GPSDOs? Isn't that just the Allan Deviation data? Symmetricom has datasheets on their website for their various modules. They have a GPS discplined quartz oscillator in several flavors. http://www.symmetricom.com/media/files/downloads/product-datasheets/ds%20XLi%20Options%202.pdf Something else to consider is doing post processing.. Use a nice quiet 10MHz oscillator for your source/sampling clock, and record the 1PPS from the GPS receiver as well as your unknown, then figure out after the fact what the oscillator was doing. Jim From bruce.griffiths at xtra.co.nz Mon Jan 5 21:54:18 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 06 Jan 2009 10:54:18 +1300 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: <4962818A.4050106@xtra.co.nz> Matt Ettus wrote: > I am working with someone who needs to have time synchronized > reception of signals in various locations which are separated by less > than 100 km. This is a situation similar to VLBI, but since the > distances are shorter, the center frequencies are lower, and the > integration times are much shorter, we probably don't need a Hydrogen > Maser, and the application can't afford one. > > The real question is whether we can get away with a GPS disciplined > OCXO or whether we would need to use a Rubidium. Does anyone have any > data on the relative frequency and/or phase errors of the 10 MHz > reference out, and relative PPS time errors of any commonly available > GPSDOs? Absolute error to UTC and true 10 MHz don't really matter, as > long as both devices have the same error. Just data comparing 2 units > with antennas right next to each other would probably be fine. > > The other concern, of course, is that even if both units were very > close, they will be exposed to slightly different environmental > conditions (different A/C settings, different cycling times, etc.). > > Are there any good papers discussing this subject? Any data out there? > > Said -- have you measured this sort of thing on the Fury? > > Thanks, > Matt > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Matt If the application is somewhat analogous to VLBI, then the maximum (uncorrectable ie random) allowable carrier frequency phase errors between receivers depends on the integration time. Maximum integration times for VLBI are typically 10,000 sec or less, with corresponding relative ADEV (after correction for drift etc) on the order of 1E-14 (or better) @ 10,000 sec for a carrier frequency of a few GHz. What is the integration time in your application? What is the carrier frequency? For short integration times most rubidium standards are much noisier than a good OCXO. GPS carrier phase techniques will allow lower noise comparisons of LO phase differences than a GPS derived PPS based system. Bruce From SAIDJACK at aol.com Mon Jan 5 21:58:55 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Mon, 5 Jan 2009 16:58:55 EST Subject: [time-nuts] Common sky pps errors for any GPSDOs? Message-ID: Hi Matt, on Fury we typically see the 1PPS aligned to within +/-25ns or so without calibration when two units use the same antenna feed. There is a good paper on the M12+ receiver's accuracy from Synergy/NIST, they tested five receivers against UTC (at UTC!!). They came up with a baseline error of 2ns over 3 weeks when the units are calibrated. You can find the paper on our website: _http://www.jackson-labs.com/docs/Motorola_M12.pdf_ (http://www.jackson-labs.com/docs/Motorola_M12.pdf) We did not do tests over longer baselines yet. bye, Said In a message dated 1/5/2009 11:32:06 Pacific Standard Time, boyscout at gmail.com writes: The other concern, of course, is that even if both units were very close, they will be exposed to slightly different environmental conditions (different A/C settings, different cycling times, etc.). Are there any good papers discussing this subject? Any data out there? Said -- have you measured this sort of thing on the Fury? Thanks, Matt From boyscout at gmail.com Mon Jan 5 22:28:11 2009 From: boyscout at gmail.com (Matt Ettus) Date: Mon, 5 Jan 2009 14:28:11 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: On Mon, Jan 5, 2009 at 12:13 PM, Lux, James P wrote: > > >> -----Original Message----- >> From: time-nuts-bounces at febo.com >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus >> Sent: Monday, January 05, 2009 11:31 AM >> To: Discussion of precise time and frequency measurement >> Subject: [time-nuts] Common sky pps errors for any GPSDOs? >> >> I am working with someone who needs to have time synchronized >> reception of signals in various locations which are separated >> by less than 100 km. This is a situation similar to VLBI, >> but since the distances are shorter, the center frequencies >> are lower, and the integration times are much shorter, we >> probably don't need a Hydrogen Maser, and the application >> can't afford one. >> >> The real question is whether we can get away with a GPS >> disciplined OCXO or whether we would need to use a Rubidium. >> Does anyone have any data on the relative frequency and/or >> phase errors of the 10 MHz reference out, and relative PPS >> time errors of any commonly available GPSDOs? > > Isn't that just the Allan Deviation data? Symmetricom has datasheets on their website for their various modules. They have a GPS discplined quartz oscillator in several flavors. > http://www.symmetricom.com/media/files/downloads/product-datasheets/ds%20XLi%20Options%202.pdf I don't think Allan Deviation is the right measure. First, standard Allan dev numbers won't take environmental differences into account. Also, isn't Allan Dev measured vs. a better reference? > Something else to consider is doing post processing.. Use a nice quiet 10MHz oscillator for your source/sampling clock, and record the 1PPS from the GPS receiver as well as your unknown, then figure out after the fact what the oscillator was doing. Unfortunately, post processing isn't possible in this app, since it is a real-time communications application. Thanks, Matt From boyscout at gmail.com Mon Jan 5 22:31:57 2009 From: boyscout at gmail.com (Matt Ettus) Date: Mon, 5 Jan 2009 14:31:57 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: <4962818A.4050106@xtra.co.nz> References: <4962818A.4050106@xtra.co.nz> Message-ID: On Mon, Jan 5, 2009 at 1:54 PM, Bruce Griffiths wrote: > > If the application is somewhat analogous to VLBI, then the maximum > (uncorrectable ie random) allowable carrier frequency phase errors > between receivers depends on the integration time. > Maximum integration times for VLBI are typically 10,000 sec or less, > with corresponding relative ADEV (after correction for drift etc) on the > order of 1E-14 (or better) @ 10,000 sec for a carrier frequency of a few > GHz. > > What is the integration time in your application? We are trying to receive data which is modulated at rates which vary, but are in the 100 Hz to 100 kHz range, so the integration times are very short, all below 10ms. > What is the carrier frequency? 30 MHz and below for now, but we'd like to be able to go as high as 500 MHz or so. > For short integration times most rubidium standards are much noisier > than a good OCXO. > GPS carrier phase techniques will allow lower noise comparisons of LO > phase differences than a GPS derived PPS based system. Don't the Rb standards end up disciplining an OCXO so you get the benefit of the crystal at the shortest integration times? Thanks, Matt From james.p.lux at jpl.nasa.gov Mon Jan 5 22:56:54 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Mon, 5 Jan 2009 14:56:54 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus > Sent: Monday, January 05, 2009 2:28 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Common sky pps errors for any GPSDOs? > > On Mon, Jan 5, 2009 at 12:13 PM, Lux, James P > wrote: > > > > > >> -----Original Message----- > >> From: time-nuts-bounces at febo.com > >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus > >> Sent: Monday, January 05, 2009 11:31 AM > >> To: Discussion of precise time and frequency measurement > >> Subject: [time-nuts] Common sky pps errors for any GPSDOs? > >> > >> I am working with someone who needs to have time synchronized > >> reception of signals in various locations which are > separated by less > >> than 100 km. This is a situation similar to VLBI, but since the > >> distances are shorter, the center frequencies are lower, and the > >> integration times are much shorter, we probably don't need > a Hydrogen > >> Maser, and the application can't afford one. > >> > >> The real question is whether we can get away with a GPS > disciplined > >> OCXO or whether we would need to use a Rubidium. > >> Does anyone have any data on the relative frequency and/or phase > >> errors of the 10 MHz reference out, and relative PPS time > errors of > >> any commonly available GPSDOs? > > > > Isn't that just the Allan Deviation data? Symmetricom has > datasheets on their website for their various modules. They > have a GPS discplined quartz oscillator in several flavors. > > > http://www.symmetricom.com/media/files/downloads/product-datasheets/ds > > %20XLi%20Options%202.pdf > > > I don't think Allan Deviation is the right measure. First, > standard Allan dev numbers won't take environmental > differences into account. > Also, isn't Allan Dev measured vs. a better reference? Environmental differences, as in the environment of the box? Or the propagation path? For the box, the short term is going to be dominated by the OCXO, isn't it? So it's relatively environment immune. Allan Dev is the box against itself,in the adjacent time slice, but wouldn't that be pretty similar to a box against an identical box, because the noise is assumed to be uncorrelated from time slice to time slice. > > > > Something else to consider is doing post processing.. Use a > nice quiet 10MHz oscillator for your source/sampling clock, > and record the 1PPS from the GPS receiver as well as your > unknown, then figure out after the fact what the oscillator was doing. > > > Unfortunately, post processing isn't possible in this app, > since it is a real-time communications application. OH.. This is like doing a distributed phased array for EME (or, as N5BF wants to do, EVE) On the basis of your other mail a few minutes later, you're looking at very short integration time (e.g. 10ms), so wouldn't phase noise be your more appropriate thing to look at, and for that, you're almost certainly looking at the basic properties of the quartz oscillator. OTOH, if you're trying to a phased uplink sort of thing, then you are concerned about longer time intervals (e.g. you want the relative phases of Tx1 and Tx2 to be constant over intervals of seconds) From bruce.griffiths at xtra.co.nz Mon Jan 5 23:02:51 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 06 Jan 2009 12:02:51 +1300 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: <4962818A.4050106@xtra.co.nz> Message-ID: <4962919B.8060107@xtra.co.nz> Matt Matt Ettus wrote: > On Mon, Jan 5, 2009 at 1:54 PM, Bruce Griffiths > wrote: > > >> If the application is somewhat analogous to VLBI, then the maximum >> (uncorrectable ie random) allowable carrier frequency phase errors >> between receivers depends on the integration time. >> Maximum integration times for VLBI are typically 10,000 sec or less, >> with corresponding relative ADEV (after correction for drift etc) on the >> order of 1E-14 (or better) @ 10,000 sec for a carrier frequency of a few >> GHz. >> >> What is the integration time in your application? >> > > We are trying to receive data which is modulated at rates which vary, > but are in the 100 Hz to 100 kHz range, so the integration times are > very short, all below 10ms. > > >> What is the carrier frequency? >> > > 30 MHz and below for now, but we'd like to be able to go as high as > 500 MHz or so. > > > What's your tolerance for phase variations between a pair of LOs? Its on the order of 50 degrees or so for VLBI. At 500MHz this corresponds to about 140ps. The corresponding relative ADEV is around 1E-8 @ tau = 10ms. Almost any good crystal oscillator can achieve this. >> For short integration times most rubidium standards are much noisier >> than a good OCXO. >> GPS carrier phase techniques will allow lower noise comparisons of LO >> phase differences than a GPS derived PPS based system. >> > > Don't the Rb standards end up disciplining an OCXO so you get the > benefit of the crystal at the shortest integration times? > > Yes, but compare their resultant short term ADEV with that of a good OCXO. They can be 1-2 orders of magnitude worse than the better OCXOs. Most of them use a relatively short time constant FLL to steer the the crystal oscillator to the passive Rubidium cell. A few (typically older more expensive ones) can be relatively quiet. An external low noise OCXO phase locked to the rubidium standard with a relatively long time constant can be used achieve lower ADEV at sort averaging times if the operating environment allows this. Whether any of this is necessary depends on your applications tolerance to short term phase variations between LOs. > Thanks, > Matt > > Bruce From bruce.griffiths at xtra.co.nz Mon Jan 5 23:03:00 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 06 Jan 2009 12:03:00 +1300 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: <496291A4.5020103@xtra.co.nz> Matt Ettus wrote: > On Mon, Jan 5, 2009 at 12:13 PM, Lux, James P wrote: > >> >>> -----Original Message----- >>> From: time-nuts-bounces at febo.com >>> [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus >>> Sent: Monday, January 05, 2009 11:31 AM >>> To: Discussion of precise time and frequency measurement >>> Subject: [time-nuts] Common sky pps errors for any GPSDOs? >>> >>> I am working with someone who needs to have time synchronized >>> reception of signals in various locations which are separated >>> by less than 100 km. This is a situation similar to VLBI, >>> but since the distances are shorter, the center frequencies >>> are lower, and the integration times are much shorter, we >>> probably don't need a Hydrogen Maser, and the application >>> can't afford one. >>> >>> The real question is whether we can get away with a GPS >>> disciplined OCXO or whether we would need to use a Rubidium. >>> Does anyone have any data on the relative frequency and/or >>> phase errors of the 10 MHz reference out, and relative PPS >>> time errors of any commonly available GPSDOs? >>> >> Isn't that just the Allan Deviation data? Symmetricom has datasheets on their website for their various modules. They have a GPS discplined quartz oscillator in several flavors. >> http://www.symmetricom.com/media/files/downloads/product-datasheets/ds%20XLi%20Options%202.pdf >> > > > I don't think Allan Deviation is the right measure. First, standard > Allan dev numbers won't take environmental differences into account. > Also, isn't Allan Dev measured vs. a better reference? > > > Not so, ADEV actually includes environmental effects during the measurement. However, data sheet ADEV specs may have been obtained in a more closely controlled environment that your intended use. ADEV is measured between oscillators one of which may be better than the other. The corresponding ADEV of each oscillator may then be derived from the relative ADEV data if some assumptions are made. One can use the datasheet ADEV to estimate worst case ADEV for pairs of such oscillators. To gauge the relative ADEV between oscillator pairs in your environment you will need to make some measurements as the various unspecified thermal time constants of the OCXO will be significant. >> Something else to consider is doing post processing.. Use a nice quiet 10MHz oscillator for your source/sampling clock, and record the 1PPS from the GPS receiver as well as your unknown, then figure out after the fact what the oscillator was doing. >> > > > Unfortunately, post processing isn't possible in this app, since it is > a real-time communications application. > > Thanks, > Matt > Bruce From ch at murgatroid.com Tue Jan 6 01:50:57 2009 From: ch at murgatroid.com (christopher hoover) Date: Mon, 5 Jan 2009 17:50:57 -0800 Subject: [time-nuts] good book on the history of calendars? In-Reply-To: References: Message-ID: <005001c96fa1$3835af70$a8a10e50$@com> Robert Darlington wrote: > So you want to exclude all of the interesting parts of calendar > history? I personally think most of the fun stuff happened 6-10 > thousand years before that period. I'll take what I can get. I'm not uninterested in earlier calendars, but, yes, I am especially interested in modern developments, for some suitable definition of "modern." :-) -ch From boyscout at gmail.com Tue Jan 6 02:04:52 2009 From: boyscout at gmail.com (Matt Ettus) Date: Mon, 5 Jan 2009 18:04:52 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: On Mon, Jan 5, 2009 at 2:56 PM, Lux, James P wrote: > >> -----Original Message----- >> From: time-nuts-bounces at febo.com >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus >> Sent: Monday, January 05, 2009 2:28 PM >> To: Discussion of precise time and frequency measurement >> Subject: Re: [time-nuts] Common sky pps errors for any GPSDOs? >> >> On Mon, Jan 5, 2009 at 12:13 PM, Lux, James P >> wrote: >> > >> > >> >> -----Original Message----- >> >> From: time-nuts-bounces at febo.com >> >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Matt Ettus >> >> Sent: Monday, January 05, 2009 11:31 AM >> >> To: Discussion of precise time and frequency measurement >> >> Subject: [time-nuts] Common sky pps errors for any GPSDOs? >> >> >> >> I am working with someone who needs to have time synchronized >> >> reception of signals in various locations which are >> separated by less >> >> than 100 km. This is a situation similar to VLBI, but since the >> >> distances are shorter, the center frequencies are lower, and the >> >> integration times are much shorter, we probably don't need >> a Hydrogen >> >> Maser, and the application can't afford one. >> >> >> >> The real question is whether we can get away with a GPS >> disciplined >> >> OCXO or whether we would need to use a Rubidium. >> >> Does anyone have any data on the relative frequency and/or phase >> >> errors of the 10 MHz reference out, and relative PPS time >> errors of >> >> any commonly available GPSDOs? >> > >> > Isn't that just the Allan Deviation data? Symmetricom has >> datasheets on their website for their various modules. They >> have a GPS discplined quartz oscillator in several flavors. >> > >> http://www.symmetricom.com/media/files/downloads/product-datasheets/ds >> > %20XLi%20Options%202.pdf >> >> >> I don't think Allan Deviation is the right measure. First, >> standard Allan dev numbers won't take environmental >> differences into account. >> Also, isn't Allan Dev measured vs. a better reference? > > Environmental differences, as in the environment of the box? Or the propagation path? > For the box, the short term is going to be dominated by the OCXO, isn't it? So it's relatively environment immune. > > Allan Dev is the box against itself,in the adjacent time slice, but wouldn't that be pretty similar to a box against an identical box, because the noise is assumed to be uncorrelated from time slice to time slice. > > > >> >> >> > Something else to consider is doing post processing.. Use a >> nice quiet 10MHz oscillator for your source/sampling clock, >> and record the 1PPS from the GPS receiver as well as your >> unknown, then figure out after the fact what the oscillator was doing. >> >> >> Unfortunately, post processing isn't possible in this app, >> since it is a real-time communications application. > > OH.. This is like doing a distributed phased array for EME (or, as N5BF wants to do, EVE) Yes, a very similar application. > > On the basis of your other mail a few minutes later, you're looking at very short integration time (e.g. 10ms), so wouldn't phase noise be your more appropriate thing to look at, and for that, you're almost certainly looking at the basic properties of the quartz oscillator. Well, basically, I need to be able to coherently add signals from multiple locations without first looking at those signals to determine what the phase error is. > > OTOH, if you're trying to a phased uplink sort of thing, then you are concerned about longer time intervals (e.g. you want the relative phases of Tx1 and Tx2 to be constant over intervals of seconds) Yes, we would need the relative phase to be constant over time scales up through about a second or two. Matt From boyscout at gmail.com Tue Jan 6 02:21:35 2009 From: boyscout at gmail.com (Matt Ettus) Date: Mon, 5 Jan 2009 18:21:35 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: <4962919B.8060107@xtra.co.nz> References: <4962818A.4050106@xtra.co.nz> <4962919B.8060107@xtra.co.nz> Message-ID: On Mon, Jan 5, 2009 at 3:02 PM, Bruce Griffiths wrote: > Matt > > Matt Ettus wrote: >> On Mon, Jan 5, 2009 at 1:54 PM, Bruce Griffiths >> wrote: >> >> >>> If the application is somewhat analogous to VLBI, then the maximum >>> (uncorrectable ie random) allowable carrier frequency phase errors >>> between receivers depends on the integration time. >>> Maximum integration times for VLBI are typically 10,000 sec or less, >>> with corresponding relative ADEV (after correction for drift etc) on the >>> order of 1E-14 (or better) @ 10,000 sec for a carrier frequency of a few >>> GHz. >>> >>> What is the integration time in your application? >>> >> >> We are trying to receive data which is modulated at rates which vary, >> but are in the 100 Hz to 100 kHz range, so the integration times are >> very short, all below 10ms. >> >> >>> What is the carrier frequency? >>> >> >> 30 MHz and below for now, but we'd like to be able to go as high as >> 500 MHz or so. >> >> >> > What's your tolerance for phase variations between a pair of LOs? > Its on the order of 50 degrees or so for VLBI. > At 500MHz this corresponds to about 140ps. > The corresponding relative ADEV is around 1E-8 @ tau = 10ms. > Almost any good crystal oscillator can achieve this. As you said, our ADEV requirements are pretty loose and could be met by any decent crystal. But Said just told us that he sees about 25ns difference between units, which is about 180 times worse than 140 ps. In VLBI I think that they can deal with an unknown phase error between the two LOs as long as that phase error remains relatively constant over the period of integration. That is why they care about ADEV. They just correlate the two signals, and subtract out that constant phase error. My problem is that we can't just do that in this application. We need to know that phase error a priori. Matt From richiem at hughes.net Tue Jan 6 02:43:56 2009 From: richiem at hughes.net (Richard Moore) Date: Mon, 5 Jan 2009 18:43:56 -0800 Subject: [time-nuts] ESI 290A Z-bridge schematics needed In-Reply-To: References: Message-ID: Hi, nuts: I have an operating manual for my ESI 290A impedance bridge, but I need the schematics. If any of you have them or know where I can get them, please drop me a line. Best, Dick Moore From bruce.griffiths at xtra.co.nz Tue Jan 6 02:51:23 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 06 Jan 2009 15:51:23 +1300 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: <4962818A.4050106@xtra.co.nz> <4962919B.8060107@xtra.co.nz> Message-ID: <4962C72B.8030109@xtra.co.nz> Matt Matt Ettus wrote: > On Mon, Jan 5, 2009 at 3:02 PM, Bruce Griffiths > wrote: > >> Matt >> >> Matt Ettus wrote: >> >>> On Mon, Jan 5, 2009 at 1:54 PM, Bruce Griffiths >>> wrote: >>> >>> >>> >>>> If the application is somewhat analogous to VLBI, then the maximum >>>> (uncorrectable ie random) allowable carrier frequency phase errors >>>> between receivers depends on the integration time. >>>> Maximum integration times for VLBI are typically 10,000 sec or less, >>>> with corresponding relative ADEV (after correction for drift etc) on the >>>> order of 1E-14 (or better) @ 10,000 sec for a carrier frequency of a few >>>> GHz. >>>> >>>> What is the integration time in your application? >>>> >>>> >>> We are trying to receive data which is modulated at rates which vary, >>> but are in the 100 Hz to 100 kHz range, so the integration times are >>> very short, all below 10ms. >>> >>> >>> >>>> What is the carrier frequency? >>>> >>>> >>> 30 MHz and below for now, but we'd like to be able to go as high as >>> 500 MHz or so. >>> >>> >>> >>> >> What's your tolerance for phase variations between a pair of LOs? >> Its on the order of 50 degrees or so for VLBI. >> At 500MHz this corresponds to about 140ps. >> The corresponding relative ADEV is around 1E-8 @ tau = 10ms. >> Almost any good crystal oscillator can achieve this. >> > > As you said, our ADEV requirements are pretty loose and could be met > by any decent crystal. > > But Said just told us that he sees about 25ns difference between > units, which is about 180 times worse than 140 ps. > > That estimate should have been 280ps with a 500MHz LO, however that still doesnt help very much. This is more a function of the timing receiver noise than the characteristics of the OCXOs themselves. You cant expect too much better than that using code phase timing receivers. However at 30MHz a sawtooth corrected M12+T or M12M will get close to the 50 degrees of phase error ( 4.76ns). Using carrier phase techniques you can easily achieve sub 100ps resolution at least for integration times of up to a few minutes. Longer term cycle slips can cause problems. > In VLBI I think that they can deal with an unknown phase error between > the two LOs as long as that phase error remains relatively constant > over the period of integration. That is why they care about ADEV. > They just correlate the two signals, and subtract out that constant > phase error. My problem is that we can't just do that in this > application. We need to know that phase error a priori. > > Matt > > > For the carrier itself absolute phase measurements cant be done. Such phase measurements only have meaning when modulation is present. Bruce From magnus at rubidium.dyndns.org Tue Jan 6 03:13:15 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Tue, 06 Jan 2009 04:13:15 +0100 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: <4962C72B.8030109@xtra.co.nz> References: <4962818A.4050106@xtra.co.nz> <4962919B.8060107@xtra.co.nz> <4962C72B.8030109@xtra.co.nz> Message-ID: <4962CC4B.7060205@rubidium.dyndns.org> > For the carrier itself absolute phase measurements cant be done. > Such phase measurements only have meaning when modulation is present. Alternating modulation frequency may do it for instance. Choosing a set of modulation frequencies being relative prime to each other alows for several readings of alternating cycle ambiguity to be resolved using the Chinese Reminder theorem. Similar set of frequencies can be used, for instance multiple of 10 alows the phase of the lower frequency to determine which of the 10 cycles the next frequency is. However, this is not easilly extendable to carrier frequency cycles, since it would imply a very wide modulation, so for that a chinese reminder approach is of interest. A PRN sequence is just a multiple of these frequencies at the same time. Alternating PRN length could be used for similar purposes of course. Multiple simultaneous PRN sequences can be added upon each other. Using multiple carrier frequencies may also be an interesting option. Consider for instance COFDM which creates a dense set of carriers using IFFT modulation and FFT demodulation. Cheers, Magnus From jltran at worldnet.att.net Tue Jan 6 03:57:47 2009 From: jltran at worldnet.att.net (J. L. Trantham) Date: Mon, 5 Jan 2009 21:57:47 -0600 Subject: [time-nuts] 8657B HET Switch Message-ID: I have an 8657B signal generator that does fine at and above 1030MHz but below that, the level is uneven and down about 10 to 15 dBm. I have traced the (or at least a) problem to a defective HET switch, part number 08657-67102, which switches the outputs to the mixer or to the doubler, depending on the frequency chosen. There is about -3.5 VDC on the connector on the HET switch that comes from J303 on the A6 board that supplies the 0.1 - 129.999999 MHz output when that frequency is selected. This knowledge cost me an 8482A power sensor. I think there is a shorted semiconductor inside the unit. There are two control inputs that are either +12V and -12V or just the reverse, depending on the frequency chosen. I have tracked down a replacement part and it is on the way. However, does anyone have any idea of what is inside the switch? I have been told there are two GASFET switches inside and the GASFET's are obsolete. Assuming that the replacement part solves the problem, I was wondering if it would be possible to disassemble the unit and replace the defective part (assuming I can find NOS parts) or design a new circuit that will fit in the enclosure and serve as a replacement. Does any one have any specific information on the HET switch or a suggestion do deal with the next occurrence of this problem? Thanks in advance. Joe From slburris at gmail.com Tue Jan 6 04:27:56 2009 From: slburris at gmail.com (Scott Burris) Date: Mon, 05 Jan 2009 20:27:56 -0800 Subject: [time-nuts] anyone know anything about an Eldorado 784 10ns Time Meter? Message-ID: <4962DDCC.70108@gmail.com> I picked up this Eldorado 784 meter for $10, primarily because of its Nixie tubes. However, this meter seems to still work. I really hate to harvest Nixies from working equipment. So can anyone tell me if this is an instrument worth saving? It looks like it can do period and time interval measurements. Opened it up, and it appears to be 1971 date coded ICs, some TTL and a bunch I can't identify (maybe house numbered). Was this a good instrument? Anyone happen to have a manual and schematics? Scott From SAIDJACK at aol.com Tue Jan 6 05:27:29 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Tue, 6 Jan 2009 00:27:29 EST Subject: [time-nuts] Common sky pps errors for any GPSDOs? Message-ID: Hi Matt, having 140ps matching of the 1PPS between units is the equivalent of knowing your antenna position to within ~0.14 feet total error max. Thats less than one inch error per antenna! That would require some serious antenna surveying :) This accuracy is impossible to achieve with timing GPS receivers without carrier-phase/post-processing as far as I know. If you are only looking at second-to-second jitter of less than 140ps then we can do this without a problem. Our ADEV at 1s measurement intervalls on the Fury OCXO is about 2E-012, or 2ps. So the pulse to pulse jitter would be much more than an order of magnitude better than you require. On the Fury GPSDO one could get better than ~5ns unit to unit variation rms with proper antenna surveying, and calibration of the 1PPS output in 1ns steps using the 1PPS shift commands. bye, Said In a message dated 1/5/2009 18:22:01 Pacific Standard Time, boyscout at gmail.com writes: But Said just told us that he sees about 25ns difference between units, which is about 180 times worse than 140 ps. In VLBI I think that they can deal with an unknown phase error between the two LOs as long as that phase error remains relatively constant over the period of integration. That is why they care about ADEV. They just correlate the two signals, and subtract out that constant phase error. My problem is that we can't just do that in this application. We need to know that phase error a priori. Matt From tvb at LeapSecond.com Tue Jan 6 05:31:42 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Mon, 5 Jan 2009 21:31:42 -0800 Subject: [time-nuts] anyone know anything about an Eldorado 784 10ns TimeMeter? References: <4962DDCC.70108@gmail.com> Message-ID: >I picked up this Eldorado 784 meter for $10, primarily because of its > Nixie tubes. > However, this meter seems to still work. I really hate to harvest > Nixies from working > equipment. > > So can anyone tell me if this is an instrument worth saving? It looks > like it can do > period and time interval measurements. Opened it up, and it appears to > be 1971 date > coded ICs, some TTL and a bunch I can't identify (maybe house numbered). > > Was this a good instrument? Anyone happen to have a manual and schematics? > > Scott Scott, Some of these old Nixie counters are really cute. Not sure I'd use one for my main counter, but it's fun to have one around just for show, especially if it still works. You can get a op/svc manual for it at: http://www.manualsplus.com/manuals/ELDORADO/784 Worth saving is a subjective question. You see a lot of this old stuff on eBay so it's not rare or anything. Send a photo or two if you have one. /tvb From james.p.lux at jpl.nasa.gov Tue Jan 6 06:01:35 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Mon, 5 Jan 2009 22:01:35 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: Message-ID: On 1/5/09 9:27 PM, "SAIDJACK at aol.com" wrote: > Hi Matt, > > having 140ps matching of the 1PPS between units is the equivalent of knowing > your antenna position to within ~0.14 feet total error max. > > Thats less than one inch error per antenna! > > That would require some serious antenna surveying :) This accuracy is > impossible to achieve with timing GPS receivers without > carrier-phase/post-processing as far as I know. On the other hand, if the antennas aren't moving, then you could spend arbitrarily long surveying the position. Or, if you have stable phase relationships (not necessarily known, but stable), you can do some sort of self survey using am arbitrary receive signal like Bernie Steinberg, et al.,'s work with the Radio Camera at Valley Forge Research Center. There's also been some work with uplink arraying in the Deep Space Network (but, of course, they have masers and optical fibers, etc.) From boyscout at gmail.com Tue Jan 6 06:03:39 2009 From: boyscout at gmail.com (Matt Ettus) Date: Mon, 5 Jan 2009 22:03:39 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: On Mon, Jan 5, 2009 at 9:27 PM, wrote: > Hi Matt, > > having 140ps matching of the 1PPS between units is the equivalent of knowing > your antenna position to within ~0.14 feet total error max. > > Thats less than one inch error per antenna! That makes it sound a lot more difficult than it really is. The vast majority of the error in GPS is systematic, such that two GPS systems with antennas near each other should have highly correlated error. This is the basis of differential GPS. It doesn't matter if the absolute error is hundreds of feet, as long as both devices have the same error. I spent a couple of years nearly a decade ago doing differential GPS for steering heavy equipment. You can get sub-centimeter errors over baselines in the tens of km. Again, this is relative error. Matt From w1ksz at earthlink.net Tue Jan 6 06:05:44 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Tue, 6 Jan 2009 01:05:44 -0500 (EST) Subject: [time-nuts] WANTED: HP 5356A Message-ID: <18907218.1231221944487.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> I need to make some measurements at 8 GHz. Since I have the HP 5355A Plug-In I thought using the 5356A head would be the way to go. Does anyone have one they will part with ? Thanks, Dick, W1KSZ From SAIDJACK at aol.com Tue Jan 6 06:59:18 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Tue, 6 Jan 2009 01:59:18 EST Subject: [time-nuts] Common sky pps errors for any GPSDOs? Message-ID: Hi Matt, I must admit I don't fully understand your requirements. Are you looking for correlation between errors, or absolute UTC accuracy, or short term jitter/wander? If you have two systems with self-surveyed antenna positions, you will likely have 1 - 10 feet of antenna height error in the self survey on the Motorola timing receivers (typically). This position-hold error in itself will give you much more than 140ps error (offset, drift, wander) between the units as satellites fade in and out of solution, even if the units are sitting right next to each other and are seeing the same systemic GPS errors. For example, let's say both units share the same antenna, and after auto-survey one reports it's height as 10 feet MSL, the other unit as 15 feet MSL (M12M's have easily more than 5 feet height error after self-survey). So if you now compare the outputs of the units, satellites directly overhead could cause a 5 feet, or ~5ns error, while sats at the horizon will not be affected by the height error, but rather the long/lat errors (which are much smaller). So unless you have a perfectly surveyed antenna position stored in the two receivers (to within < 1 foot) you will get GPS systemic errors as well as timing errors due to position error - especially due to antenna height errors. When we say units typically have 25ns unit-to-unit variation on the 1PPS on un-calibrated units, then I believe most of this is caused by the auto-survey position errors of the GPS receiver. One could get much better performance by manually entering the exact position-hold position of the antenna, and then calibrating for antenna cable delay (in 1ns steps). This seems to yield down to 2ns performance as reported by Motorola/Synergy/NIST with careful calibration, and using a "proper" GPS timing antenna with multipath choke-ring etc. But again, this requires a perfectly surveyed antenna position, as well as offset correction due to antenna cable length delay. There are also antenna cable length variations due to ambient temperature changes :) Bruce and others had discussed these errors not too long ago. 140ps error (or 70ps per GPSDO unit) may be possible on a long antenna cable just due to temperature changes on the cable.. Lastly, our units seem to have a residual PLL tracking noise floor of down to 1.9ns rms when using a good double oven OCXO as can be seen on the unit running in Mexico using a properly surveyed antenna position: _http://resco.ucol.mx/Fury/gpsstat.htm_ (http://resco.ucol.mx/Fury/gpsstat.htm) Getting 140ps matching offset error between two different units' 1PPS outputs may be tough to achieve. bye, Said In a message dated 1/5/2009 22:04:10 Pacific Standard Time, boyscout at gmail.com writes: That makes it sound a lot more difficult than it really is. The vast majority of the error in GPS is systematic, such that two GPS systems with antennas near each other should have highly correlated error. This is the basis of differential GPS. It doesn't matter if the absolute error is hundreds of feet, as long as both devices have the same error. I spent a couple of years nearly a decade ago doing differential GPS for steering heavy equipment. You can get sub-centimeter errors over baselines in the tens of km. Again, this is relative error. Matt From boyscout at gmail.com Tue Jan 6 07:40:10 2009 From: boyscout at gmail.com (Matt Ettus) Date: Mon, 5 Jan 2009 23:40:10 -0800 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: On Mon, Jan 5, 2009 at 10:59 PM, wrote: > Hi Matt, > > I must admit I don't fully understand your requirements. Are you looking for > correlation between errors, or absolute UTC accuracy, or short term > jitter/wander? > > If you have two systems with self-surveyed antenna positions, you will > likely have 1 - 10 feet of antenna height error in the self survey on the Motorola > timing receivers (typically). > > This position-hold error in itself will give you much more than 140ps error > (offset, drift, wander) between the units as satellites fade in and out of > solution, even if the units are sitting right next to each other and are seeing > the same systemic GPS errors. > > For example, let's say both units share the same antenna, and after > auto-survey one reports it's height as 10 feet MSL, the other unit as 15 feet MSL > (M12M's have easily more than 5 feet height error after self-survey). > > So if you now compare the outputs of the units, satellites directly overhead > could cause a 5 feet, or ~5ns error, while sats at the horizon will not be > affected by the height error, but rather the long/lat errors (which are much > smaller). > > So unless you have a perfectly surveyed antenna position stored in the two > receivers (to within < 1 foot) you will get GPS systemic errors as well as > timing errors due to position error - especially due to antenna height errors. > > When we say units typically have 25ns unit-to-unit variation on the 1PPS on > un-calibrated units, then I believe most of this is caused by the auto-survey > position errors of the GPS receiver. One could get much better performance by > manually entering the exact position-hold position of the antenna, and then > calibrating for antenna cable delay (in 1ns steps). > > This seems to yield down to 2ns performance as reported by > Motorola/Synergy/NIST with careful calibration, and using a "proper" GPS timing antenna with > multipath choke-ring etc. > > But again, this requires a perfectly surveyed antenna position, as well as > offset correction due to antenna cable length delay. > > There are also antenna cable length variations due to ambient temperature > changes :) > > Bruce and others had discussed these errors not too long ago. 140ps error > (or 70ps per GPSDO unit) may be possible on a long antenna cable just due to > temperature changes on the cable.. > > Lastly, our units seem to have a residual PLL tracking noise floor of down > to 1.9ns rms when using a good double oven OCXO as can be seen on the unit > running in Mexico using a properly surveyed antenna position: > > _http://resco.ucol.mx/Fury/gpsstat.htm_ > (http://resco.ucol.mx/Fury/gpsstat.htm) > > Getting 140ps matching offset error between two different units' 1PPS > outputs may be tough to achieve. > I see what you are saying here. I guess that it will be necessary to have some way to calibrate out the long term phase variations from the received signals just like in VLBI. I think it would be interesting to see the raw data from a time interval counter on the PPS of two identical GPSDOs sharing an antenna. If anyone has that sort of data, maybe over a day or two, I'd love to get a copy. Thanks, Matt From pvince at theiet.org Tue Jan 6 11:22:52 2009 From: pvince at theiet.org (Peter Vince) Date: Tue, 06 Jan 2009 11:22:52 +0000 Subject: [time-nuts] Precise manual survey (was Common sky pps...) Message-ID: <49420.1231240972@uk2.net> Said wrote: >When we say units typically have 25ns unit-to-unit variation on the 1PPS on >un-calibrated units, then I believe most of this is caused by the auto-survey >position errors of the GPS receiver. One could get much better performance by > manually entering the exact position-hold position of the antenna, and then >calibrating for antenna cable delay (in 1ns steps). A naive question, if I may: how do I go about doing a precise manual position survey? Is it simply a case of letting the unit self survey, then manually entering different co-ordinates (say +/- 10 metres) in each of the three directions in turn, watch the signal output, and try to tune for minimum wobble? Thanks, Peter From bg at lysator.liu.se Tue Jan 6 13:11:00 2009 From: bg at lysator.liu.se (=?ISO-8859-1?Q?Bj=F6rn?= Gabrielsson) Date: Tue, 06 Jan 2009 14:11:00 +0100 Subject: [time-nuts] Common sky pps errors for any GPSDOs? In-Reply-To: References: Message-ID: <1231247460.15547.35.camel@bg-desktop> Hi Matt, On Mon, 2009-01-05 at 22:03 -0800, Matt Ettus wrote: > On Mon, Jan 5, 2009 at 9:27 PM, wrote: > > Hi Matt, > > > > having 140ps matching of the 1PPS between units is the equivalent of knowing > > your antenna position to within ~0.14 feet total error max. > > > > Thats less than one inch error per antenna! > > That makes it sound a lot more difficult than it really is. The vast > majority of the error in GPS is systematic, such that two GPS systems > with antennas near each other should have highly correlated error. > This is the basis of differential GPS. It doesn't matter if the > absolute error is hundreds of feet, as long as both devices have the > same error. One idea with a "traditional" GPSDO... I assume the sites have a real time communication link, Internet or Radio. Make sure the sites use exactly the same GPS SVs. This can be forced by telling the GPS to exclude SVs you do not want to use. Either you go with 1-SV timing mode and manually tell the receivers which SV to use. Or you juggle 4-6 SVs that are high on the sky on all sites. This will help the GPSDO to measure against the same satellites which gives you kind of a differential effect. > I spent a couple of years nearly a decade ago doing differential GPS > for steering heavy equipment. You can get sub-centimeter errors over > baselines in the tens of km. Again, this is relative error. Sub 10cm, and even sub 5cm over distances up to 40km is possible with dual freq GPS receivers in real time. There are some reasonably priced dual freq GPS that can be driven by your external 5 or 10 MHz OCXO. The Novatel OEMV-2, beeing one candidate http://www.novatel.com/Documents/Papers/OEMV2.pdf Make one site the "base" and the others "rovers". Pass RTK-corrections from your base to the rovers. You should get a very reasonable position errors, especially since your sites are stationary and you can let the RTK algorithms get plenty of time to converge. Then look at the receivers estimate of local oscillator drift for your frequency measurement. This is a fairly simple integration of COTS modules. Since the rovers are not taking advantage of beeing at a surveyed stationary position this is not the optimal solution. Someone on the list with the equipment and time to set this system up? Tvb, have you done this? > Matt -- Bj?rn From newell at cei.net Wed Jan 7 01:23:29 2009 From: newell at cei.net (Scott Newell) Date: Tue, 06 Jan 2009 19:23:29 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <91981b3e0811201055s116f2222r2a8094fa6a1673cc@mail.gmail.co m> References: <91981b3e0811201055s116f2222r2a8094fa6a1673cc@mail.gmail.com> Message-ID: <200901070123.n071NacR000700@host22.the-web-host.com> At 12:55 PM 11/20/2008, Chris Kuethe wrote: >On Thu, Nov 20, 2008 at 10:40 AM, Brad Stockdale wrote: > > o WWVB = 60 KHz > >I bought a nice little module from digi-key to handle this. >561-1014-ND, under $11 including the ferrite antenna. Do you recall if 561-1014-ND was the board and antenna, or just the board? The digikey description leads me to think that no antenna is included. Thanks! newell N5TNL From wittend at wwrinc.com Wed Jan 7 01:31:47 2009 From: wittend at wwrinc.com (David M. Witten II) Date: Tue, 06 Jan 2009 19:31:47 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <200901070123.n071NacR000700@host22.the-web-host.com> References: <91981b3e0811201055s116f2222r2a8094fa6a1673cc@mail.gmail.com> <200901070123.n071NacR000700@host22.the-web-host.com> Message-ID: <49640603.5090207@wwrinc.com> I was confused by their description too. It does include the antenna. I bought two to play with. It seems pretty complete, but I haven't written any code to read it yet. Dave Witten KD0EAG Scott Newell wrote: > At 12:55 PM 11/20/2008, Chris Kuethe wrote: >> On Thu, Nov 20, 2008 at 10:40 AM, Brad Stockdale wrote: >>> o WWVB = 60 KHz >> I bought a nice little module from digi-key to handle this. >> 561-1014-ND, under $11 including the ferrite antenna. > > Do you recall if 561-1014-ND was the board and antenna, or just the > board? The digikey description leads me to think that no antenna is included. > > > Thanks! > newell N5TNL > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From gwinn at Raytheon.com Wed Jan 7 01:38:37 2009 From: gwinn at Raytheon.com (Joseph M Gwinn) Date: Tue, 6 Jan 2009 20:38:37 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops Message-ID: First the background: In some timing distribution applications, the primary source of interference comes from different ground voltages in different parts of the facility, such as a ship or a megawatt radar. The effect of differing ground potentials on a shielded cable is to pull a large current through the shield, so there is a significant voltage between the ends of the cable. No matter how good the shield is at RF, one consequence is that the same power-frequency offset voltage appears on the conductors within that shield, because the skin depth at 60 Hz vastly exceeds the thickness of any reasonable shield. Unshielded twisted pair will suffer the same common-mode offset voltage, perhaps more. This offset often contains significant harmonics of the power frequency, nominally up to the seventh harmonic, not just the fundamental. If the cable is shielded twisted pair, such as twinax, the offset appears as a common-mode voltage on the two conductors, and (if not too large) is eliminated by the CMRR of the receiver. If the cable is coax, the offset voltage appears added to the timing signal voltage, and if the offset isn't too large the signal receiver will be sufficiently immune to this conducted EMI. And now the question: What standards exist governing required immunity of signal ports to these ground-loop induced power-frequency (hum) voltages? All the conducted suseptability standards I've found cover only frequencies exceeding 10 KHz, not power frequencies and their harmonics. Thanks, Joe From newell at cei.net Wed Jan 7 01:40:29 2009 From: newell at cei.net (Scott Newell) Date: Tue, 06 Jan 2009 19:40:29 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <49640603.5090207@wwrinc.com> References: <91981b3e0811201055s116f2222r2a8094fa6a1673cc@mail.gmail.com> <200901070123.n071NacR000700@host22.the-web-host.com> <49640603.5090207@wwrinc.com> Message-ID: <200901070140.n071eZbx003986@host22.the-web-host.com> At 07:31 PM 1/6/2009, David M. Witten II wrote: >I was confused by their description too. It does include the antenna. >I bought two to play with. It seems pretty complete, but I haven't >written any code to read it yet. Thanks--appreciate the confirmation! -- newell N5TNL From kirbybq at bellsouth.net Wed Jan 7 03:54:41 2009 From: kirbybq at bellsouth.net (Brian Kirby) Date: Tue, 06 Jan 2009 21:54:41 -0600 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <49642781.2020305@bellsouth.net> During my experiences involving audio/phone, video and data transmission, we were taught to ground the shield at one end only so we would not cause a ground loop. I ran into problems everywhere I went with this and as much as folks disdain transformers, they are your friend in this type of problem. Don White Consultants/Interference Control Technology published a whole series on EMI, Grounding, and EMC for the military. They are located in Gainesville, VA. Brian Joseph M Gwinn wrote: > First the background: > > In some timing distribution applications, the primary source of > interference comes from different ground voltages in different parts of > the facility, such as a ship or a megawatt radar. > > The effect of differing ground potentials on a shielded cable is to pull a > large current through the shield, so there is a significant voltage > between the ends of the cable. No matter how good the shield is at RF, > one consequence is that the same power-frequency offset voltage appears on > the conductors within that shield, because the skin depth at 60 Hz vastly > exceeds the thickness of any reasonable shield. Unshielded twisted pair > will suffer the same common-mode offset voltage, perhaps more. This > offset often contains significant harmonics of the power frequency, > nominally up to the seventh harmonic, not just the fundamental. > > If the cable is shielded twisted pair, such as twinax, the offset appears > as a common-mode voltage on the two conductors, and (if not too large) is > eliminated by the CMRR of the receiver. > > If the cable is coax, the offset voltage appears added to the timing > signal voltage, and if the offset isn't too large the signal receiver will > be sufficiently immune to this conducted EMI. > > > And now the question: > > What standards exist governing required immunity of signal ports to these > ground-loop induced power-frequency (hum) voltages? > > All the conducted suseptability standards I've found cover only > frequencies exceeding 10 KHz, not power frequencies and their harmonics. > > > Thanks, > > Joe > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From magnus at rubidium.dyndns.org Wed Jan 7 04:48:13 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 07 Jan 2009 05:48:13 +0100 Subject: [time-nuts] NTP API on Linux 2.6.26 Message-ID: <4964340D.8030909@rubidium.dyndns.org> Hi! As I have been investigating the ways of NTPD to fiddle with time in the LINUX kernel I discovered that /usr/include/linux/timex.h (as supplied by the kernel) is not in sync with /usr/include/sys/timex.h (as supplied by glibc 2.7). Since it is the sys/timex.h which is the interface to NTPD and anyone else (it is actually a neat little interface if correctly supported). The fluke is that glibc duplicates the timex.h but has not been updated since oh... Linux 2.2.0. The linux/timex.h is up to date with the NTP API as far as I can see (have not checked the details). There are some links that may be handy: http://bugs.gentoo.org/attachment.cgi?id=165913&action=view http://sources.redhat.com/bugzilla/show_bug.cgi?id=9690 http://sourceware.org/ml/libc-alpha/2008-03/msg00076.html However a small test-program: #include //#include #include "timex.h" int main() { struct timex foo; adjtimex(&foo); printf("TAI Offset %i\n", foo.tai); return 0; } (Notice my quick and dirty hack to use a hacked variant of timex.h as if the patch was being applied, also notice that the .c part does not apply to the adjtimex() call but to the ntp_gettime() call which I am not using, so I do not require that patch for this purpose.) This should be the kernels feeling of the TAI-UTC difference. I do not think it reflects that: magnus at heaven:~/gcc/ntptest$ ./tai TAI Offset -1553771440 magnus at heaven:~/gcc/ntptest$ ./tai TAI Offset -263060400 magnus at heaven:~/gcc/ntptest$ ./tai TAI Offset 238212176 magnus at heaven:~/gcc/ntptest$ ./tai TAI Offset 658158672 magnus at heaven:~/gcc/ntptest$ ./tai TAI Offset 1551639632 So I guess there is more to it than that patch alone. If someone could run the above test-program on some *BSD box or whatever implementing the NTP API version 4 I would be interested in seeing what the result would be. It surely isn't the definitive test on the API, but seems to detect one (of possible several) flaws. Cheers, Magnus From imp at bsdimp.com Wed Jan 7 04:58:35 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue, 06 Jan 2009 21:58:35 -0700 (MST) Subject: [time-nuts] NTP API on Linux 2.6.26 In-Reply-To: <4964340D.8030909@rubidium.dyndns.org> References: <4964340D.8030909@rubidium.dyndns.org> Message-ID: <20090106.215835.-457444968.imp@bsdimp.com> In message: <4964340D.8030909 at rubidium.dyndns.org> Magnus Danielson writes: : Hi! : : As I have been investigating the ways of NTPD to fiddle with time in the : LINUX kernel I discovered that /usr/include/linux/timex.h (as supplied : by the kernel) is not in sync with /usr/include/sys/timex.h (as supplied : by glibc 2.7). Since it is the sys/timex.h which is the interface to : NTPD and anyone else (it is actually a neat little interface if : correctly supported). : : The fluke is that glibc duplicates the timex.h but has not been updated : since oh... Linux 2.2.0. The linux/timex.h is up to date with the NTP : API as far as I can see (have not checked the details). : : There are some links that may be handy: : http://bugs.gentoo.org/attachment.cgi?id=165913&action=view : http://sources.redhat.com/bugzilla/show_bug.cgi?id=9690 : http://sourceware.org/ml/libc-alpha/2008-03/msg00076.html : : However a small test-program: : #include : //#include : #include "timex.h" : : int main() : { : struct timex foo; : adjtimex(&foo); : printf("TAI Offset %i\n", foo.tai); : return 0; : } : : (Notice my quick and dirty hack to use a hacked variant of timex.h as if : the patch was being applied, also notice that the .c part does not apply : to the adjtimex() call but to the ntp_gettime() call which I am not : using, so I do not require that patch for this purpose.) : : This should be the kernels feeling of the TAI-UTC difference. I do not : think it reflects that: : magnus at heaven:~/gcc/ntptest$ ./tai : TAI Offset -1553771440 : magnus at heaven:~/gcc/ntptest$ ./tai : TAI Offset -263060400 : magnus at heaven:~/gcc/ntptest$ ./tai : TAI Offset 238212176 : magnus at heaven:~/gcc/ntptest$ ./tai : TAI Offset 658158672 : magnus at heaven:~/gcc/ntptest$ ./tai : TAI Offset 1551639632 : : So I guess there is more to it than that patch alone. : : If someone could run the above test-program on some *BSD box or whatever : implementing the NTP API version 4 I would be interested in seeing what : the result would be. It surely isn't the definitive test on the API, but : seems to detect one (of possible several) flaws. That didn't work. % cc -o y y.c -Wall y.c: In function 'main': y.c:9: warning: implicit declaration of function 'adjtimex' y.c:10: error: 'struct timex' has no member named 'tai' But this does: #include #include #include int main(int argc, char **argv) { int rv; struct ntptimeval ntv; struct timeval tv1; struct timeval tv2; gettimeofday(&tv1, NULL); rv = ntp_gettime(&ntv); gettimeofday(&tv2, NULL); printf("System: %ld.%06ld\nntp: %ld.%09ld (err %ld)\nntp*: %ld.%09ld\nsystem: %ld.%06ld\n", (long)tv1.tv_sec, (long)tv1.tv_usec, (long)ntv.time.tv_sec, (long)ntv.time.tv_nsec, ntv.esterror * 1000, (long)ntv.time.tv_sec, (long)ntv.time.tv_nsec + ntv.esterror * 1000, (long)tv2.tv_sec, (long)tv2.tv_usec); printf("TAI Offset is %ld\n", ntv.tai); } Warner From magnus at rubidium.dyndns.org Wed Jan 7 05:15:10 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 07 Jan 2009 06:15:10 +0100 Subject: [time-nuts] NTP API on Linux 2.6.26 In-Reply-To: <20090106.215835.-457444968.imp@bsdimp.com> References: <4964340D.8030909@rubidium.dyndns.org> <20090106.215835.-457444968.imp@bsdimp.com> Message-ID: <49643A5E.6000002@rubidium.dyndns.org> M. Warner Losh skrev: > In message: <4964340D.8030909 at rubidium.dyndns.org> > Magnus Danielson writes: > : Hi! > : > : As I have been investigating the ways of NTPD to fiddle with time in the > : LINUX kernel I discovered that /usr/include/linux/timex.h (as supplied > : by the kernel) is not in sync with /usr/include/sys/timex.h (as supplied > : by glibc 2.7). Since it is the sys/timex.h which is the interface to > : NTPD and anyone else (it is actually a neat little interface if > : correctly supported). > : > : The fluke is that glibc duplicates the timex.h but has not been updated > : since oh... Linux 2.2.0. The linux/timex.h is up to date with the NTP > : API as far as I can see (have not checked the details). > : > : There are some links that may be handy: > : http://bugs.gentoo.org/attachment.cgi?id=165913&action=view > : http://sources.redhat.com/bugzilla/show_bug.cgi?id=9690 > : http://sourceware.org/ml/libc-alpha/2008-03/msg00076.html > : > : However a small test-program: > : #include > : //#include > : #include "timex.h" > : > : int main() > : { > : struct timex foo; > : adjtimex(&foo); > : printf("TAI Offset %i\n", foo.tai); > : return 0; > : } > : > : (Notice my quick and dirty hack to use a hacked variant of timex.h as if > : the patch was being applied, also notice that the .c part does not apply > : to the adjtimex() call but to the ntp_gettime() call which I am not > : using, so I do not require that patch for this purpose.) > : > : This should be the kernels feeling of the TAI-UTC difference. I do not > : think it reflects that: > : magnus at heaven:~/gcc/ntptest$ ./tai > : TAI Offset -1553771440 > : magnus at heaven:~/gcc/ntptest$ ./tai > : TAI Offset -263060400 > : magnus at heaven:~/gcc/ntptest$ ./tai > : TAI Offset 238212176 > : magnus at heaven:~/gcc/ntptest$ ./tai > : TAI Offset 658158672 > : magnus at heaven:~/gcc/ntptest$ ./tai > : TAI Offset 1551639632 > : > : So I guess there is more to it than that patch alone. > : > : If someone could run the above test-program on some *BSD box or whatever > : implementing the NTP API version 4 I would be interested in seeing what > : the result would be. It surely isn't the definitive test on the API, but > : seems to detect one (of possible several) flaws. > > That didn't work. > > % cc -o y y.c -Wall > y.c: In function 'main': > y.c:9: warning: implicit declaration of function 'adjtimex' > y.c:10: error: 'struct timex' has no member named 'tai' Oh, I just recalled, adjtimex is the Linux variant for ntp_adjtime, this achieves the same thing using the same interface (but a more portable name as ntp_adjtime exists in Linux also): #include //#include #include "timex.h" int main() { struct timex foo; //adjtimex(&foo); ntp_adjtime(&foo); printf("TAI Offset %i\n", foo.tai); return 0; } and it fails misserably in the same fashion. > But this does: > > #include > #include > #include > > int > main(int argc, char **argv) > { > int rv; > struct ntptimeval ntv; > struct timeval tv1; > struct timeval tv2; > > gettimeofday(&tv1, NULL); > rv = ntp_gettime(&ntv); > gettimeofday(&tv2, NULL); > printf("System: %ld.%06ld\nntp: %ld.%09ld (err %ld)\nntp*: %ld.%09ld\nsystem: %ld.%06ld\n", > (long)tv1.tv_sec, (long)tv1.tv_usec, > (long)ntv.time.tv_sec, (long)ntv.time.tv_nsec, ntv.esterror * 1000, > (long)ntv.time.tv_sec, (long)ntv.time.tv_nsec + ntv.esterror * 1000, > (long)tv2.tv_sec, (long)tv2.tv_usec); > printf("TAI Offset is %ld\n", ntv.tai); > } Patching it to use my patched timex.h and also patching out tv_nsec since it was also not supported (should be another bug as NANO is supported with this kernel) I got this: magnus at heaven:~/gcc/ntptest$ ./taiwarner System: 1231305074.211898 ntp: 1231305074.000000000 (err 491000) ntp*: 1231305074.000491000 system: 1231305074.211906 TAI Offset is 0 TAI Warner is that big media company you know. :) Either this is just a mockupfield of some sort or it just shows that my box does not have any propper TAI-UTS offset given, regardless of which, it should be fixed. Cheers, Magnus From joegwinn at comcast.net Wed Jan 7 05:16:12 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Wed, 7 Jan 2009 00:16:12 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops Message-ID: At 4:59 AM +0000 1/7/09, time-nuts-request at febo.com wrote: > >Message: 6 >Date: Tue, 06 Jan 2009 21:54:41 -0600 >From: Brian Kirby >Subject: Re: [time-nuts] Standards sought for immunity of shielded > cable links to power-frequency ground loops >To: Discussion of precise time and frequency measurement > >Message-ID: <49642781.2020305 at bellsouth.net> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >During my experiences involving audio/phone, video and data >transmission, we were taught to ground the shield at one end only so we >would not cause a ground loop. Yes, it's impossible to do this in a system of any size. In my experience, the RF cables connect the arms of the star-grounding system, causing loops. So, the receivers had to be immune. The problem is to quantify and specify the required degree of immunity. >I ran into problems everywhere I went with this and as much as folks >disdain transformers, they are your friend in this type of problem. DC blocks (usually a series capacitor) also work at RF. But we would have a lot of them. And we would still need some kind of spec to require, to know when we are done. >Don White Consultants/Interference Control Technology published a whole >series on EMI, Grounding, and EMC for the military. They are located in >Gainesville, VA. But do they publish formal and official requirements documents? That's what I need, versus training. Thanks, Joe From magnus at rubidium.dyndns.org Wed Jan 7 06:27:52 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 07 Jan 2009 07:27:52 +0100 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <49644B68.3020800@rubidium.dyndns.org> Joseph M Gwinn skrev: > First the background: > > In some timing distribution applications, the primary source of > interference comes from different ground voltages in different parts of > the facility, such as a ship or a megawatt radar. > > The effect of differing ground potentials on a shielded cable is to pull a > large current through the shield, so there is a significant voltage > between the ends of the cable. No matter how good the shield is at RF, > one consequence is that the same power-frequency offset voltage appears on > the conductors within that shield, because the skin depth at 60 Hz vastly > exceeds the thickness of any reasonable shield. Unshielded twisted pair > will suffer the same common-mode offset voltage, perhaps more. This > offset often contains significant harmonics of the power frequency, > nominally up to the seventh harmonic, not just the fundamental. > > If the cable is shielded twisted pair, such as twinax, the offset appears > as a common-mode voltage on the two conductors, and (if not too large) is > eliminated by the CMRR of the receiver. > > If the cable is coax, the offset voltage appears added to the timing > signal voltage, and if the offset isn't too large the signal receiver will > be sufficiently immune to this conducted EMI. For most purposes an isolational transformer would solve this issue. The unfortunate signal characteristics of a PPS pulse makes this a little more cumbersome, but not unachievable, but it is no longer a simple passive device. For higher frequencies will RF chokes be an aid of course, but the RF choke needs "bolting down" in order to be effective, so that there is a common mode current for the RF choke to object to. However, the RF choke is not as effective with lower frequencies and essentially useless for DC. > And now the question: > > What standards exist governing required immunity of signal ports to these > ground-loop induced power-frequency (hum) voltages? > > All the conducted suseptability standards I've found cover only > frequencies exceeding 10 KHz, not power frequencies and their harmonics. You should look into the telecom set of standards. If you think of it, they have been addressing this particular problem for ages. The words which probably get you right on the target is "bonding network" since you bond to the ground. In short, there are two grounding strategies: all gear is floating relative the safety ground or all gear is internally tied to the safety ground. There is benefits and problems with both strategies. Regardless, a hierarchial star ground strategy emerges. One document to start with is the "Qwest Technical Publication Grounding - Central Office and Remote Equipment Environment" at http://www.qwest.com/techpub/77355/77355.pdf Not to say that it is the standard of any sort, but I think it is a good document to start from as it is a public source of telecom bonding practices to be used in many facilities, implementing existing international standards and involving transmitting towers (which is within your field). IEC 60950 should be a standard reference regardless. You should also consult Bellcore GR-1089. There are additional Bellcore specs, but starting with GR-63 and GR-1089 is not totally off the mark at least. Bellcore specs costs money, but if you need to comply there is no alternative. ITU-T has a set of documents, such as the K-series of standards. You can download these for free at: http://www.itu.int/rec/T-REC-K/e The European telecom world uses ETSI EN 300 253 as basis. They require a login which you can get for free and then pull down all the documents you like. There is also alot of specific EMC documents for various contexts etc and they are all there. ETSI EMC is the TB handling them. On the military side, MIL-HDBK-419 may be a guide: http://tscm.com/MIL-HDBK-419A.PDF Old standard MIL-STD-188-124B: http://www.tscm.com/MIL-STD-188-124B.PDF Newer stdandard MIL-STD-1310 for ships: http://www.earth2.net/parts/basics/milstd1310g.pdf In the end, all these documents forms a reference of standards and practice in a varity of environments. I suspect that your environment does has some bonding standard and practice and you need to figure out what it is so that you know what you can expect, what you need to fullfill (which is limiting freedom on what methods you may apply!) and then it becomes easier to say what may help you. Also, you need to figure out what is the type of problems you run into, how disturbances actually induce into your lines. It could very well be that PSUs acts as EMF due to bad conditioning for instance. There are many anecdotes and horror stories to be told on the subject. There are also sucsess stories to be told. What makes the field a bit complex is that you need to think about failures, EMC, bonding, interference, lightning strikes (on wire, in tower, on building) which can cause a disparity of various indirect effects. It's a bit like being a time-nut. We could probably have a separate email list setup for that kind of discussions alone. Cheers, Magnus From SAIDJACK at aol.com Wed Jan 7 09:05:20 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Wed, 7 Jan 2009 04:05:20 EST Subject: [time-nuts] Precise manual survey (was Common sky pps...) Message-ID: Hello Peter, that's a good question. Some users of our Fury use rented/borrowed survey equipment (Leica, Javad, etc) to get a very precise position of their antenna, or they call in a surveyor. It is also possible to let the receiver do the auto survey multiple times, preferably during different times of the day, then manually average the position fixes, and enter them into our Fury unit as the new position-hold position. I described this method some time ago. Position error should be reduced by this type of averaging. One could also use the Fury NMEA GPGGA output command to send NMEA position data to a PC over a long time, say a week or more, then crunch all that data down to one averaged position fix and manually enter it into the Fury. And your idea of trial and error is not bad either, but I would think height errors of <10 feet, and position errors of less than 5 feet would be sufficient to try. This requires a good reference to compare against though, and LOT'S of patience I would think. From magnus at rubidium.dyndns.org Wed Jan 7 09:08:47 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 07 Jan 2009 10:08:47 +0100 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <4964711F.6060909@rubidium.dyndns.org> Joe Gwinn skrev: > At 4:59 AM +0000 1/7/09, time-nuts-request at febo.com wrote: >> Message: 6 >> Date: Tue, 06 Jan 2009 21:54:41 -0600 >> From: Brian Kirby >> Subject: Re: [time-nuts] Standards sought for immunity of shielded >> cable links to power-frequency ground loops >> To: Discussion of precise time and frequency measurement >> >> Message-ID: <49642781.2020305 at bellsouth.net> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> During my experiences involving audio/phone, video and data >> transmission, we were taught to ground the shield at one end only so we >> would not cause a ground loop. > > Yes, it's impossible to do this in a system of any size. In my > experience, the RF cables connect the arms of the star-grounding > system, causing loops. So, the receivers had to be immune. The > problem is to quantify and specify the required degree of immunity. If you only where connecting the boxes through the power grid and have no other electrical connection at all, the problem would not be as big. Fiber connections does generally not cause any concern. Real systems interconnect in some interesting mesh of often non-static structure. The way to handle that is to build some overall strategy. This takes the form of bondning strategy, EMC requirements and wiring practices. Additional tools of various sorts helps to releive specific problems. >> I ran into problems everywhere I went with this and as much as folks >> disdain transformers, they are your friend in this type of problem. > > DC blocks (usually a series capacitor) also work at RF. But we would > have a lot of them. And we would still need some kind of spec to > require, to know when we are done. Trouble is that most DC blocks is only providing a diffrential block, so that would either render it fairly useless for DC purposes (if the terminating impedance is low at DC-lowfreq in which case the full inner conductor would keep approximatly the same common mode voltage level as the shield since the shield is a low impedance path, the termination is a low impedance path and the conductor is a low impedance path) or dangerous as it would translate a common mode to a diffrential mode voltage (for a high impedance termination at the DC-lowfreq as now the center conductor does not follow the shield and thus the diffrential voltage forms from a common mode source). An effective cure needs to block common mode disturbances while not (significantly) convert them into diffrential mode where the user signal is. Isolational transformers (basically 1:1 transformers, preferably double-shielded, where each shield is hooked to the respective cable shield side) is usually preferred in this context. It can be effective to connect the grounds on both sides to see if it causes the problem to reoccur, if not it is only a precaution to have the transformer. This type of common-mode to diffrential-mode convertion aspect also comes into play when designing lightning arresters. Inappropriate use of com-gaps can result in one of them to lit but not the other and a diffrential mode spike is formed. The diffrential mode tolerance to over-voltage or over-current is usually much less than common mode tolerance. That said, diffrential mode DC blocks have their use, but I fail to see how they can aid in this application. Do feel free to bring me up to speed on how they help. >> Don White Consultants/Interference Control Technology published a whole >> series on EMI, Grounding, and EMC for the military. They are located in >> Gainesville, VA. > > But do they publish formal and official requirements documents? > That's what I need, versus training. I hope my previous post was a rought pointer in the right direction. There is more and I hope I can help you further on that subject. EMC is hairpulling experience at times and take some learning, but it is fairly basic physics applied in the end. Cheers, Magnus From jltran at worldnet.att.net Wed Jan 7 13:41:17 2009 From: jltran at worldnet.att.net (J. L. Trantham) Date: Wed, 7 Jan 2009 07:41:17 -0600 Subject: [time-nuts] 10638A Degausser for 5061A Message-ID: <77909C915F2B46CCA290C6744E40B488@S0028384766> I recently uploaded a manual for the 10638A Degausser to KO4BB's website. I checked this AM and it is available for download. Joe From n3toy at yahoo.com Wed Jan 7 14:25:04 2009 From: n3toy at yahoo.com (James R. Gorr) Date: Wed, 7 Jan 2009 06:25:04 -0800 (PST) Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <200901070140.n071eZbx003986@host22.the-web-host.com> Message-ID: <332872.66371.qm@web54103.mail.re2.yahoo.com> http://dkc3.digikey.com/PDF/T091/P0529.pdf When I look at the catalogue, the description says: > | UTC Receiver Module, 60kHz, no CPU | 561-1014-ND | 10.70 | CMMR-6P-60 | I have looked at modules like this before but what I saw was much more expensive. So I'd like to get one at < $11.00. Have you been able to RX WWVB with it (even if you haven't written anything to decode it)? I wonder what the no CPU means? Jamie --- On Tue, 1/6/09, Scott Newell wrote: > From: Scott Newell > Subject: Re: [time-nuts] WWV / WWVH / WWVB > To: "Discussion of precise time and frequency measurement" > Date: Tuesday, January 6, 2009, 5:40 PM > At 07:31 PM 1/6/2009, David M. Witten II wrote: > >I was confused by their description too. It does > include the antenna. > >I bought two to play with. It seems pretty complete, > but I haven't > >written any code to read it yet. > > Thanks--appreciate the confirmation! > > -- > newell N5TNL > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From marc_bury at yahoo.fr Wed Jan 7 14:35:16 2009 From: marc_bury at yahoo.fr (Marc Bury) Date: Wed, 7 Jan 2009 14:35:16 +0000 (GMT) Subject: [time-nuts] Re : Standards sought for immunity of shielded cable links to power-frequency ground loops (Magnus Danielson) References: Message-ID: <646148.35626.qm@web23101.mail.ird.yahoo.com> Magnus wrote: > Isolational transformers (basically 1:1 transformers, preferably double-shielded, where each shield is hooked to the respective cable shield side) >?is usually preferred in this context. It can be effective to connect the grounds on both sides to see if it causes the problem to reoccur, if not it is only >?a precaution to have the transformer. Isolation transformers are widely used in communications for RJ-45 Ethernet links, with?cheaply available 1:1 transformers giving 1Gb/sec and more. They are also used in standard SP/DIF over coax in?digital?audio application to prevent ground loops. So, plenty of cheap available hardware you can re-use for tinkering ! Marc From wittend at wwrinc.com Wed Jan 7 14:52:23 2009 From: wittend at wwrinc.com (David M. Witten II) Date: Wed, 07 Jan 2009 08:52:23 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <332872.66371.qm@web54103.mail.re2.yahoo.com> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> Message-ID: <4964C1A7.4080902@wwrinc.com> James R. Gorr wrote: > http://dkc3.digikey.com/PDF/T091/P0529.pdf > > > When I look at the catalogue, the description says: > >> | UTC Receiver Module, 60kHz, no CPU | 561-1014-ND | 10.70 | CMMR-6P-60 | > > I have looked at modules like this before but what I saw was much more expensive. So I'd like to get one at < $11.00. Have you been able to RX WWVB with it (even if you haven't written anything to decode it)? > No, I haven't had time to make one work. It seems like a nice little package, but how useful and for what purposes I am not yet certain. My curiosity just got the better of me (again). The device produces a pulse train that encodes the WWV information. > I wonder what the no CPU means? That worried me too. I read the manufacturer's information and it seems that this is sometimes used with an Epson 4 bit CPU. But any CPU/MCU should be able to do the job. A small PIC or AVR should be able to handle it easily. I did a little experimentation with a small ARM7 module (ARMite from Coridium), but haven't had time to do anything useful. There is an article in the November '08 Circuit Cellar Magazine that uses this module with a Freescale DEMO9S08QG8: Time Server Design: Synchronize with the WWVB Time Code Signal Honorable Mention WIZnet iEthernet 2007 Design Contest by Steven Nickels The article can be purchased at: http://www.circuitcellar.com/magazine/220.html The article gives some details of decoding, but I don't have Freescale tools and have a satisfactory (better) NTP server, so I won't duplicate it. I would like to know what others might do with this thing. Dave W. KD0EAG > > Jamie > > From msa at latt.net Wed Jan 7 15:53:43 2009 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 7 Jan 2009 15:53:43 +0000 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <4964C1A7.4080902@wwrinc.com> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> Message-ID: <20090107155343.GA89519@mx1.latt.net> On Wed, Jan 07, 2009 at 08:52:23AM -0600, David M. Witten II wrote: > No, I haven't had time to make one work. It seems like a nice little > package, but how useful and for what purposes I am not yet certain. My > curiosity just got the better of me (again). The device produces a > pulse train that encodes the WWV information. > The article gives some details of decoding, but I don't have Freescale > tools and have a satisfactory (better) NTP server, so I won't duplicate it. > > I would like to know what others might do with this thing. See this for some ideas: http://www.ringolake.com/pic_proj/WWVB/wwvb.html --msa From magnus at rubidium.dyndns.org Wed Jan 7 16:05:52 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 07 Jan 2009 17:05:52 +0100 Subject: [time-nuts] Re : Standards sought for immunity of shielded cable links to power-frequency ground loops (Magnus Danielson) In-Reply-To: <646148.35626.qm@web23101.mail.ird.yahoo.com> References: <646148.35626.qm@web23101.mail.ird.yahoo.com> Message-ID: <4964D2E0.6050304@rubidium.dyndns.org> Marc Bury skrev: > > Magnus wrote: >> Isolational transformers (basically 1:1 transformers, preferably double-shielded, where each shield is hooked to the respective cable shield side) >> is usually preferred in this context. It can be effective to connect the grounds on both sides to see if it causes the problem to reoccur, if not it is only >> a precaution to have the transformer. > > Isolation transformers are widely used in communications for RJ-45 Ethernet links, with cheaply available > 1:1 transformers giving 1Gb/sec and more. Certainly. I actually can't remember one electrical Ethernet variant which haven't used them and I remember the old evil days even. > They are also used in standard SP/DIF over coax in digital audio application to prevent ground loops. To be honest, for S/P-DIF it is more rarely used where as for AES/EBU it is much more common. Then there is all the PDH speeds, ISDN and other digital loops which uses them. Regardless, there is plentifull of them. > So, plenty of cheap available hardware you can re-use for tinkering ! Certainly. However, I think Joes problem was a little more fundamental for the moment. But for the lower frequencies he was asking the rules generally is 1) Bond the nodes down with a bonding network 2) use isolational transformers if needed. For highe? frequencies adding RF chokes and capacitive common mode bonding (if not low-resistive) etc. is most probably the most effective way to isolate things. Cheers, Magnus > Marc > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From chris.kuethe at gmail.com Wed Jan 7 16:55:48 2009 From: chris.kuethe at gmail.com (Chris Kuethe) Date: Wed, 7 Jan 2009 08:55:48 -0800 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <4964C1A7.4080902@wwrinc.com> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> Message-ID: <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> On Wed, Jan 7, 2009 at 6:52 AM, David M. Witten II wrote: > James R. Gorr wrote: >> Have you been able to RX WWVB with it (even if you haven't written anything to decode it)? > > No, I haven't had time to make one work. It seems like a nice little > package, but how useful and for what purposes I am not yet certain. My > curiosity just got the better of me (again). The device produces a > pulse train that encodes the WWV information. It's super-easy to get bits out. (component side up, solder pads on the bottom edge) [1][2][3][4][5][6][7][8] 1) GND 2) VCC 5) GND 6) OUT 7) ~OUT pin 5 is the enable/power-on pin. ground it to turn the module on. then you get bits on pin 6 and 7. >> I wonder what the no CPU means? > > That worried me too. I read the manufacturer's information and it seems > that this is sometimes used with an Epson 4 bit CPU. But any CPU/MCU > should be able to do the job. A small PIC or AVR should be able to > handle it easily. I have one of these modules connected to an arduino (AVR)... for the moment i hacked up an ugly little logger that just samples at 100Hz, toggles the LED and prints the samples. I need to spend some quality time with the manual and read about input capture. > There is an article in the November '08 Circuit Cellar Magazine that > uses this module with a Freescale DEMO9S08QG8: http://www.projects-lab.com/?p=719 ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2008/220/Nickels-220.zip > The article gives some details of decoding, but I don't have Freescale > tools and have a satisfactory (better) NTP server, so I won't duplicate it. searching for "AVR WWVB" and "AVR DCF77" turned up some leads. http://www.ringolake.com/pic_proj/WWVB/wwvb.html http://www.mulder.franken.de/ntpdcfledclock/ http://www.embedds.com/neat-binary-dcf-77-clock/ ... -- GDB has a 'break' feature; why doesn't it have 'fix' too? From hmurray at megapathdsl.net Wed Jan 7 17:18:57 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 07 Jan 2009 09:18:57 -0800 Subject: [time-nuts] WWV / WWVH / WWVB Message-ID: <20090107171858.9E024BCD8@ip-64-139-1-69.sjc.megapath.net> > I would like to know what others might do with this thing. One thing you can do is connect it to a PC via a modem control signal. There is software at: http://www.buzzard.me.uk/jonathan/radioclock.html A lot of the text is for a different hardware module but there is lots of info. In particular, the software will feed ntpd via the SHM interface. -- These are my opinions, not necessarily my employer's. I hate spam. From SAIDJACK at aol.com Wed Jan 7 18:32:04 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Wed, 7 Jan 2009 13:32:04 EST Subject: [time-nuts] Precise manual survey (was Common sky pps...) Message-ID: Hello Peter, I would think it's related to 1ns per foot, but depends highly on Sat geometry at any given time. I remember talking about this some years ago on time nuts, and someone mentioned it wasn't exactly 1ns/foot, but slightly less (if I remember correctly). Yes, the cable delay is completely independent of the "wobble", since all sat's signals will be delayed equally long. The cable delay just causes a static phase-offset in the UTC 1PPS pulse. This can be compensated for in 1ns steps on our Fury GPSDO. There are some secondary effects such as multipath signals that can also have a detrimental effect on precision, so the antenna quality and it's placement can also help reduce the wobble. The Motorola M12+ manual has some nice explanations and drawings to this effect. I think timing receivers have a much easier time detecting multipath, and rejecting it than 3D fix receivers since timing receivers can over-determine their position/time resolution. bye, Said In a message dated 1/7/2009 08:02:59 Pacific Standard Time, pvince at theiet.org writes: Thanks Said. A supplementary question, if I may: can you confirm that the phase "wobble" caused would be a maximum of the usual 1ns per foot? And am I right in thinking that incorrectly specifying the antenna cable delay will only affect the accuracy of the timing of the 1pps output wrt UTC, and not cause any extra wobble? Thanks, Peter From brooke at pacific.net Wed Jan 7 18:44:58 2009 From: brooke at pacific.net (brooke at pacific.net) Date: Wed, 7 Jan 2009 10:44:58 -0800 (PST) Subject: [time-nuts] WWV / WWVH / WWVB Message-ID: <3159.SVVXXVxVQkI=.1231353898.squirrel@webmail.securepacific.net> Hi Jamie: The same company makes a number of LF time code receiving products. Their top of the line model combines a ferrite loop antenna, made to have very specific properties, with a three band receiver that resonates the antenna at either 40, 60 or 77.5 kHz by switching caps. The included CPU can decide which frequency is active and then decode it to make a clock that works with any of the standard signals. The big problem they had was the capacity of chip caps change when they are soldered making it very difficult to choose the proper caps. See: http://www.prc68.com/I/Loop.shtml I have a couple of the no CPU units on order in the hope that the output signal has a relationship with the signal strength. If that's the case then they can be used in developing an antenna. Have Fun, Brooke Clarke http://www.prc68.com James R. Gorr wrote: > http://dkc3.digikey.com/PDF/T091/P0529.pdf > > > When I look at the catalogue, the description says: > >> | UTC Receiver Module, 60kHz, no CPU | 561-1014-ND | 10.70 | CMMR-6P-60 | > > I have looked at modules like this before but what I saw was much more expensive. So I'd like to get one at < $11.00. Have you been able to RX WWVB with it (even if you haven't written anything to decode it)? > > I wonder what the no CPU means? > > Jamie > > > --- On Tue, 1/6/09, Scott Newell wrote: > >> From: Scott Newell >> Subject: Re: [time-nuts] WWV / WWVH / WWVB >> To: "Discussion of precise time and frequency measurement" >> Date: Tuesday, January 6, 2009, 5:40 PM >> At 07:31 PM 1/6/2009, David M. Witten II wrote: >>> I was confused by their description too. It does >> include the antenna. >>> I bought two to play with. It seems pretty complete, >> but I haven't >>> written any code to read it yet. >> Thanks--appreciate the confirmation! >> >> -- >> newell N5TNL >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From steveheidmann at yahoo.com Wed Jan 7 18:52:01 2009 From: steveheidmann at yahoo.com (steve heidmann) Date: Wed, 7 Jan 2009 10:52:01 -0800 (PST) Subject: [time-nuts] more accuracy Message-ID: <206416.19546.qm@web36805.mail.mud.yahoo.com> tvb , When will you have your triphoton time base up and running ? ? ( sciencedaily.com today ) From jra at febo.com Wed Jan 7 20:15:25 2009 From: jra at febo.com (John Ackermann N8UR) Date: Wed, 07 Jan 2009 15:15:25 -0500 Subject: [time-nuts] FTS 4100 (4050/4060) Service Information? Message-ID: <49650D5D.4000904@febo.com> I recently acquired a couple of FTS 4100/S12 cesium frequency standard modules. These are, I've been told, basically the guts of a 4050 (and maybe 4060?) commercial standard repackaged for military "fly-away" use. They run from 22-30 volts and have a couple of switches and a meter jack, but no front panel. I have two units that both seem to lock up, though both have minor glitches, and a third once worked but recently stopped locking; I'm trying to fix that one for a University group. I have some very basic operations-level documentation for the 4100, but nothing that helps with troubleshooting or repair. Does anyone here have a service manual that covers the 4100, or much more likely, the "CFS" package of the 4050 or 4060? A scanned copy would do the trick very nicely. Thanks! John From gwinn at raytheon.com Wed Jan 7 20:59:54 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Wed, 7 Jan 2009 15:59:54 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <49644B68.3020800@rubidium.dyndns.org> Message-ID: Magnus, time-nuts-bounces at febo.com wrote on 01/07/2009 01:27:52 AM: > Joseph M Gwinn skrev: > > First the background: > > > > In some timing distribution applications, the primary source of > > interference comes from different ground voltages in different parts of > > the facility, such as a ship or a megawatt radar. I left a useful detail out: The reference signal is a 10 MHz sinewave. > > The effect of differing ground potentials on a shielded cable is to pull a > > large current through the shield, so there is a significant voltage > > between the ends of the cable. No matter how good the shieldis at RF, > > one consequence is that the same power-frequency offset voltage appears on > > the conductors within that shield, because the skin depth at 60 Hz vastly > > exceeds the thickness of any reasonable shield. Unshielded twisted pair > > will suffer the same common-mode offset voltage, perhaps more. This > > offset often contains significant harmonics of the power frequency, > > nominally up to the seventh harmonic, not just the fundamental. > > > > If the cable is shielded twisted pair, such as twinax, the offset appears > > as a common-mode voltage on the two conductors, and (if not too large) is > > eliminated by the CMRR of the receiver. > > > > If the cable is coax, the offset voltage appears added to the timing > > signal voltage, and if the offset isn't too large the signal receiver will > > be sufficiently immune to this conducted EMI. > > For most purposes an isolation transformer would solve this issue. The > unfortunate signal characteristics of a PPS pulse makes this a little > more cumbersome, but not unachievable, but it is no longer a simple > passive device. For higher frequencies will RF chokes be an aid of > course, but the RF choke needs "bolting down" in order to be effective, > so that there is a common mode current for the RF choke to object to. > However, the RF choke is not as effective with lower frequencies and > essentially useless for DC. The receivers have built-in RF transformers. There is no 1PPS signal per se, although the transformer would probably pass such a signal well enough. What is being carried is 10 MHz. The problem is to devise a test and spec that ensures that the actual implemented circuit in the receivers suffice. There are many ways to botch this circuit. > > And now the question: > > > > What standards exist governing required immunity of signal ports to these > > ground-loop induced power-frequency (hum) voltages? > > > > All the conducted suseptability standards I've found cover only > > frequencies exceeding 10 KHz, not power frequencies and theirharmonics. > > You should look into the telecom set of standards. If you think of it, > they have been addressing this particular problem for ages. The words > which probably get you right on the target is "bonding network" since > you bond to the ground. This is just the sort of lead I was hoping to find. > In short, there are two grounding strategies: all gear is floating > relative the safety ground or all gear is internally tied to the safety > ground. There is benefits and problems with both strategies. Regardless, > a hierarchial star ground strategy emerges. In our systems, everything is tied to ground for both safety and RF reasons unrelated to timing signals. And we do have a star of sorts, but the story always ends up more complex than that, so it always ends up being a somewhat random grounding grid. My problem is not safety, it is tolerance of conducted EMI. > One document to start with is the "Qwest Technical Publication > Grounding - Central Office and Remote Equipment Environment" at > http://www.qwest.com/techpub/77355/77355.pdf > > Not to say that it is the standard of any sort, but I think it is a good > document to start from as it is a public source of telecom bonding > practices to be used in many facilities, implementing existing > international standards and involving transmitting towers (which is > within your field). > > IEC 60950 should be a standard reference regardless. > > You should also consult Bellcore GR-1089. There are additional Bellcore > specs, but starting with GR-63 and GR-1089 is not totally off the mark > at least. Bellcore specs costs money, but if you need to comply there is > no alternative. > > ITU-T has a set of documents, such as the K-series of standards. You can > download these for free at: > http://www.itu.int/rec/T-REC-K/e > > The European telecom world uses ETSI EN 300 253 as basis. They require a > login which you can get for free and then pull down all the documents > you like. There is also alot of specific EMC documents for various > contexts etc and they are all there. ETSI EMC is the TB handling them. > > On the military side, MIL-HDBK-419 may be a guide: > http://tscm.com/MIL-HDBK-419A.PDF > > Old standard MIL-STD-188-124B: > http://www.tscm.com/MIL-STD-188-124B.PDF > > Newer standard MIL-STD-1310 for ships: > http://www.earth2.net/parts/basics/milstd1310g.pdf I will be doing some homework. Some of these are tomes. > In the end, all these documents forms a reference of standards and > practice in a varity of environments. I suspect that your environment > does has some bonding standard and practice and you need to figure out > what it is so that you know what you can expect, what you need to > fullfill (which is limiting freedom on what methods you may apply!) and > then it becomes easier to say what may help you. Also, you need to > figure out what is the type of problems you run into, how disturbances > actually induce into your lines. It could very well be that PSUs acts as > EMF due to bad conditioning for instance. > > There are many anecdotes and horror stories to be told on the subject. > There are also sucesses stories to be told. We do have a bonding story, one that sort-of follows MIL-STD-1310, even though the system is land based. > What makes the field a bit complex is that you need to think about > failures, EMC, bonding, interference, lightning strikes (on wire, in > tower, on building) which can cause a disparity of various indirect > effects. It's a bit like being a time-nut. We could probably have a > separate email list setup for that kind of discussions alone. Fortunately for me, I do not have to worry about lightning. That's handled elsewhere, as all these cables are within a steel-frame building with a lightning protection system built in. Joe From magnus at rubidium.dyndns.org Wed Jan 7 21:22:06 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 07 Jan 2009 22:22:06 +0100 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <49651CFE.3070800@rubidium.dyndns.org> Joseph, Joseph M Gwinn skrev: > Magnus, > > time-nuts-bounces at febo.com wrote on 01/07/2009 01:27:52 AM: > >> Joseph M Gwinn skrev: >>> First the background: >>> >>> In some timing distribution applications, the primary source of >>> interference comes from different ground voltages in different parts > of >>> the facility, such as a ship or a megawatt radar. > > I left a useful detail out: The reference signal is a 10 MHz sinewave. 10 MHz into a transmitter. Should not be too hard to master. For some reason I feel confident in that environment. :) >> For most purposes an isolation transformer would solve this issue. The >> unfortunate signal characteristics of a PPS pulse makes this a little >> more cumbersome, but not unachievable, but it is no longer a simple >> passive device. For higher frequencies will RF chokes be an aid of >> course, but the RF choke needs "bolting down" in order to be effective, >> so that there is a common mode current for the RF choke to object to. >> However, the RF choke is not as effective with lower frequencies and >> essentially useless for DC. > > The receivers have built-in RF transformers. There is no 1PPS signal per > se, although the transformer would probably pass such a signal well > enough. What is being carried is 10 MHz. > > The problem is to devise a test and spec that ensures that the actual > implemented circuit in the receivers suffice. There are many ways to > botch this circuit. I see. It is fairly easy to induce common mode currents and DC voltages. An isolational transformer from a source and then on the other side simply DC offset or apply signal through a transformer if not directly from an amplifier. >> You should look into the telecom set of standards. If you think of it, >> they have been addressing this particular problem for ages. The words >> which probably get you right on the target is "bonding network" since >> you bond to the ground. > > This is just the sort of lead I was hoping to find. Great. >> In short, there are two grounding strategies: all gear is floating >> relative the safety ground or all gear is internally tied to the safety >> ground. There is benefits and problems with both strategies. Regardless, > >> a hierarchial star ground strategy emerges. > > In our systems, everything is tied to ground for both safety and RF > reasons unrelated to timing signals. And we do have a star of sorts, but > the story always ends up more complex than that, so it always ends up > being a somewhat random grounding grid. As always. > My problem is not safety, it is tolerance of conducted EMI. The reason I mention safety is that some people suggest solutions which does not fullfill the safety criteria in spirit or standard. It gets you into the right category of solutions. >> One document to start with is the "Qwest Technical Publication >> Grounding - Central Office and Remote Equipment Environment" at >> http://www.qwest.com/techpub/77355/77355.pdf >> >> Not to say that it is the standard of any sort, but I think it is a good > >> document to start from as it is a public source of telecom bonding >> practices to be used in many facilities, implementing existing >> international standards and involving transmitting towers (which is >> within your field). >> >> IEC 60950 should be a standard reference regardless. >> >> You should also consult Bellcore GR-1089. There are additional Bellcore >> specs, but starting with GR-63 and GR-1089 is not totally off the mark >> at least. Bellcore specs costs money, but if you need to comply there is > >> no alternative. >> >> ITU-T has a set of documents, such as the K-series of standards. You can > >> download these for free at: >> http://www.itu.int/rec/T-REC-K/e >> >> The European telecom world uses ETSI EN 300 253 as basis. They require a > >> login which you can get for free and then pull down all the documents >> you like. There is also alot of specific EMC documents for various >> contexts etc and they are all there. ETSI EMC is the TB handling them. >> >> On the military side, MIL-HDBK-419 may be a guide: >> http://tscm.com/MIL-HDBK-419A.PDF >> >> Old standard MIL-STD-188-124B: >> http://www.tscm.com/MIL-STD-188-124B.PDF >> >> Newer standard MIL-STD-1310 for ships: >> http://www.earth2.net/parts/basics/milstd1310g.pdf > > I will be doing some homework. Some of these are tomes. You could also look up ETSI EN 300 132-* and EN 300 386 which is relevant for telecom boxes. Further on is EN 300 199-* probably good to have around, but maybe not so applicable to this particular problem. What you want to transfer is similar to an E1 or E2 on an intra-office link. >> EMF due to bad conditioning for instance. >> >> There are many anecdotes and horror stories to be told on the subject. >> There are also sucesses stories to be told. > > We do have a bonding story, one that sort-of follows MIL-STD-1310, even > though the system is land based. Sounds good. Will think about levels. >> What makes the field a bit complex is that you need to think about >> failures, EMC, bonding, interference, lightning strikes (on wire, in >> tower, on building) which can cause a disparity of various indirect >> effects. It's a bit like being a time-nut. We could probably have a >> separate email list setup for that kind of discussions alone. > > Fortunately for me, I do not have to worry about lightning. That's > handled elsewhere, as all these cables are within a steel-frame building > with a lightning protection system built in. Actually, the most outer cabling links needs to be shielded or else they would intduce into cables. Cheers, Magnus From phk at phk.freebsd.dk Wed Jan 7 21:25:04 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 07 Jan 2009 21:25:04 +0000 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: Your message of "Tue, 06 Jan 2009 20:38:37 EST." Message-ID: <5016.1231363504@critter.freebsd.dk> In message , Joseph M Gwinn writes: >The effect of differing ground potentials on a shielded cable is to pull a >large current through the shield, [...] The correct enginering solution is to use twinax, ground the shield in one end only and transformer-couple the signal at least in the other end from the grounding. Look at IBM's 5250 terminal hookup for an school book example of getting it right. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ronaldheld at gmail.com Wed Jan 7 22:08:22 2009 From: ronaldheld at gmail.com (Ronald Held) Date: Wed, 7 Jan 2009 17:08:22 -0500 Subject: [time-nuts] TB PS/Antenna recommendations Message-ID: <9a86fb0e0901071408r4a205518mc346d7694f9af5f8@mail.gmail.com> I have not following all of discussions for a while, so perhaps I missed out on some of this. What do people suggest for a power supply and from where? The harder request is for an indoor antenna probable placed up against the window. Reliable dealers or stores would be very helpful. Ronald From gwinn at raytheon.com Wed Jan 7 22:42:56 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Wed, 7 Jan 2009 17:42:56 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <5016.1231363504@critter.freebsd.dk> Message-ID: Poul-Henning, time-nuts-bounces at febo.com wrote on 01/07/2009 04:25:04 PM: > In message 000907CA at mck.us.ra > y.com>, Joseph M Gwinn writes: > > >The effect of differing ground potentials on a shielded cable is to pull a > >large current through the shield, [...] > > The correct enginering solution is to use twinax, ground the shield > in one end only and transformer-couple the signal at least in the > other end from the grounding. Yes, I know of this. Shielded twisted pair is also widely used in audio, for the same reasons. But my system is coax and was that way before I arrived. I know of some similar but ship-board systems that use twinax for time reference distribution, as you suggest. Don't know if they use transformers though. Could be a differential TX and RX. I recall that they send a RS422 signal. I imagine that the shield is grounded at both ends, if only for safety reasons. Fortunately, my system is not so noisy as a ship. If I had it to do over, I might well use multimode fiber. > Look at IBM's 5250 terminal hookup for an school book example of getting > it right. A blast from the past - shades of the 1970s! A parallel story: Some years ago I was working on shipboard systems that used 10BASE5 ethernet over thick coax (nominally RG8). The problem is that there is no real ground on a ship, and there can be 7 volts difference between bow and stern because the hull is used as the power system neutral. Well, 10BASE5 ethernet uses 2-volt signals, so 7 volts offset would prevent communications. The solution was to use triax. The outer shield was grounded at both ends. The inner shield and center conductor together formed the ethernet media. The inner shield was connected to the outer shield in exactly one place. For safety, this connection had to be able to handle 1,000 amps, to ensure that breakers would pop before ground links opened. (One of our young engineers was going to use a AWG #30 wire-wrap link.) The outer shield stopped at the cabinet I/O panel, with only the inner shield and center conductor continuing (as a bit of RG58) to the etherent transceivers. This worked flawlessly. Joe From phk at phk.freebsd.dk Wed Jan 7 22:56:19 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 07 Jan 2009 22:56:19 +0000 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: Your message of "Wed, 07 Jan 2009 17:42:56 EST." Message-ID: <5329.1231368979@critter.freebsd.dk> In message , Joseph M Gwinn writes: >Could be a differential TX and RX. I recall that they send a RS422 signal. Depending on the speed, RS422 works fine with transformers. >I imagine that the shield is grounded at both ends, if only for >safety reasons. That is actually a very unsafe practice, unless there is another much thicker and reliable ground connection between the two domains. But you should never let the screen float in the far end, you should terminate it with a 10M resistor and a sparkgap in parallel to the local ground. The resistor takes care of static electricity and the sparkgap will do lightnings. >If I had it to do over, I might well use multimode fiber. Yes, never roll copper more than 100m or between buildings if you can get away with installing fiber. >The solution was to use triax. The >outer shield was grounded at both ends. The inner shield and center >conductor together formed the ethernet media. The inner shield was >connected to the outer shield in exactly one place. That's technically speaking not triax, that's double shield. Triax would have the conductors and one shield. But yes, double shielding works great, provided you don't have morons with screwdrivers around. Poul-Henning (Who once lost all ethernet interfaces, the access control system and a few minor computers when a moron first created and then cut a 600+ A ground loop). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From SAIDJACK at aol.com Wed Jan 7 23:00:42 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Wed, 7 Jan 2009 18:00:42 EST Subject: [time-nuts] Precise manual survey (was Common sky pps...) Message-ID: Hello Peter, we've got a number of different units running various tests in our lab right now, and they all can be tracked on the following site: _http://www.jackson-labs.com/images/gpsstat.htm_ (http://www.jackson-labs.com/images/gpsstat.htm) The units will flip-through the website every 30 seconds or so. These are two 3D Fix units, and two Fury's running in position-hold mode. From gwinn at raytheon.com Wed Jan 7 23:34:19 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Wed, 7 Jan 2009 18:34:19 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <5329.1231368979@critter.freebsd.dk> Message-ID: Poul-Henning, time-nuts-bounces at febo.com wrote on 01/07/2009 05:56:19 PM: > In message 007CC84F at mck.us.ra > y.com>, Joseph M Gwinn writes: > > >Could be a differential TX and RX. I recall that they send a RS422 signal. > > Depending on the speed, RS422 works fine with transformers. Yes. It would be 10 MHz or 20 MHz, depending on coding. Or 5 MHz, so the transitions are at 10 MHz. I don't recall, or never knew. > >I imagine that the shield is grounded at both ends, if only for > >safety reasons. > > That is actually a very unsafe practice, unless there is another > much thicker and reliable ground connection between the two domains. There is a very heavy grounding grid, and such systems almost always ground the (outer) shields at every connector. > But you should never let the screen float in the far end, you should > terminate it with a 10M resistor and a sparkgap in parallel to the > local ground. > > The resistor takes care of static electricity and the sparkgap will > do lightnings. I've done such things, but with a 100 ohm resistor (and a safety ground to ensure that the voltage doesn't get too large. But this was a lab lashup. > >If I had it to do over, I might well use multimode fiber. > > Yes, never roll copper more than 100m or between buildings if you > can get away with installing fiber. > > >The solution was to use triax. The > >outer shield was grounded at both ends. The inner shield and center > >conductor together formed the ethernet media. The inner shield was > >connected to the outer shield in exactly one place. > > That's technically speaking not triax, that's double shield. Triax > would have the conductors and one shield. No, I think that's twinax: . Triax is a center plus two concentric shields: . The terms are very similar. > But yes, double shielding works great, provided you don't have morons > with screwdrivers around. > > Poul-Henning > > (Who once lost all ethernet interfaces, the access control system > and a few minor computers when a moron first created and then cut > a 600+ A ground loop). Was there a big bang? What was the source of the 600 amps? Joe From magnus at rubidium.dyndns.org Thu Jan 8 03:35:02 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 04:35:02 +0100 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <5329.1231368979@critter.freebsd.dk> References: <5329.1231368979@critter.freebsd.dk> Message-ID: <49657466.7010500@rubidium.dyndns.org> Poul-Henning Kamp skrev: > In message y.com>, Joseph M Gwinn writes: > >> Could be a differential TX and RX. I recall that they send a RS422 signal. > > Depending on the speed, RS422 works fine with transformers. You want a DC balanced encoding if you send data down the line, otherwise you will saturate the transformer and saturation works very well as method of damping. This was actually used for modulation of high powers and then the transformer was called a transductor, essentially a transformer with too small core. This is the core at the Grimeton long wave transmitter (a world heritage site) in south of Sweden. Lovely thing to visit. The 127 m high and 1,8 km long antenna is not easy to miss. I beleive the output effect was 200 kW at 17,2 kHz. It has a definitive steam-engine feel to it. Lovely. Usually thought the signal is just dampend out. Only transitions survive. A pure 10 MHz is not a problem at all, but generic RS422 may not survive. >> I imagine that the shield is grounded at both ends, if only for >> safety reasons. > > That is actually a very unsafe practice, unless there is another > much thicker and reliable ground connection between the two domains. Which is what most bonding network standards will describe never the less. > But you should never let the screen float in the far end, you should > terminate it with a 10M resistor and a sparkgap in parallel to the > local ground. > > The resistor takes care of static electricity and the sparkgap will > do lightnings. You most probably want to use a capacitor from shield to chassi both for providing a low impedance path for RF and static electricity blasts but also helps in reducing the RF emission. Clamping an external RF choke on the cable will be meaningfull when the cap is there as the RF choke is being properly terminated. >> If I had it to do over, I might well use multimode fiber. > > Yes, never roll copper more than 100m or between buildings if you > can get away with installing fiber. So true. Not that you can't get it to work, but it is tedious to make it work under all conditions. >> The solution was to use triax. The >> outer shield was grounded at both ends. The inner shield and center >> conductor together formed the ethernet media. The inner shield was >> connected to the outer shield in exactly one place. > > That's technically speaking not triax, that's double shield. Triax > would have the conductors and one shield. > > But yes, double shielding works great, provided you don't have morons > with screwdrivers around. The ethernet habit of using vampire clamps provided a great opportunity for less insightful installation practices. > Poul-Henning > > (Who once lost all ethernet interfaces, the access control system > and a few minor computers when a moron first created and then cut > a 600+ A ground loop). As I said... :) Remember, we need to support our morons in their daily task. :) Cheers, Magnus From magnus at rubidium.dyndns.org Thu Jan 8 03:47:46 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 04:47:46 +0100 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <49657762.5060504@rubidium.dyndns.org> Joseph, >>> Could be a differential TX and RX. I recall that they send a RS422 > signal. >> Depending on the speed, RS422 works fine with transformers. > > Yes. It would be 10 MHz or 20 MHz, depending on coding. Or 5 MHz, so the > transitions are at 10 MHz. I don't recall, or never knew. RS422 does not imply any encoding as such so it would be 10 MHz but naturally there is twice that many transitions, but it is the frequency of the signal you are interested in for this case. >>> I imagine that the shield is grounded at both ends, if only for >>> safety reasons. >> That is actually a very unsafe practice, unless there is another >> much thicker and reliable ground connection between the two domains. > > There is a very heavy grounding grid, and such systems almost always > ground the (outer) shields at every connector. Which would imply that if the signal passes through a connector jack or through a wall, much of the current would be sent back to its EMF source locally in the room. This does have its merits. >> But you should never let the screen float in the far end, you should >> terminate it with a 10M resistor and a sparkgap in parallel to the >> local ground. >> >> The resistor takes care of static electricity and the sparkgap will >> do lightnings. > > I've done such things, but with a 100 ohm resistor (and a safety ground to > ensure that the voltage doesn't get too large. But this was a lab lashup. The trouble with 100 ohm is that still can be a little low in relation to ground loop impedances, it still allow some fair current to roll down the cable. A capacitor in parallel would cut most of the transient energy straight through and allow for a higher resistive path for the low frequency energy. >>> If I had it to do over, I might well use multimode fiber. >> Yes, never roll copper more than 100m or between buildings if you >> can get away with installing fiber. >> >>> The solution was to use triax. The >>> outer shield was grounded at both ends. The inner shield and center >>> conductor together formed the ethernet media. The inner shield was >>> connected to the outer shield in exactly one place. >> That's technically speaking not triax, that's double shield. Triax >> would have the conductors and one shield. > > No, I think that's twinax: . > > Triax is a center plus two concentric shields: > . > > The terms are very similar. I have some triax cables and connectors, but not twinax... >> But yes, double shielding works great, provided you don't have morons >> with screwdrivers around. >> >> Poul-Henning >> >> (Who once lost all ethernet interfaces, the access control system >> and a few minor computers when a moron first created and then cut >> a 600+ A ground loop). > > Was there a big bang? What was the source of the 600 amps? I think there (with some delay) was some awfull scream of dispare. The cost of Ethernet interfaces where much more significant back then. Cheers, Magnus From richiem at hughes.net Thu Jan 8 04:54:04 2009 From: richiem at hughes.net (Richard Moore) Date: Wed, 7 Jan 2009 20:54:04 -0800 Subject: [time-nuts] TBolt antenna In-Reply-To: References: Message-ID: <04990E12-E284-4D5B-9D97-458E4379293C@hughes.net> On Jan 7, 2009, at 2:43 PM, time-nuts-request at febo.com wrote: > > Message: 6 > Date: Wed, 7 Jan 2009 17:08:22 -0500 > From: "Ronald Held" > Subject: [time-nuts] TB PS/Antenna recommendations > To: time-nuts at febo.com > Message-ID: > <9a86fb0e0901071408r4a205518mc346d7694f9af5f8 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I have not following all of discussions for a while, so perhaps I > missed out on some of this. What do people suggest for a power supply > and from where? The harder request is for an indoor antenna probable > placed up against the window. Reliable dealers or stores would be very > helpful. > Ronald > I'm using a fairly crappy triple-output open-frame Autec supply from Marlin P. Jones that was $13. I'm not recommending it, but it works. My antenna is an active patch type by Hawk that runs off +5V from the TBolt. It has a magnetic base for top of vehicle use. I've got it feeding two GPSDOs thru a splitter and it's working great. I got it from Synergy for $35 if I remember correctly -- been a while. I've got it duct taped to a 2x4 sticking our from under the eave of my lab. Most any active antenna will likely work OK outdoors, but I don't know about indoors -- think you'll want some higher gain version. Dick Moore From tvb at LeapSecond.com Thu Jan 8 08:02:44 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Thu, 8 Jan 2009 00:02:44 -0800 Subject: [time-nuts] GPSDO time constant Message-ID: Here are ADEV plots and interesting results from a recent experiment on varying the time-constant of a GPSDO: http://www.leapsecond.com/pages/tbolt-tc/ There was a thread recently where Warren suggested that the loop time constant (TC) of GPSDO was less than ideal. He is correct. There are a couple of reasons for this, if I may guess. 1) Some GPSDO, like the surplus SmartClock designs from HP, were designed to meet spec even when S/A was still in effect. With the much greater wander in civilian GPS timing during those years, the TC needed to be less than what you can get away with today. 2) If you are a manufacturer and have a GPSDO spec to meet, you need to make sure the TC is valid for all OCXO that you ship, not just the average one. The way to do this is to be conservative and to ship the units with a TC that is short enough that even the parts on the lower end of the bell curve still meet your spec. The other alternative is to individually measure (days, weeks?) every OCXO and individually burn a default TC into each unit shipped. 3) Most commercial GPSDO need to work over a fairly wide temperature range. This might require a tighter TC. If the user has a more controlled environment they can probably tolerate a longer TC that what the manufacturer dare ship as a default. 4) A GPSDO should still work reliably in the face of phase or frequency jumps in the OCXO. Although the timing of these is not predictable, their typical magnitude is probably something that the designer can learn. The TC needs to be short enough so that the GPSDO gracefully handles these jumps. If one is too aggressive the GPSDO will wander out of spec instead of more closely tracking GPS. 5) I'm not sure it's possible to optimize for both time stability and frequency stability at the same time. A long TC will help avoid too sudden frequency changes in the GPSDO; a short TC will help the 1pps stay close to UTC. I suppose a GPSDO might be optimized more for one application than the other; this would affect the choice of default TC. 6) Most OCXO demonstrate much better drift rates after they have been in operation for weeks or months. The drift rate has a some impact on the choice of TC. It's probably not a good business model to ship a GPSDO with a TC optimized for how the unit might eventually run a year from now. It has to work out of the box. So this cause the default TC to be set shorter than ideal. 7) There may also be a SV, sky-view, or latitude dependence. Someone enjoying all 32 SV today, with a clear 360 degree view of the sky at mid-latitude will probably enjoy slightly better performance than someone a few years ago when there were less operational SV in orbit, or with mountain, forest, building obstructions, or at extreme latitudes. If you have much better than average reception you could probably move the TC out further. So for these reasons (more like guesses), it would not surprise me if most GPSDO have the TC set on the low side. Let me know if you have additional info on this topic. The good news is that if you, the time-nut, have the gear and the time to measure the stability of the OCXO in your GPSDO, and know your environment well, then you can probably safely lengthen the TC and achieve much better mid-term stability out of your GPSDO as shown in the plot above. /tvb From namichie at gmail.com Thu Jan 8 08:38:37 2009 From: namichie at gmail.com (Neville Michie) Date: Thu, 8 Jan 2009 19:38:37 +1100 Subject: [time-nuts] GPSDO time constant In-Reply-To: References: Message-ID: Thanks Tom, that answered questions I had been wondering about for some time. I think that was one of the best posts that I have read. It also reinforces my plans to build a passive temperature control for my TB, putting it in an insulated aluminium box with a tiny cooling fan regulating its self- heating temperature to about 40C. great post! Neville Michie On 08/01/2009, at 7:02 PM, Tom Van Baak wrote: > Here are ADEV plots and interesting results from a recent > experiment on varying the time-constant of a GPSDO: > > http://www.leapsecond.com/pages/tbolt-tc/ > > > /tvb > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ > time-nuts > and follow the instructions there. From phk at phk.freebsd.dk Thu Jan 8 08:47:29 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 08:47:29 +0000 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: Your message of "Wed, 07 Jan 2009 18:34:19 EST." Message-ID: <7171.1231404449@critter.freebsd.dk> In message , Joseph M Gwinn writes: >> That's technically speaking not triax, that's double shield. Triax >> would have the conductors and one shield. > >No, I think that's twinax: . > >Triax is a center plus two concentric shields: >. Sorry, I fumbled what I wrote there. I would say wiki is wrong here, the usage I am used to is: coax: single conductor + shield twinax: twisted pair + shield triax: the wires + shield >> (Who once lost all ethernet interfaces, the access control system >> and a few minor computers when a moron first created and then cut >> a 600+ A ground loop). > >Was there a big bang? What was the source of the 600 amps? They replaced the separation transformer with a UPS, and they connected the two sides ground together at the UPS. Unfortunately the grounding on our secondary side was much better than the power companys grounding on the primary side, which was the entire point of having the the transformer in the first place. Yes, there were a significant bang and his two-hand wire-cutter was recategorized from "tool" to "industrial art". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Jan 8 08:51:45 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 08:51:45 +0000 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: Your message of "Thu, 08 Jan 2009 04:47:46 +0100." <49657762.5060504@rubidium.dyndns.org> Message-ID: <7217.1231404705@critter.freebsd.dk> In message <49657762.5060504 at rubidium.dyndns.org>, Magnus Danielson writes: >> Was there a big bang? What was the source of the 600 amps? > >I think there (with some delay) was some awfull scream of dispare. >The cost of Ethernet interfaces where much more significant back then. The most expensive one we lost was in a UNISYS 2200, where three microprocessors worked together to limit bandwidth to 100 kB/s. I belive the sticker prices as $15k. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Jan 8 08:57:26 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 08:57:26 +0000 Subject: [time-nuts] GPSDO time constant In-Reply-To: Your message of "Thu, 08 Jan 2009 00:02:44 PST." Message-ID: <7277.1231405046@critter.freebsd.dk> In message , "Tom Van Baak" writes: >Here are ADEV plots and interesting results from a recent >experiment on varying the time-constant of a GPSDO: > >http://www.leapsecond.com/pages/tbolt-tc/ Tom, part of the reason for the sub-optimally short default time constant is to be able to cope with worst-case specs of the oscillator. Even though they are pretty good, shifts in voltage, temperature and orientation does affect them. A very good example of this effect is the NTPD PLL, which uncritically belives otherwise unplausible good news, and lengthens the poll-period to 20 minutes and then refuses to accept that it did it wrong, until i thas seen three or four (= one hour) samples saying so, after which it breaks lock and starts over. In a lab setting, it makes sense to increase over the default time-constant, just remember that it impacts your loops ability to cope with for instance a 2g turnover. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bruce.griffiths at xtra.co.nz Thu Jan 8 10:14:30 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 08 Jan 2009 23:14:30 +1300 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <7171.1231404449@critter.freebsd.dk> References: <7171.1231404449@critter.freebsd.dk> Message-ID: <4965D206.2070301@xtra.co.nz> Poul-Henning Kamp wrote: > In message y.com>, Joseph M Gwinn writes: > > >>> That's technically speaking not triax, that's double shield. Triax >>> would have the conductors and one shield. >>> >> No, I think that's twinax: . >> >> Triax is a center plus two concentric shields: >> . >> > > Sorry, I fumbled what I wrote there. I would say wiki is wrong > here, the usage I am used to is: > coax: single conductor + shield > twinax: twisted pair + shield > triax: the wires + shield > > >>> (Who once lost all ethernet interfaces, the access control system >>> and a few minor computers when a moron first created and then cut >>> a 600+ A ground loop). >>> >> Was there a big bang? What was the source of the 600 amps? >> > > They replaced the separation transformer with a UPS, and they > connected the two sides ground together at the UPS. > > Unfortunately the grounding on our secondary side was much better > than the power companys grounding on the primary side, which was the > entire point of having the the transformer in the first place. > > Yes, there were a significant bang and his two-hand wire-cutter was > recategorized from "tool" to "industrial art". > > Similarly for Quadraxial cable there are 2 interpretations: 1) an inner conductor surrounded by 3 coaxial tubular conductors all insulated from each other. 2) 2 twisted pairs with an outer tubular shield used in some high speed network cabling. Both meanings are in common use. Quintaxial cable seems only to be mentioned in texts on cable shielding. In which it consists of a central conductor surrounded by 4 coaxial tubular screens all of which are insulated from each other. Bruce From magnus at rubidium.dyndns.org Thu Jan 8 10:51:50 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 11:51:50 +0100 Subject: [time-nuts] GPSDO time constant In-Reply-To: References: Message-ID: <4965DAC6.6040909@rubidium.dyndns.org> Tom Van Baak skrev: > Here are ADEV plots and interesting results from a recent > experiment on varying the time-constant of a GPSDO: > > http://www.leapsecond.com/pages/tbolt-tc/ > > There was a thread recently where Warren suggested that the > loop time constant (TC) of GPSDO was less than ideal. He is > correct. There are a couple of reasons for this, if I may guess. I particular liked that you tweaked the damping constant. If it is not scaled off the normal charts (it doesn't look like it) I think it is rather low damping factor and this infact does not supprise me at least to produce a definitive bump. Keeping it at 1.2 is still not "critically damped" but rather under-damped. I would love to see a few variants of measure at say tau = 100s but for various damping coefficients. By the looks of it, the bump can be attributed almost completely to resonance in the PLL loop, which is certainly not what we would like to see... adding to the noise response. > 1) Some GPSDO, like the surplus SmartClock designs from HP, > were designed to meet spec even when S/A was still in effect. > With the much greater wander in civilian GPS timing during > those years, the TC needed to be less than what you can get > away with today. > > 2) If you are a manufacturer and have a GPSDO spec to meet, > you need to make sure the TC is valid for all OCXO that you ship, > not just the average one. The way to do this is to be conservative > and to ship the units with a TC that is short enough that even the > parts on the lower end of the bell curve still meet your spec. > > The other alternative is to individually measure (days, weeks?) > every OCXO and individually burn a default TC into each unit > shipped. With the end result being that noise specs would still vary between units. Also, if one unit was good at fab and gets pounded during shipping doesn't help either. > 3) Most commercial GPSDO need to work over a fairly wide > temperature range. This might require a tighter TC. If the user > has a more controlled environment they can probably tolerate a > longer TC that what the manufacturer dare ship as a default. > > 4) A GPSDO should still work reliably in the face of phase or > frequency jumps in the OCXO. Although the timing of these is > not predictable, their typical magnitude is probably something > that the designer can learn. The TC needs to be short enough > so that the GPSDO gracefully handles these jumps. If one is > too aggressive the GPSDO will wander out of spec instead of > more closely tracking GPS. All these 4 points really argue against the principle of choosing one TC to fit them all. Using suitable heuristics to adapt TC to conditions and recent history runtime will provide a much more dynamic fashion in which units would adapt to their performance and their environment. > 5) I'm not sure it's possible to optimize for both time stability > and frequency stability at the same time. A long TC will help > avoid too sudden frequency changes in the GPSDO; a short > TC will help the 1pps stay close to UTC. I suppose a GPSDO > might be optimized more for one application than the other; > this would affect the choice of default TC. Actually no, not really. If we remove the issues of hanging bridge, which the ThunderBolt effectively has since it steers it's timing clock, then another reason for shifting PPS is due to changing symmetry and when removing or adding a satellite from the chosen constellation (by tracking set or TRAIM selective set) the apparent receiver time will jump. In the meanwhile it may glide as the symmetry changes. Multipath can also aid in shifting position. So a shorter time constant does not render a closer rendition of UTC but rather a quicker follow of apparent time position of the receiver, which isn't quite the same thing. Thus, a longer time constants acts like an averaging of apparent time position. Another factor which plauges most single frequency receivers is that they can't correct for actual ionospheric delay. They run according to a parameterized model. There is a deviation between the actual and apparent delay and it is changing over time. Thus, using Rubidium or Caesium to steer local clock will allow for even greater time constants and thus greater averaging potential, as 1000 s is still kind of "short". The conclusion is that the GPS receivers we use have many inherrent non-static error sources > 6) Most OCXO demonstrate much better drift rates after they > have been in operation for weeks or months. The drift rate has > a some impact on the choice of TC. It's probably not a good > business model to ship a GPSDO with a TC optimized for how > the unit might eventually run a year from now. It has to work > out of the box. So this cause the default TC to be set shorter > than ideal. > > 7) There may also be a SV, sky-view, or latitude dependence. > Someone enjoying all 32 SV today, with a clear 360 degree > view of the sky at mid-latitude will probably enjoy slightly better > performance than someone a few years ago when there were > less operational SV in orbit, or with mountain, forest, building > obstructions, or at extreme latitudes. If you have much better > than average reception you could probably move the TC out > further. These two points again suggests a more dynamic approach to setting time constant. There is some old papers discussing straight PLL loops vs. Kalman filter and Kalman filter (if done properly) will adapt dynamically and they showed (to some degree) that the Kalman filter approach outperformed the straight PLL approach. > So for these reasons (more like guesses), it would not surprise > me if most GPSDO have the TC set on the low side. Let me > know if you have additional info on this topic. In general I think you are right. There are many reasons why they go on the low side. > The good news is that if you, the time-nut, have the gear and > the time to measure the stability of the OCXO in your GPSDO, > and know your environment well, then you can probably safely > lengthen the TC and achieve much better mid-term stability out > of your GPSDO as shown in the plot above. Agreed. But also recall that long-term effects like frequency drift is pretty easy to measure with a GPS. It would not take too much research to figure out some suitable drift-TC relationship such that you could either just look the charts to find a good match or even apply them in real time steering. For ThunderBolt owners it is pretty straightforward to adjust the TC and damping, which is very nice. Use this oppertunity! Cheers, Magnus From magnus at rubidium.dyndns.org Thu Jan 8 10:58:42 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 11:58:42 +0100 Subject: [time-nuts] GPSDO time constant In-Reply-To: <7277.1231405046@critter.freebsd.dk> References: <7277.1231405046@critter.freebsd.dk> Message-ID: <4965DC62.9070205@rubidium.dyndns.org> Poul-Henning Kamp skrev: > In message , "Tom Van Baak" writes: >> Here are ADEV plots and interesting results from a recent >> experiment on varying the time-constant of a GPSDO: >> >> http://www.leapsecond.com/pages/tbolt-tc/ > > Tom, part of the reason for the sub-optimally short default time > constant is to be able to cope with worst-case specs of the > oscillator. > > Even though they are pretty good, shifts in voltage, temperature > and orientation does affect them. > > A very good example of this effect is the NTPD PLL, which > uncritically belives otherwise unplausible good news, and > lengthens the poll-period to 20 minutes and then refuses > to accept that it did it wrong, until i thas seen three > or four (= one hour) samples saying so, after which it > breaks lock and starts over. Isn't this more due to surrounding (obviously flawed) heuristics rather than the PLL? Interesting never the less. > In a lab setting, it makes sense to increase over the default > time-constant, just remember that it impacts your loops ability > to cope with for instance a 2g turnover. > Most labs would have issues with a 2g turnover. :) Flipping oscillators that runs is evil and should be avoided at all times. Should be in the rulebook for time-nuts. Cheers, Magnus From bruce.griffiths at xtra.co.nz Thu Jan 8 11:09:02 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 00:09:02 +1300 Subject: [time-nuts] GPSDO time constant In-Reply-To: <4965DAC6.6040909@rubidium.dyndns.org> References: <4965DAC6.6040909@rubidium.dyndns.org> Message-ID: <4965DECE.3060004@xtra.co.nz> Hej Magnus Magnus Danielson wrote: > Tom Van Baak skrev: > >> Here are ADEV plots and interesting results from a recent >> experiment on varying the time-constant of a GPSDO: >> >> http://www.leapsecond.com/pages/tbolt-tc/ >> >> There was a thread recently where Warren suggested that the >> loop time constant (TC) of GPSDO was less than ideal. He is >> correct. There are a couple of reasons for this, if I may guess. >> > > I particular liked that you tweaked the damping constant. If it is not > scaled off the normal charts (it doesn't look like it) I think it is > rather low damping factor and this infact does not supprise me at least > to produce a definitive bump. Keeping it at 1.2 is still not "critically > damped" but rather under-damped. > > I would love to see a few variants of measure at say tau = 100s but for > various damping coefficients. By the looks of it, the bump can be > attributed almost completely to resonance in the PLL loop, which is > certainly not what we would like to see... adding to the noise response. > > >> 1) Some GPSDO, like the surplus SmartClock designs from HP, >> were designed to meet spec even when S/A was still in effect. >> With the much greater wander in civilian GPS timing during >> those years, the TC needed to be less than what you can get >> away with today. >> >> 2) If you are a manufacturer and have a GPSDO spec to meet, >> you need to make sure the TC is valid for all OCXO that you ship, >> not just the average one. The way to do this is to be conservative >> and to ship the units with a TC that is short enough that even the >> parts on the lower end of the bell curve still meet your spec. >> >> The other alternative is to individually measure (days, weeks?) >> every OCXO and individually burn a default TC into each unit >> shipped. >> > > With the end result being that noise specs would still vary between > units. Also, if one unit was good at fab and gets pounded during > shipping doesn't help either. > > >> 3) Most commercial GPSDO need to work over a fairly wide >> temperature range. This might require a tighter TC. If the user >> has a more controlled environment they can probably tolerate a >> longer TC that what the manufacturer dare ship as a default. >> >> 4) A GPSDO should still work reliably in the face of phase or >> frequency jumps in the OCXO. Although the timing of these is >> not predictable, their typical magnitude is probably something >> that the designer can learn. The TC needs to be short enough >> so that the GPSDO gracefully handles these jumps. If one is >> too aggressive the GPSDO will wander out of spec instead of >> more closely tracking GPS. >> > > All these 4 points really argue against the principle of choosing one TC > to fit them all. Using suitable heuristics to adapt TC to conditions and > recent history runtime will provide a much more dynamic fashion in which > units would adapt to their performance and their environment. > > >> 5) I'm not sure it's possible to optimize for both time stability >> and frequency stability at the same time. A long TC will help >> avoid too sudden frequency changes in the GPSDO; a short >> TC will help the 1pps stay close to UTC. I suppose a GPSDO >> might be optimized more for one application than the other; >> this would affect the choice of default TC. >> > > Actually no, not really. > > If we remove the issues of hanging bridge, which the ThunderBolt > effectively has since it steers it's timing clock, then another reason > for shifting PPS is due to changing symmetry and when removing or adding > a satellite from the chosen constellation (by tracking set or TRAIM > selective set) the apparent receiver time will jump. In the meanwhile it > may glide as the symmetry changes. Multipath can also aid in shifting > position. So a shorter time constant does not render a closer rendition > of UTC but rather a quicker follow of apparent time position of the > receiver, which isn't quite the same thing. Thus, a longer time > constants acts like an averaging of apparent time position. > > Another factor which plauges most single frequency receivers is that > they can't correct for actual ionospheric delay. They run according to a > parameterized model. There is a deviation between the actual and > apparent delay and it is changing over time. > > Thus, using Rubidium or Caesium to steer local clock will allow for even > greater time constants and thus greater averaging potential, as 1000 s > is still kind of "short". > > The conclusion is that the GPS receivers we use have many inherrent > non-static error sources > > >> 6) Most OCXO demonstrate much better drift rates after they >> have been in operation for weeks or months. The drift rate has >> a some impact on the choice of TC. It's probably not a good >> business model to ship a GPSDO with a TC optimized for how >> the unit might eventually run a year from now. It has to work >> out of the box. So this cause the default TC to be set shorter >> than ideal. >> >> 7) There may also be a SV, sky-view, or latitude dependence. >> Someone enjoying all 32 SV today, with a clear 360 degree >> view of the sky at mid-latitude will probably enjoy slightly better >> performance than someone a few years ago when there were >> less operational SV in orbit, or with mountain, forest, building >> obstructions, or at extreme latitudes. If you have much better >> than average reception you could probably move the TC out >> further. >> > > These two points again suggests a more dynamic approach to setting time > constant. > > There is some old papers discussing straight PLL loops vs. Kalman filter > and Kalman filter (if done properly) will adapt dynamically and they > showed (to some degree) that the Kalman filter approach outperformed the > straight PLL approach. > > >> So for these reasons (more like guesses), it would not surprise >> me if most GPSDO have the TC set on the low side. Let me >> know if you have additional info on this topic. >> > > In general I think you are right. There are many reasons why they go on > the low side. > > >> The good news is that if you, the time-nut, have the gear and >> the time to measure the stability of the OCXO in your GPSDO, >> and know your environment well, then you can probably safely >> lengthen the TC and achieve much better mid-term stability out >> of your GPSDO as shown in the plot above. >> > > Agreed. But also recall that long-term effects like frequency drift is > pretty easy to measure with a GPS. It would not take too much research > to figure out some suitable drift-TC relationship such that you could > either just look the charts to find a good match or even apply them in > real time steering. > > For ThunderBolt owners it is pretty straightforward to adjust the TC and > damping, which is very nice. Use this oppertunity! > > How exactly can one measure the resultant performance or even select the optimum time constant and damping factor if one doesn't have a quieter reference? Can one really resort to some sort of N cornered hat? > Cheers, > Magnus > > > Bruce From magnus at rubidium.dyndns.org Thu Jan 8 11:23:39 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 12:23:39 +0100 Subject: [time-nuts] GPSDO time constant In-Reply-To: <4965DECE.3060004@xtra.co.nz> References: <4965DAC6.6040909@rubidium.dyndns.org> <4965DECE.3060004@xtra.co.nz> Message-ID: <4965E23B.7070300@rubidium.dyndns.org> Hej Bruce, >>> The good news is that if you, the time-nut, have the gear and >>> the time to measure the stability of the OCXO in your GPSDO, >>> and know your environment well, then you can probably safely >>> lengthen the TC and achieve much better mid-term stability out >>> of your GPSDO as shown in the plot above. >>> >> Agreed. But also recall that long-term effects like frequency drift is >> pretty easy to measure with a GPS. It would not take too much research >> to figure out some suitable drift-TC relationship such that you could >> either just look the charts to find a good match or even apply them in >> real time steering. >> >> For ThunderBolt owners it is pretty straightforward to adjust the TC and >> damping, which is very nice. Use this oppertunity! > > How exactly can one measure the resultant performance or even select the > optimum time constant and damping factor if one doesn't have a quieter > reference? > Can one really resort to some sort of N cornered hat? If time constants is allowed to be limited by frequency drift (regardless of its source) then you can use a long term drift estimate to control the time constant of the control loop. Essentially being an adaptive filter. It is still a gross oversimplification, but may still be a handy one. Cheers, Magnus From phk at phk.freebsd.dk Thu Jan 8 11:27:11 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 11:27:11 +0000 Subject: [time-nuts] GPSDO time constant In-Reply-To: Your message of "Fri, 09 Jan 2009 00:09:02 +1300." <4965DECE.3060004@xtra.co.nz> Message-ID: <8373.1231414031@critter.freebsd.dk> In message <4965DECE.3060004 at xtra.co.nz>, Bruce Griffiths writes: >Hej Magnus > >Magnus Danielson wrote: > >How exactly can one measure the resultant performance or even select the >optimum time constant and damping factor if one doesn't have a quieter >reference? >Can one really resort to some sort of N cornered hat? I experimented with that, and you can actually get pretty far with simpler standalone means such as periodograms of zero crossings. My theory behind this is that the noise (of all kinds) is basically gaussian or other symmetric distributions. Consequently, the offset between your oscillator and the reference should also have a symmetric distribution of sign, subject to well known random "paradoxes" like the fact that repeatedly rolling 6 with dice doesn't prove you cheat, you might just be very very lucky. I have not fully developed this lead, and would welcome others to experiement and improve on it, it takes more patience and stability than my lap can muster when it must also work for my salary. The way I autotune the timeconstant of the PLL in NTPns is based on this lack of zero-crossings of the offset from the reference input: The first sign that a PLL has been torqued to hard is that the reference input is not able to steer the oscillator adequately and you can detect this very early, by monitoring how long runs you have where the offset from the reference stays the same sign: the runs on one side will get longer and more frequent than on the other side. You can also tell that the timeconstant is too short, because the runs are not long enough, indicating that the PLL follows the reference signal more aggresively than it need. Look in the main/pllmath.c file of NTPns to see my current implementation. (http://phk.freebsd.dk/phkrel/). One of my NTP servers use the same GPS PPS to steer the PRS10 Rb and for the NTP data feed, so the NTPns should obviously end up with a zero frequency error, since the PRS10 takes care of that. Consequently the PLL keeps stretching the timeconstant of the software PLL, until it had identified a 2e-18 rounding error in the frequency estimation code in the kernel. The third order code on the other hand, does not seem to do me much good yet, but maybe I simply don't have good enough kit for that to be dominant. The experiements I would propose requires that you can get hold of the reference/oscillator difference signal somehow, and then what you want to do is simply record runs of these values for various timeconstants and damping factors. The run them through a statistical package, or possibly even the DIEHARD tests, and see how different timeconstants score, the ones where the offset looks most random are optimal. Have fun :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Jan 8 11:28:34 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 11:28:34 +0000 Subject: [time-nuts] GPSDO time constant In-Reply-To: Your message of "Thu, 08 Jan 2009 11:58:42 +0100." <4965DC62.9070205@rubidium.dyndns.org> Message-ID: <8418.1231414114@critter.freebsd.dk> In message <4965DC62.9070205 at rubidium.dyndns.org>, Magnus Danielson writes: >> In a lab setting, it makes sense to increase over the default >> time-constant, just remember that it impacts your loops ability >> to cope with for instance a 2g turnover. >> >Most labs would have issues with a 2g turnover. :) > >Flipping oscillators that runs is evil and should be avoided at all >times. Should be in the rulebook for time-nuts. Correct, but it is perfectly normal behaviour for telecom techs who remodel installations while running, so the products must cope with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From magnus at rubidium.dyndns.org Thu Jan 8 11:50:01 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 12:50:01 +0100 Subject: [time-nuts] GPSDO time constant In-Reply-To: <8418.1231414114@critter.freebsd.dk> References: <8418.1231414114@critter.freebsd.dk> Message-ID: <4965E869.4090205@rubidium.dyndns.org> Poul-Henning Kamp skrev: > In message <4965DC62.9070205 at rubidium.dyndns.org>, Magnus Danielson writes: > >>> In a lab setting, it makes sense to increase over the default >>> time-constant, just remember that it impacts your loops ability >>> to cope with for instance a 2g turnover. >>> >> Most labs would have issues with a 2g turnover. :) >> >> Flipping oscillators that runs is evil and should be avoided at all >> times. Should be in the rulebook for time-nuts. > > Correct, but it is perfectly normal behaviour for telecom techs > who remodel installations while running, so the products must > cope with it. > True. Very true. The only thing which to some degree prohibits that is to make them monolithic. You are not entierly safe even with monolithic racks. Ericsson created a rack system in which the bottom of the rack was actually forming a closed container with the floor. Hook up compressed air to the nossle and the rack was floating, and hand-pushing the rack into position was no trouble, pull the plugg and it would sit tight on the floor again. That way they could shift in their racks while running, making cut-over time go down to zero. Cheers, Magnus From phk at phk.freebsd.dk Thu Jan 8 12:11:36 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 12:11:36 +0000 Subject: [time-nuts] GPSDO time constant In-Reply-To: Your message of "Thu, 08 Jan 2009 12:50:01 +0100." <4965E869.4090205@rubidium.dyndns.org> Message-ID: <8566.1231416696@critter.freebsd.dk> In message <4965E869.4090205 at rubidium.dyndns.org>, Magnus Danielson writes: >Ericsson created a rack system in which the bottom of the rack >was actually forming a closed container with the floor. We had that at one place I worked, except it was two small "dogs" you attached front and back a standard 19" rack. Trouble was that you had to wash the floor first, or the dust would blow all over the place. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From stephan at rrsg.ee.uct.ac.za Thu Jan 8 15:01:54 2009 From: stephan at rrsg.ee.uct.ac.za (Stephan Sandenbergh) Date: Thu, 8 Jan 2009 17:01:54 +0200 Subject: [time-nuts] Motorola M12+T - On board oscillator phase noise specand/or part number In-Reply-To: <0D7331CE7C5E487B8FABE2B150220045@pc52> References: <0D7331CE7C5E487B8FABE2B150220045@pc52> Message-ID: Hi Tom, Thanks - the data is rather useful. Do you perhaps know what the high freq phase noise looks like? I'd like to lock the GPS LO to the output of my GPSDO. However, the integrated jitter will probably determine if it could be done, by something as simple as filtering the output of a fractional N (implemented inside a FPGA) or maybe a dedicated fractional N IC with low-noise VCO (such as those from Analog Devices). I guess the latter is more realistic. I'd guess the stock TCXO onboard the M12+T would have a noise floor below say -140dBc/Hz. Regards, Stephan. 2009/1/2 Tom Van Baak > > Hi All, > > > > Has anyone been able to figure out the part number and/or measured the > > phase noise of the quartz oscillator on board the Motorola M12+T? > > > > This will be an interesting figure to see. > > > > Regards, > > > > Stephan. > > This is an ADEV+MDEV plot for the 100 Hz output of an > M12+ in free-run mode (no gps lock). > > http://www.leapsecond.com/pages/m12-adev/m12-free.gif > > If you want more data let me know. > > /tvb > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From jra at febo.com Thu Jan 8 15:20:01 2009 From: jra at febo.com (John Ackermann N8UR) Date: Thu, 08 Jan 2009 10:20:01 -0500 Subject: [time-nuts] Motorola M12+T - On board oscillator phase noise specand/or part number In-Reply-To: References: <0D7331CE7C5E487B8FABE2B150220045@pc52> Message-ID: <496619A1.6@febo.com> Stephan Sandenbergh wrote: > Hi Tom, > > Thanks - the data is rather useful. Do you perhaps know what the high freq > phase noise looks like? I'd like to lock the GPS LO to the output of my > GPSDO. However, the integrated jitter will probably determine if it could be > done, by something as simple as filtering the output of a fractional N > (implemented inside a FPGA) or maybe a dedicated fractional N IC with > low-noise VCO (such as those from Analog Devices). I guess the latter is > more realistic. > > I'd guess the stock TCXO onboard the M12+T would have a noise floor below > say -140dBc/Hz. I have a plot that shows the phase noise of two Tbolts and two Z3801As at http://www.febo.com/pages/gpsdo_comparison/ -- scroll down the page a bit to find the phase noise info. John From brooke at pacific.net Thu Jan 8 17:25:40 2009 From: brooke at pacific.net (brooke at pacific.net) Date: Thu, 8 Jan 2009 09:25:40 -0800 (PST) Subject: [time-nuts] GPSDO time constant Message-ID: <1472.SVVXXVxVQkI=.1231435540.squirrel@webmail.securepacific.net> Hi Magnus: I think some labs don't think about 90 degree turnovers, for example: I've heard that the xtal oscillator cal procedure for some HP test equipment says that the instrument should be in the same position as when it's operating. For heavy rack equipment that means you lay on a mechanics creeper when making the adjustment rather than flipping the instrument 90 degrees on a bench. Have Fun, Brooke Clarke http://www.prc68.com Magnus Danielson wrote: . . . > Most labs would have issues with a 2g turnover. :) > > Flipping oscillators that runs is evil and should be avoided at all > times. Should be in the rulebook for time-nuts. > > Cheers, > Magnus From magnus at rubidium.dyndns.org Thu Jan 8 17:50:37 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 18:50:37 +0100 Subject: [time-nuts] GPSDO time constant In-Reply-To: <1472.SVVXXVxVQkI=.1231435540.squirrel@webmail.securepacific.net> References: <1472.SVVXXVxVQkI=.1231435540.squirrel@webmail.securepacific.net> Message-ID: <49663CED.7080904@rubidium.dyndns.org> Hi Brooke, brooke at pacific.net skrev: > Hi Magnus: > > I think some labs don't think about 90 degree turnovers, for example: > > I've heard that the xtal oscillator cal procedure for some HP test > equipment says that the instrument should be in the same position as when > it's operating. For heavy rack equipment that means you lay on a > mechanics creeper when making the adjustment rather than flipping the > instrument 90 degrees on a bench. So you didn't check out your HP gravity field wrapping mirror? Those are SO handy. :) Cheers, Magnus From w1ksz at earthlink.net Thu Jan 8 18:11:10 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Thu, 8 Jan 2009 13:11:10 -0500 (EST) Subject: [time-nuts] 10 MHz Band-Pass Filter Needed Message-ID: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> The GPSDO I want to use has an output rich in harmonics. In some cases that is good, but Murphy rules and in the application I have today, it is not good. I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something small with SMA connectors would be ideal, but I can live with BNC. Anyone have such a beast or know where I can get one ? I checked Mini-Circuits and choked on the price !! Thanks, Dick, W1KSZ From danrae at verizon.net Thu Jan 8 18:19:08 2009 From: danrae at verizon.net (Dan Rae) Date: Thu, 08 Jan 2009 10:19:08 -0800 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed In-Reply-To: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Message-ID: <4966439C.10804@verizon.net> Richard W. Solomon wrote: > The GPSDO I want to use has an output rich in harmonics. In some > cases that is good, but Murphy rules and in the application I have > today, it is not good. > > I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something > small with SMA connectors would be ideal, but I can live with BNC. > > Anyone have such a beast or know where I can get one ? I checked Mini-Circuits > and choked on the price !! > > Dick, it is really easy to build one. The wonderful (free!) filter design program ELSIE will give you all the help you need. I would have thought an hour or so with a couple of toroids would do the trick. Even just a Low Pass filter would usually do to turn a square wave into a sine... Dan ac6ao / g3ncr From SAIDJACK at aol.com Thu Jan 8 18:26:48 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Thu, 8 Jan 2009 13:26:48 EST Subject: [time-nuts] GPSDO time constant Message-ID: Hi Magnus, all depends - in an aircraft you have 6g+ turn-overs :) We make a version of our FireFly-II GPSDO with ultra-low-g sensitivity and ruggedization, that one you can run in a back-pack while doing skating-tricks on a ramp and you won't see much change in frequency. A bit more pricey on that OCXO of course. Most "standard" oscillators will have about 1-2ppb change after a turn-over. I have seen some that actually change the Crystal temperature when turned over, so you can see the initial frequency change due to gravity, then you see the operating current change, and the frequency slowly drift away as the temperature of the crystal is changed. Bad. Very bad. bye, Said In a message dated 1/8/2009 09:29:41 Pacific Standard Time, brooke at pacific.net writes: Magnus Danielson wrote: . . . > Most labs would have issues with a 2g turnover. :) > > Flipping oscillators that runs is evil and should be avoided at all > times. Should be in the rulebook for time-nuts. > > Cheers, > Magnus From jra at febo.com Thu Jan 8 18:30:22 2009 From: jra at febo.com (John Ackermann N8UR) Date: Thu, 08 Jan 2009 13:30:22 -0500 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed In-Reply-To: <4966439C.10804@verizon.net> References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <4966439C.10804@verizon.net> Message-ID: <4966463E.2020303@febo.com> Dan Rae wrote: > Richard W. Solomon wrote: >> The GPSDO I want to use has an output rich in harmonics. In some >> cases that is good, but Murphy rules and in the application I have >> today, it is not good. >> >> I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something >> small with SMA connectors would be ideal, but I can live with BNC. >> >> Anyone have such a beast or know where I can get one ? I checked Mini-Circuits >> and choked on the price !! >> >> > > Dick, it is really easy to build one. The wonderful (free!) filter > design program ELSIE will give you all the help you need. I would have > thought an hour or so with a couple of toroids would do the trick. Even > just a Low Pass filter would usually do to turn a square wave into a sine... It's actually much better to use an LPF than a bandpass filter if you don't have subharmonic energy to deal with. An LPF with a cutoff midway between the fundamental and the 2nd harmonic will show much less tempco (in the form of phase shift over temperature) than a bandpass filter. John From jra at febo.com Thu Jan 8 18:32:30 2009 From: jra at febo.com (John Ackermann N8UR) Date: Thu, 08 Jan 2009 13:32:30 -0500 Subject: [time-nuts] GPSDO time constant In-Reply-To: References: Message-ID: <496646BE.8070601@febo.com> I mentioned in another post that I picked up a couple of militarized FTS-4100 "fly-away" Cs units. These have an option installed that adds an accelerometer to the OCXO; it's supposed to reduce G sensitivity by at least an order of magnitude. John ---- SAIDJACK at aol.com wrote: > Hi Magnus, > > all depends - in an aircraft you have 6g+ turn-overs :) > > We make a version of our FireFly-II GPSDO with ultra-low-g sensitivity and > ruggedization, that one you can run in a back-pack while doing skating-tricks > on a ramp and you won't see much change in frequency. A bit more pricey on > that OCXO of course. > > Most "standard" oscillators will have about 1-2ppb change after a turn-over. > I have seen some that actually change the Crystal temperature when turned > over, so you can see the initial frequency change due to gravity, then you see > the operating current change, and the frequency slowly drift away as the > temperature of the crystal is changed. Bad. Very bad. > > bye, > Said > > > In a message dated 1/8/2009 09:29:41 Pacific Standard Time, > brooke at pacific.net writes: > > Magnus Danielson wrote: > . . . >> Most labs would have issues with a 2g turnover. :) >> >> Flipping oscillators that runs is evil and should be avoided at all >> times. Should be in the rulebook for time-nuts. >> >> Cheers, >> Magnus > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From w1ksz at earthlink.net Thu Jan 8 18:38:45 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Thu, 8 Jan 2009 13:38:45 -0500 (EST) Subject: [time-nuts] 10 MHz Band-Pass Filter Needed (REVISED) Message-ID: <3405567.1231439925402.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Another thought came to me, a PC Mount device would also do as I could mount it inside the GPSDO box and eliminate another set of connectors. Building one is not viable as the space I have is restricted. 73, Dick, W1LSZ -----Original Message----- >From: "Richard W. Solomon" >Sent: Jan 8, 2009 1:11 PM >To: time-nuts at febo.com >Subject: [time-nuts] 10 MHz Band-Pass Filter Needed > >The GPSDO I want to use has an output rich in harmonics. In some >cases that is good, but Murphy rules and in the application I have >today, it is not good. > >I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something >small with SMA connectors would be ideal, but I can live with BNC. > >Anyone have such a beast or know where I can get one ? I checked Mini-Circuits >and choked on the price !! > >Thanks, Dick, W1KSZ > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From james.p.lux at jpl.nasa.gov Thu Jan 8 18:42:16 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 8 Jan 2009 10:42:16 -0800 Subject: [time-nuts] GPSDO time constant In-Reply-To: <49663CED.7080904@rubidium.dyndns.org> References: <1472.SVVXXVxVQkI=.1231435540.squirrel@webmail.securepacific.net> <49663CED.7080904@rubidium.dyndns.org> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Magnus Danielson > Sent: Thursday, January 08, 2009 9:51 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] GPSDO time constant > > Hi Brooke, > So you didn't check out your HP gravity field wrapping mirror? > Those are SO handy. :) > > Cheers, > Magnus I think that division got sold off when it became Agilent. From james.p.lux at jpl.nasa.gov Thu Jan 8 19:11:16 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 8 Jan 2009 11:11:16 -0800 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed In-Reply-To: <4966463E.2020303@febo.com> References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <4966439C.10804@verizon.net> <4966463E.2020303@febo.com> Message-ID: James Lux, P.E. Task Manager, SOMD Software Defined Radios Flight Communications Systems Section Jet Propulsion Laboratory 4800 Oak Grove Drive, Mail Stop 161-213 Pasadena, CA, 91109 +1(818)354-2075 phone +1(818)393-6875 fax > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of John Ackermann N8UR > Sent: Thursday, January 08, 2009 10:30 AM > To: danrae at verizon.net; Discussion of precise time and > frequency measurement > Subject: Re: [time-nuts] 10 MHz Band-Pass Filter Needed > > Dan Rae wrote: > > Richard W. Solomon wrote: > >> The GPSDO I want to use has an output rich in harmonics. In some > >> cases that is good, but Murphy rules and in the application I have > >> today, it is not good. > >> > >> I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, > >> something small with SMA connectors would be ideal, but I > can live with BNC. > >> > >> Anyone have such a beast or know where I can get one ? I checked > >> Mini-Circuits and choked on the price !! You mean the ever popular BBP-10.7 for $41? Hard to beat that price for something comparable. > >> > >> > > > > Dick, it is really easy to build one. The wonderful (free!) filter > > design program ELSIE will give you all the help you need. I would > > have thought an hour or so with a couple of toroids would do the > > trick. Even just a Low Pass filter would usually do to > turn a square wave into a sine... > > It's actually much better to use an LPF than a bandpass > filter if you don't have subharmonic energy to deal with. An > LPF with a cutoff midway between the fundamental and the 2nd > harmonic will show much less tempco (in the form of phase > shift over temperature) than a bandpass filter. You might even be able to use some wonky little filter feedthrough with a suitable cutoff frequency. From magnus at rubidium.dyndns.org Thu Jan 8 19:19:01 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 20:19:01 +0100 Subject: [time-nuts] GPSDO time constant In-Reply-To: <8566.1231416696@critter.freebsd.dk> References: <8566.1231416696@critter.freebsd.dk> Message-ID: <496651A5.6050604@rubidium.dyndns.org> Poul-Henning Kamp skrev: > In message <4965E869.4090205 at rubidium.dyndns.org>, Magnus Danielson writes: > >> Ericsson created a rack system in which the bottom of the rack >> was actually forming a closed container with the floor. > > We had that at one place I worked, except it was two small "dogs" you > attached front and back a standard 19" rack. I never seen it myself, so you have more correct info. I go back from something told to me way back in time, so details got a bit fuzzy. > Trouble was that you had to wash the floor first, or the dust would > blow all over the place. You also have some rather high requirements on the floor quality, it needs to be fairly flat as well. Cheers, Magnus From magnus at rubidium.dyndns.org Thu Jan 8 19:25:44 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 20:25:44 +0100 Subject: [time-nuts] GPSDO time constant In-Reply-To: References: <1472.SVVXXVxVQkI=.1231435540.squirrel@webmail.securepacific.net> <49663CED.7080904@rubidium.dyndns.org> Message-ID: <49665338.6050705@rubidium.dyndns.org> Lux, James P skrev: > >> -----Original Message----- >> From: time-nuts-bounces at febo.com >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Magnus Danielson >> Sent: Thursday, January 08, 2009 9:51 AM >> To: Discussion of precise time and frequency measurement >> Subject: Re: [time-nuts] GPSDO time constant >> >> Hi Brooke, > >> So you didn't check out your HP gravity field wrapping mirror? >> Those are SO handy. :) >> >> Cheers, >> Magnus > > > I think that division got sold off when it became Agilent. I beleive ILM picked them up. Cheers, Magnus From james.p.lux at jpl.nasa.gov Thu Jan 8 19:29:23 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 8 Jan 2009 11:29:23 -0800 Subject: [time-nuts] GPSDO time constant In-Reply-To: <496651A5.6050604@rubidium.dyndns.org> References: <8566.1231416696@critter.freebsd.dk> <496651A5.6050604@rubidium.dyndns.org> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Magnus Danielson > Sent: Thursday, January 08, 2009 11:19 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] GPSDO time constant > > Poul-Henning Kamp skrev: > > In message <4965E869.4090205 at rubidium.dyndns.org>, Magnus > Danielson writes: > > > >> Ericsson created a rack system in which the bottom of the rack was > >> actually forming a closed container with the floor. > > > > We had that at one place I worked, except it was two small > "dogs" you > > attached front and back a standard 19" rack. > > I never seen it myself, so you have more correct info. I go > back from something told to me way back in time, so details > got a bit fuzzy. > > > Trouble was that you had to wash the floor first, or the dust would > > blow all over the place. > > You also have some rather high requirements on the floor > quality, it needs to be fairly flat as well. > When I worked in the special effects business, we used to use these all the time to move heavy stuff around. It actually doesn't require a "real flat" floor (1 cm grooves aren't a big issue). Think about them as small hovercraft. It also doesn't take much air pressure to lift things (large area * small pressure). For instance, folks build small hovercraft using electric leaf blowers as the pressurization fan to support a disk some 1.2m in diameter which will easily support a couple people. The lift pads we used were about 30cm in diameter. 1 psi (7kPa) lifts about 50kg. Moving around 1 ton things with 4 pads wasn't unusual. The rougher the floor, the more airflow you need. From w1ksz at earthlink.net Thu Jan 8 19:33:02 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Thu, 8 Jan 2009 14:33:02 -0500 (EST) Subject: [time-nuts] 10 MHz Band-Pass Filter Needed Message-ID: <10466671.1231443183109.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Looks like I can beat that price, the SCLF or SXLP devices are $8.95 each. 73, Dick, W1KSZ -----Original Message----- >From: "Lux, James P" >Sent: Jan 8, 2009 2:11 PM >To: Discussion of precise time and frequency measurement >Subject: Re: [time-nuts] 10 MHz Band-Pass Filter Needed > > > >James Lux, P.E. >Task Manager, SOMD Software Defined Radios >Flight Communications Systems Section >Jet Propulsion Laboratory >4800 Oak Grove Drive, Mail Stop 161-213 >Pasadena, CA, 91109 >+1(818)354-2075 phone >+1(818)393-6875 fax > >> -----Original Message----- >> From: time-nuts-bounces at febo.com >> [mailto:time-nuts-bounces at febo.com] On Behalf Of John Ackermann N8UR >> Sent: Thursday, January 08, 2009 10:30 AM >> To: danrae at verizon.net; Discussion of precise time and >> frequency measurement >> Subject: Re: [time-nuts] 10 MHz Band-Pass Filter Needed >> >> Dan Rae wrote: >> > Richard W. Solomon wrote: >> >> The GPSDO I want to use has an output rich in harmonics. In some >> >> cases that is good, but Murphy rules and in the application I have >> >> today, it is not good. >> >> >> >> I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, >> >> something small with SMA connectors would be ideal, but I >> can live with BNC. >> >> >> >> Anyone have such a beast or know where I can get one ? I checked >> >> Mini-Circuits and choked on the price !! > >You mean the ever popular BBP-10.7 for $41? >Hard to beat that price for something comparable. > > >> >> >> >> >> > >> > Dick, it is really easy to build one. The wonderful (free!) filter >> > design program ELSIE will give you all the help you need. I would >> > have thought an hour or so with a couple of toroids would do the >> > trick. Even just a Low Pass filter would usually do to >> turn a square wave into a sine... >> >> It's actually much better to use an LPF than a bandpass >> filter if you don't have subharmonic energy to deal with. An >> LPF with a cutoff midway between the fundamental and the 2nd >> harmonic will show much less tempco (in the form of phase >> shift over temperature) than a bandpass filter. > >You might even be able to use some wonky little filter feedthrough with a suitable cutoff frequency. > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From wb6bnq at cox.net Thu Jan 8 19:36:57 2009 From: wb6bnq at cox.net (WB6BNQ) Date: Thu, 08 Jan 2009 11:36:57 -0800 Subject: [time-nuts] GPSDO time constant References: <8566.1231416696@critter.freebsd.dk> <496651A5.6050604@rubidium.dyndns.org> Message-ID: <496655D9.B6FE0394@cox.net> "Lux, James P" wrote: When I worked in the special effects business, we used to use these all the time to move heavy stuff around. It actually doesn't require a "real flat" floor (1 cm grooves aren't a big issue). Think about them as small hovercraft. It also doesn't take much air pressure to lift things (large area * small pressure). For instance, folks build small hovercraft using electric leaf blowers as the pressurization fan to support a disk some 1.2m in diameter which will easily support a couple people. The lift pads we used were about 30cm in diameter. 1 psi (7kPa) lifts about 50kg. Moving around 1 ton things with 4 pads wasn't unusual. The rougher the floor, the more airflow you need. James, Do you have any web sites that show such a contration using leaf blowers ? thanks, Bill....WB6BNQ From chris.kuethe at gmail.com Thu Jan 8 19:42:52 2009 From: chris.kuethe at gmail.com (Chris Kuethe) Date: Thu, 8 Jan 2009 11:42:52 -0800 Subject: [time-nuts] GPSDO time constant In-Reply-To: <496655D9.B6FE0394@cox.net> References: <8566.1231416696@critter.freebsd.dk> <496651A5.6050604@rubidium.dyndns.org> <496655D9.B6FE0394@cox.net> Message-ID: <91981b3e0901081142k76d2de6cw5db4492dc6c9fef6@mail.gmail.com> On Thu, Jan 8, 2009 at 11:36 AM, WB6BNQ wrote: > Do you have any web sites that show such a contration using leaf > blowers ? mythbusters -- GDB has a 'break' feature; why doesn't it have 'fix' too? From bruce.griffiths at xtra.co.nz Thu Jan 8 19:56:29 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 08:56:29 +1300 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <7171.1231404449@critter.freebsd.dk> References: <7171.1231404449@critter.freebsd.dk> Message-ID: <49665A6D.2030100@xtra.co.nz> Poul-Henning Kamp wrote: > In message y.com>, Joseph M Gwinn writes: > > >>> That's technically speaking not triax, that's double shield. Triax >>> would have the conductors and one shield. >>> >> No, I think that's twinax: . >> >> Triax is a center plus two concentric shields: >> . >> > > Sorry, I fumbled what I wrote there. I would say wiki is wrong > here, the usage I am used to is: > coax: single conductor + shield > twinax: twisted pair + shield > triax: the wires + shield > Poul-Henning I have been unable to find a reference to triax consisting of 3 conductors within a shield, however such confusion is understandable given the confusion over quadrax:- concentric conductors for triax, quadrax, quintax etc: Cable Shielding for Electromagnetic Compatibility By Anatoly Tsaliovich http://www.lemo.com/techlibrary/glossary.jsp?catID=003 Alternate definitions for quadrax (but not triax): http://www.picwire.com/technical/Coax%20vs%20Triax.pdf http://www.ecnmag.com/ethernet-cable-suits-aerospace.aspx?menuid=336 Triax consisting of a central conductor surrounded by 2 concentric conductors is widely used to interconnect televsion cameras. Bruce From phk at phk.freebsd.dk Thu Jan 8 19:59:26 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 19:59:26 +0000 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: Your message of "Fri, 09 Jan 2009 08:56:29 +1300." <49665A6D.2030100@xtra.co.nz> Message-ID: <1946.1231444766@critter.freebsd.dk> In message <49665A6D.2030100 at xtra.co.nz>, Bruce Griffiths writes: >I have been unable to find a reference to triax consisting of 3 >conductors within a shield, however such confusion is understandable >given the confusion over quadrax:- I have only ever seen it used for very old 3-electrode condenser microphones. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bruce.griffiths at xtra.co.nz Thu Jan 8 20:00:37 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 09:00:37 +1300 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed In-Reply-To: <4966463E.2020303@febo.com> References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <4966439C.10804@verizon.net> <4966463E.2020303@febo.com> Message-ID: <49665B65.1050305@xtra.co.nz> John Ackermann N8UR wrote: > Dan Rae wrote: > >> Richard W. Solomon wrote: >> >>> The GPSDO I want to use has an output rich in harmonics. In some >>> cases that is good, but Murphy rules and in the application I have >>> today, it is not good. >>> >>> I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something >>> small with SMA connectors would be ideal, but I can live with BNC. >>> >>> Anyone have such a beast or know where I can get one ? I checked Mini-Circuits >>> and choked on the price !! >>> >>> >>> >> Dick, it is really easy to build one. The wonderful (free!) filter >> design program ELSIE will give you all the help you need. I would have >> thought an hour or so with a couple of toroids would do the trick. Even >> just a Low Pass filter would usually do to turn a square wave into a sine... >> > > It's actually much better to use an LPF than a bandpass filter if you > don't have subharmonic energy to deal with. An LPF with a cutoff midway > between the fundamental and the 2nd harmonic will show much less tempco > (in the form of phase shift over temperature) than a bandpass filter. > > John > > John Another approach is to use relatively high Q traps/bandstop filters to eliminate/minimise the unwanted harmonics together with a low pass filter. The high Q traps contribute little phase shift and phase shift tempco at the fundamental. Bruce From n3toy at yahoo.com Thu Jan 8 20:06:15 2009 From: n3toy at yahoo.com (James R. Gorr) Date: Thu, 8 Jan 2009 12:06:15 -0800 (PST) Subject: [time-nuts] TB PS/Antenna recommendations In-Reply-To: <04990E12-E284-4D5B-9D97-458E4379293C@hughes.net> Message-ID: <155892.27285.qm@web54105.mail.re2.yahoo.com> Here is some information on different power-supplies for the tbolt and their performance: http://www.leapsecond.com/pages/tbolt/noise.htm My tbolt is a little different, it uses: +12/+5/-7 volts. The only thing I had on hand was a box for of wall-warts, so I grabbed three out and configured them as such: http://n3toy.net/images/power_supply.png Not sure of the quality of power, but it works. Jamie --- On Wed, 1/7/09, Richard Moore wrote: > From: Richard Moore > Subject: Re: [time-nuts] TBolt antenna > To: time-nuts at febo.com > Date: Wednesday, January 7, 2009, 8:54 PM > On Jan 7, 2009, at 2:43 PM, time-nuts-request at febo.com > wrote: > > > > Message: 6 > > Date: Wed, 7 Jan 2009 17:08:22 -0500 > > From: "Ronald Held" > > > Subject: [time-nuts] TB PS/Antenna recommendations > > To: time-nuts at febo.com > > Message-ID: > > > <9a86fb0e0901071408r4a205518mc346d7694f9af5f8 at mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > I have not following all of discussions for a while, > so perhaps I > > missed out on some of this. What do people suggest for > a power supply > > and from where? The harder request is for an indoor > antenna probable > > placed up against the window. Reliable dealers or > stores would be very > > helpful. > > Ronald > > > > I'm using a fairly crappy triple-output open-frame > Autec supply from > Marlin P. Jones that was $13. I'm not recommending it, > but it works. > My antenna is an active patch type by Hawk that runs off > +5V from the > TBolt. It has a magnetic base for top of vehicle use. > I've got it > feeding two GPSDOs thru a splitter and it's working > great. I got it > from Synergy for $35 if I remember correctly -- been a > while. I've > got it duct taped to a 2x4 sticking our from under the eave > of my > lab. Most any active antenna will likely work OK outdoors, > but I > don't know about indoors -- think you'll want some > higher gain version. > > Dick Moore > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From james.p.lux at jpl.nasa.gov Thu Jan 8 20:07:24 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 8 Jan 2009 12:07:24 -0800 Subject: [time-nuts] GPSDO time constant In-Reply-To: <496655D9.B6FE0394@cox.net> References: <8566.1231416696@critter.freebsd.dk> <496651A5.6050604@rubidium.dyndns.org> <496655D9.B6FE0394@cox.net> Message-ID: Google "Leaf blower hovercraft" and you'll get dozens of useful hits. Here's a real old link: http://amasci.com/amateur/hovercft.html > -----Original Message----- > James, > > Do you have any web sites that show such a contration using leaf > blowers ? > > thanks, > > Bill....WB6BNQ From newell at cei.net Thu Jan 8 20:07:45 2009 From: newell at cei.net (Scott Newell) Date: Thu, 08 Jan 2009 14:07:45 -0600 Subject: [time-nuts] Standards sought for immunity of shielded cablelinks to power-frequency ground loops In-Reply-To: <1946.1231444766@critter.freebsd.dk> References: Message-ID: <200901082007.n08K7kxd018543@mail963c35.nsolutionszone.com> At 01:59 PM 1/8/2009 , Poul-Henning Kamp wrote: >In message <49665A6D.2030100 at xtra.co.nz>, Bruce Griffiths writes: > >>I have been unable to find a reference to triax consisting of 3 >>conductors within a shield, however such confusion is understandable >>given the confusion over quadrax:- > >I have only ever seen it used for very old 3-electrode condenser >microphones. Doesn't Keithley use triax connectors on some of their high-impedance instrumentation? -- newell N5TNL From holrum at hotmail.com Thu Jan 8 20:17:59 2009 From: holrum at hotmail.com (Mark Sims) Date: Thu, 8 Jan 2009 20:17:59 +0000 Subject: [time-nuts] GPSDO time constant In-Reply-To: References: Message-ID: In the world of precision scales you can often beat the many of the manufactures specs by an order of magnitude by adjusting and calibrating the scale in the exact location and orientation where it will be used (and not moving it or afterwards). Some of the adjustments involve moving rather crudely threaded mechanical adjustments the equivalent of a few wavelengths of light. There is no way to actually make the adjustments other than trial and error... move it enough times and it will eventually wind up in the right place... and hysteresis and backlash are a bitch... The alignment spec for the color monitor in the HP16500 logic analyzers says to face the unit to the west when adjusting it (but they don't say which end to point west). Also some of the adjustments are on the bottom of the monitor and others are on the side. You usually make the adjustments with the unit on its side... but nobody ever runs the unit in that orientation. ------------ I've heard that the xtal oscillator cal procedure for some HP test equipment says that the instrument should be in the same position as when it's operating. For heavy rack equipment that means you lay on a mechanics creeper when making the adjustment rather than flipping the instrument 90 degrees on a bench. _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From bruce.griffiths at xtra.co.nz Thu Jan 8 20:58:51 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 09:58:51 +1300 Subject: [time-nuts] Standards sought for immunity of shielded cablelinks to power-frequency ground loops In-Reply-To: <200901082007.n08K7kxd018543@mail963c35.nsolutionszone.com> References: <200901082007.n08K7kxd018543@mail963c35.nsolutionszone.com> Message-ID: <4966690B.8000800@xtra.co.nz> Scott Newell wrote: > At 01:59 PM 1/8/2009 , Poul-Henning Kamp wrote: > >> In message <49665A6D.2030100 at xtra.co.nz>, Bruce Griffiths writes: >> >> >>> I have been unable to find a reference to triax consisting of 3 >>> conductors within a shield, however such confusion is understandable >>> given the confusion over quadrax:- >>> >> I have only ever seen it used for very old 3-electrode condenser >> microphones. >> > > Doesn't Keithley use triax connectors on some of their high-impedance > instrumentation? > > Scott They use the concentic conductor definition/interpretation of the term triax. I was seeking an example of the 3 conductor within a shield interpretation. See the links on quadrax posted earlier for an idea of the pervasive rampant confusion. Bruce From richiem at hughes.net Thu Jan 8 21:04:44 2009 From: richiem at hughes.net (Richard Moore) Date: Thu, 8 Jan 2009 13:04:44 -0800 Subject: [time-nuts] GPSDO TC In-Reply-To: References: Message-ID: On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: > Message: 6 > Date: Thu, 08 Jan 2009 11:51:50 +0100 > From: Magnus Danielson > Subject: Re: [time-nuts] GPSDO time constant > To: Tom Van Baak , Discussion of precise time and > frequency measurement > >>> > For ThunderBolt owners it is pretty straightforward to adjust the > TC and > damping, which is very nice. Use this oppertunity! So, Magnus (and Tom), what damping factor do you suggest for a TBolt? I'm running a verrry long TC now. If 1.2 is not actually critically damped, what value would be? Any guesses? BTW, I really like that plot of Tom's that tracks the oven and then gets better from the GPS... Dick Moore From magnus at rubidium.dyndns.org Thu Jan 8 21:21:40 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 22:21:40 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: References: Message-ID: <49666E64.9030207@rubidium.dyndns.org> Dick, Richard Moore skrev: > On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: > >> Message: 6 >> Date: Thu, 08 Jan 2009 11:51:50 +0100 >> From: Magnus Danielson >> Subject: Re: [time-nuts] GPSDO time constant >> To: Tom Van Baak , Discussion of precise time and >> frequency measurement >> For ThunderBolt owners it is pretty straightforward to adjust the >> TC and >> damping, which is very nice. Use this oppertunity! > > So, Magnus (and Tom), what damping factor do you suggest for a TBolt? > I'm running a verrry long TC now. If 1.2 is not actually critically > damped, what value would be? Any guesses? BTW, I really like that > plot of Tom's that tracks the oven and then gets better from the GPS... Assuming that damping factors match classical analysis of damping, then the square root of 2 is the answer... 1.414 or there abouts. I would be more conservative than that. I would consider damping factors such as 3-4 or so. I have no support from measurements on GPSDOs but it is reasonable that the rise of gain at and near the PLL frequency we see for other systems will occur and result in similar effects even here. This gain raises the noise floor and amount of gain is directly coupled to the damping factor. It's just standard PLL stuff all over again. The only difference is that we view the result in ADEV or MDEV views. Cheers, Magnus From bruce.griffiths at xtra.co.nz Thu Jan 8 21:28:35 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 10:28:35 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: References: Message-ID: <49667003.8040403@xtra.co.nz> Richard Moore wrote: > On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: > > >> Message: 6 >> Date: Thu, 08 Jan 2009 11:51:50 +0100 >> From: Magnus Danielson >> Subject: Re: [time-nuts] GPSDO time constant >> To: Tom Van Baak , Discussion of precise time and >> frequency measurement >> >> For ThunderBolt owners it is pretty straightforward to adjust the >> TC and >> damping, which is very nice. Use this oppertunity! >> > > So, Magnus (and Tom), what damping factor do you suggest for a TBolt? > I'm running a verrry long TC now. If 1.2 is not actually critically > damped, what value would be? Any guesses? BTW, I really like that > plot of Tom's that tracks the oven and then gets better from the GPS... > > Dick Moore > > Richard As always, the problem is how do you know that the time constant you are using is anywhere near optimum? Bruce From bruce.griffiths at xtra.co.nz Thu Jan 8 21:42:58 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 10:42:58 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: <49666E64.9030207@rubidium.dyndns.org> References: <49666E64.9030207@rubidium.dyndns.org> Message-ID: <49667362.2010202@xtra.co.nz> Magnus Danielson wrote: > Dick, > > Richard Moore skrev: > >> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: >> >> >>> Message: 6 >>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>> From: Magnus Danielson >>> Subject: Re: [time-nuts] GPSDO time constant >>> To: Tom Van Baak , Discussion of precise time and >>> frequency measurement >>> For ThunderBolt owners it is pretty straightforward to adjust the >>> TC and >>> damping, which is very nice. Use this oppertunity! >>> >> So, Magnus (and Tom), what damping factor do you suggest for a TBolt? >> I'm running a verrry long TC now. If 1.2 is not actually critically >> damped, what value would be? Any guesses? BTW, I really like that >> plot of Tom's that tracks the oven and then gets better from the GPS... >> > > Assuming that damping factors match classical analysis of damping, then > the square root of 2 is the answer... 1.414 or there abouts. > > I would be more conservative than that. I would consider damping factors > such as 3-4 or so. I have no support from measurements on GPSDOs but it > is reasonable that the rise of gain at and near the PLL frequency we see > for other systems will occur and result in similar effects even here. > This gain raises the noise floor and amount of gain is directly coupled > to the damping factor. It's just standard PLL stuff all over again. The > only difference is that we view the result in ADEV or MDEV views. > > Cheers, > Magnus > > Hej Magnus For a second order loop, the noise bandwidth is minimised for a fixed time constant by choosing a damping factor of 0.5. Using a damping factor of 1.414 increases the noise bandwidth by about 60%. Using a damping factor of 0.7071 only increases the loop noise bandwidth by about 6%. A damping factor of 0.3 increases the noise bandwidth by about 13%. Bruce From bg at lysator.liu.se Thu Jan 8 21:55:25 2009 From: bg at lysator.liu.se (=?ISO-8859-1?Q?Bj=F6rn?= Gabrielsson) Date: Thu, 08 Jan 2009 22:55:25 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: <49667003.8040403@xtra.co.nz> References: <49667003.8040403@xtra.co.nz> Message-ID: <1231451725.15547.56.camel@bg-desktop> On Fri, 2009-01-09 at 10:28 +1300, Bruce Griffiths wrote: > Richard Moore wrote: > > On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: > > > > > >> Message: 6 > >> Date: Thu, 08 Jan 2009 11:51:50 +0100 > >> From: Magnus Danielson > >> Subject: Re: [time-nuts] GPSDO time constant > >> To: Tom Van Baak , Discussion of precise time and > >> frequency measurement > >> > >> For ThunderBolt owners it is pretty straightforward to adjust the > >> TC and > >> damping, which is very nice. Use this oppertunity! > >> > > > > So, Magnus (and Tom), what damping factor do you suggest for a TBolt? > > I'm running a verrry long TC now. If 1.2 is not actually critically > > damped, what value would be? Any guesses? BTW, I really like that > > plot of Tom's that tracks the oven and then gets better from the GPS... > > > > Dick Moore > > > > > Richard > > As always, the problem is how do you know that the time constant you are > using is anywhere near optimum? > > > Bruce So what is optimum... from control theory we learn, that with an even better model of your system, you can push performance to the edge! But you always loose robustness in doing that. So what is the implication of a to large TC here? Nothing going instable in the control loop? We are just following the "freerunning" OCXO curve past the point where GPS goes downhill? -- Bj?rn From bruce.griffiths at xtra.co.nz Thu Jan 8 22:09:19 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 11:09:19 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: <1231451725.15547.56.camel@bg-desktop> References: <49667003.8040403@xtra.co.nz> <1231451725.15547.56.camel@bg-desktop> Message-ID: <4966798F.20604@xtra.co.nz> Bj?rn Gabrielsson wrote: > On Fri, 2009-01-09 at 10:28 +1300, Bruce Griffiths wrote: > >> Richard Moore wrote: >> >>> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: >>> >>> >>> >>>> Message: 6 >>>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>>> From: Magnus Danielson >>>> Subject: Re: [time-nuts] GPSDO time constant >>>> To: Tom Van Baak , Discussion of precise time and >>>> frequency measurement >>>> >>>> For ThunderBolt owners it is pretty straightforward to adjust the >>>> TC and >>>> damping, which is very nice. Use this oppertunity! >>>> >>>> >>> So, Magnus (and Tom), what damping factor do you suggest for a TBolt? >>> I'm running a verrry long TC now. If 1.2 is not actually critically >>> damped, what value would be? Any guesses? BTW, I really like that >>> plot of Tom's that tracks the oven and then gets better from the GPS... >>> >>> Dick Moore >>> >>> >>> >> Richard >> >> As always, the problem is how do you know that the time constant you are >> using is anywhere near optimum? >> >> >> Bruce >> > > So what is optimum... from control theory we learn, that with an even > better model of your system, you can push performance to the edge! But > you always loose robustness in doing that. > > So what is the implication of a to large TC here? Nothing going instable > in the control loop? We are just following the "freerunning" OCXO curve > past the point where GPS goes downhill? > > -- > > Bj?rn > > > Bj?rn My point was that measurements are required to establish the optimum for each individual OCXO not just for a given OCXO model. Bruce From magnus at rubidium.dyndns.org Thu Jan 8 22:28:36 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 08 Jan 2009 23:28:36 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: <49667362.2010202@xtra.co.nz> References: <49666E64.9030207@rubidium.dyndns.org> <49667362.2010202@xtra.co.nz> Message-ID: <49667E14.3070801@rubidium.dyndns.org> Bruce Griffiths skrev: > Magnus Danielson wrote: >> Dick, >> >> Richard Moore skrev: >> >>> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: >>> >>> >>>> Message: 6 >>>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>>> From: Magnus Danielson >>>> Subject: Re: [time-nuts] GPSDO time constant >>>> To: Tom Van Baak , Discussion of precise time and >>>> frequency measurement >>>> For ThunderBolt owners it is pretty straightforward to adjust the >>>> TC and >>>> damping, which is very nice. Use this oppertunity! >>>> >>> So, Magnus (and Tom), what damping factor do you suggest for a TBolt? >>> I'm running a verrry long TC now. If 1.2 is not actually critically >>> damped, what value would be? Any guesses? BTW, I really like that >>> plot of Tom's that tracks the oven and then gets better from the GPS... >>> >> Assuming that damping factors match classical analysis of damping, then >> the square root of 2 is the answer... 1.414 or there abouts. >> >> I would be more conservative than that. I would consider damping factors >> such as 3-4 or so. I have no support from measurements on GPSDOs but it >> is reasonable that the rise of gain at and near the PLL frequency we see >> for other systems will occur and result in similar effects even here. >> This gain raises the noise floor and amount of gain is directly coupled >> to the damping factor. It's just standard PLL stuff all over again. The >> only difference is that we view the result in ADEV or MDEV views. >> >> Cheers, >> Magnus >> >> > Hej Magnus > > For a second order loop, the noise bandwidth is minimised for a fixed > time constant by choosing a damping factor of 0.5. > Using a damping factor of 1.414 increases the noise bandwidth by about 60%. > Using a damping factor of 0.7071 only increases the loop noise bandwidth > by about 6%. > A damping factor of 0.3 increases the noise bandwidth by about 13%. Yes, but the bump comes from the increase gain around the resonance and spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure does not really comply here since they usually build on a simplified model of noise type (white noise - gaussian). A simple check in Gardiner provides both the generic integrating formula, simplified results and a graph showing the smae numbers that you give. I rather beleive what ADEV, MDEV and TDEV experience in this context. We could go back to the real integration formula, adapt it to various powers of f^-n noises and analyse it for the same set of PLL loop filters as analysed by Gardiner. Similarly we could cook up a simulation and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth measures can be calculated alongside. I am somewhat surprised that you missed the opportunity to correct me as I was giving the incorrect value for damping factor of a critically damped system. It is the square root of 1/2 and not 2, thus 0.7071 is the appropriate damping factor for critically damped systems. I am somewhat surprised that when we have been discussing the bandwidth of the PLLs and considering OCXOs being running with fairly high drift rate we have been assuming second degree loops. This form of acceleration requires third degree responses for proper handling, as being well documented in literature such as Gardiner. Going for third degree response the bandwidth of the loop can be (at least more freely) disconnected from tracking requirements due to drift rate. Another aspect worth mentioning is that a pure PLL with a small bandwidth has a very long trackin period. Heuristics to use wider bandwidths or use frequency measure aided bootstrapping or a diffrential element (PID rather than PI regulator) which is equivalent to also feed a frequency error measurement into the loop will significantly aid the loop in quick lock-in. A Kalman filter approach is just along the same lines and when considered next to some more elaborate schemes of heuristic aided PLL seems to much simpler. While the Kalman filter approach isn't as optimum as claimed to be it is still a useful tool. Cheers, Magnus From bg at lysator.liu.se Thu Jan 8 22:29:20 2009 From: bg at lysator.liu.se (=?ISO-8859-1?Q?Bj=F6rn?= Gabrielsson) Date: Thu, 08 Jan 2009 23:29:20 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: <4966798F.20604@xtra.co.nz> References: <49667003.8040403@xtra.co.nz> <1231451725.15547.56.camel@bg-desktop> <4966798F.20604@xtra.co.nz> Message-ID: <1231453760.15547.63.camel@bg-desktop> On Fri, 2009-01-09 at 11:09 +1300, Bruce Griffiths wrote: [...snip... > My point was that measurements are required to establish the optimum for > each individual OCXO not just for a given OCXO model. > > Bruce Are those measurements possible to do in real time with only the GPSDO? -- Bj?rn From bruce.griffiths at xtra.co.nz Thu Jan 8 22:36:53 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 11:36:53 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: <1231453760.15547.63.camel@bg-desktop> References: <49667003.8040403@xtra.co.nz> <1231451725.15547.56.camel@bg-desktop> <4966798F.20604@xtra.co.nz> <1231453760.15547.63.camel@bg-desktop> Message-ID: <49668005.1090608@xtra.co.nz> Bj?rn Gabrielsson wrote: > On Fri, 2009-01-09 at 11:09 +1300, Bruce Griffiths wrote: > [...snip... > > >> My point was that measurements are required to establish the optimum for >> each individual OCXO not just for a given OCXO model. >> >> Bruce >> > > Are those measurements possible to do in real time with only the GPSDO? > > -- > > Bj?rn > > > Bj?rn Not really, however one can measure the relative ADEV as a function of tau for the free running OCXO and the timing receiver. There will be a broad minimum at some tau. The optimum time constant may lie somewhere in the vicinity of that minimum. Its probably impossible to do much better than that without a nice stable statistically independent (for all tau) frequency standard. Bruce From dave.g0dja at tiscali.co.uk Thu Jan 8 22:46:13 2009 From: dave.g0dja at tiscali.co.uk (Dave Ackrill) Date: Thu, 08 Jan 2009 22:46:13 +0000 Subject: [time-nuts] GPSDO TC In-Reply-To: References: Message-ID: <49668235.1010704@tiscali.co.uk> Can someone cure this fail message please? Thanks... Secure Connection Failed www.febo.com uses an invalid security certificate. The certificate is not trusted because it is self signed. The certificate is only valid for febo.com. The certificate expired on 11/11/2008 14:57. (Error code: sec_error_expired_issuer_certificate) * This could be a problem with the server's configuration, or it could be someone trying to impersonate the server. * If you have connected to this server successfully in the past, the error may be temporary, and you can try again later. Or you can add an exception? From rbarrioss at msn.com Thu Jan 8 22:47:29 2009 From: rbarrioss at msn.com (Roberto Barrios) Date: Thu, 8 Jan 2009 22:47:29 +0000 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed (Roberto Barrios) In-Reply-To: References: Message-ID: > The GPSDO I want to use has an output rich in harmonics. In some> cases that is good, but Murphy rules and in the application I have> today, it is not good.> > I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something> small with SMA connectors would be ideal, but I can live with BNC.> > Anyone have such a beast or know where I can get one ? I checked Mini-Circuits> and choked on the price !!> > Thanks, Dick, W1KSZ> Hi Dick, There are plans for a simple nine section low pass filter here: http://jwmeng.com/AppNote/AppNote003.html You can also use (I did) a filter from an old 10mbit ethernet network card, as suggested here: http://www.uhf-satcom.com/misc/10MHz_dist/ I joined this list just yesterday, so hello to everyone. I live in Madrid and I'm interested in frequency measurement for HAM purposes. Not understanding most of the things you guys discuss here, I thought I would never have the opportunity to give my 2 cents... I?m currently working on a simple GPSDO that (luckily) some of you may find interesting. I'll send you details in a few days so I can get your opinions and (hopefully) it inspires/helps someone. Bests Regards & 73's Roberto Barrios, EB4EQA Madrid, Spain _________________________________________________________________ See how Windows? connects the people, information, and fun that are part of your life http://clk.atdmt.com/MRT/go/119463819/direct/01/ From bruce.griffiths at xtra.co.nz Thu Jan 8 22:53:40 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 11:53:40 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: <49667E14.3070801@rubidium.dyndns.org> References: <49666E64.9030207@rubidium.dyndns.org> <49667362.2010202@xtra.co.nz> <49667E14.3070801@rubidium.dyndns.org> Message-ID: <496683F4.4000309@xtra.co.nz> Hej Magnus Magnus Danielson wrote: > Bruce Griffiths skrev: > >> Magnus Danielson wrote: >> >>> Dick, >>> >>> Richard Moore skrev: >>> >>> >>>> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: >>>> >>>> >>>> >>>>> Message: 6 >>>>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>>>> From: Magnus Danielson >>>>> Subject: Re: [time-nuts] GPSDO time constant >>>>> To: Tom Van Baak , Discussion of precise time and >>>>> frequency measurement >>>>> For ThunderBolt owners it is pretty straightforward to adjust the >>>>> TC and >>>>> damping, which is very nice. Use this oppertunity! >>>>> >>>>> >>>> So, Magnus (and Tom), what damping factor do you suggest for a TBolt? >>>> I'm running a verrry long TC now. If 1.2 is not actually critically >>>> damped, what value would be? Any guesses? BTW, I really like that >>>> plot of Tom's that tracks the oven and then gets better from the GPS... >>>> >>>> >>> Assuming that damping factors match classical analysis of damping, then >>> the square root of 2 is the answer... 1.414 or there abouts. >>> >>> I would be more conservative than that. I would consider damping factors >>> such as 3-4 or so. I have no support from measurements on GPSDOs but it >>> is reasonable that the rise of gain at and near the PLL frequency we see >>> for other systems will occur and result in similar effects even here. >>> This gain raises the noise floor and amount of gain is directly coupled >>> to the damping factor. It's just standard PLL stuff all over again. The >>> only difference is that we view the result in ADEV or MDEV views. >>> >>> Cheers, >>> Magnus >>> >>> >>> >> Hej Magnus >> >> For a second order loop, the noise bandwidth is minimised for a fixed >> time constant by choosing a damping factor of 0.5. >> Using a damping factor of 1.414 increases the noise bandwidth by about 60%. >> Using a damping factor of 0.7071 only increases the loop noise bandwidth >> by about 6%. >> A damping factor of 0.3 increases the noise bandwidth by about 13%. >> > > Yes, but the bump comes from the increase gain around the resonance and > spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure > does not really comply here since they usually build on a simplified > model of noise type (white noise - gaussian). A simple check in Gardiner > provides both the generic integrating formula, simplified results and a > graph showing the smae numbers that you give. > Whilst the phase noise of a sawtooth corrected M12+T GPS timing receiver approximates white phase noise (at least for tau < 1 day), this may not be so for the receiver used in the Thunderbolt. The phase noise of the OCXO certainly cannot be accurately modeled as white phase noise for large tau. > I rather beleive what ADEV, MDEV and TDEV experience in this context. > > Yes measurements are the key but if one doesnt have a suitable statistically independent low noise frequency reference it isnt possible to optimise the loop parameters for an individual GPSDO. > We could go back to the real integration formula, adapt it to various > powers of f^-n noises and analyse it for the same set of PLL loop > filters as analysed by Gardiner. Similarly we could cook up a simulation > and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth > measures can be calculated alongside. > > I am somewhat surprised that you missed the opportunity to correct me as > I was giving the incorrect value for damping factor of a critically > damped system. It is the square root of 1/2 and not 2, thus 0.7071 is > the appropriate damping factor for critically damped systems. > > I had noted that your quoted damping factor was incorrect but I suspected that you would realise that. Actually according to Gardener critical damping factor is 1 ( minimum settling with no overshoot for a phase step). However a damping factor of 0.7071 is widely used. > I am somewhat surprised that when we have been discussing the bandwidth > of the PLLs and considering OCXOs being running with fairly high drift > rate we have been assuming second degree loops. This form of > acceleration requires third degree responses for proper handling, as > being well documented in literature such as Gardiner. Going for third > degree response the bandwidth of the loop can be (at least more freely) > disconnected from tracking requirements due to drift rate. > I only mentioned second order type II loops as the analysis is somewhat simpler and there is no indication from the number of tuning parameters for the Thunderbolt that a higher order loop is involved. > Another aspect worth mentioning is that a pure PLL with a small > bandwidth has a very long trackin period. Heuristics to use wider > bandwidths or use frequency measure aided bootstrapping or a diffrential > element (PID rather than PI regulator) which is equivalent to also feed > a frequency error measurement into the loop will significantly aid the > loop in quick lock-in. A Kalman filter approach is just along the same > lines and when considered next to some more elaborate schemes of > heuristic aided PLL seems to much simpler. While the Kalman filter > approach isn't as optimum as claimed to be it is still a useful tool. > > Cheers, > Magnus > > Bruce From jra at febo.com Thu Jan 8 22:53:56 2009 From: jra at febo.com (John Ackermann N8UR) Date: Thu, 08 Jan 2009 17:53:56 -0500 Subject: [time-nuts] GPSDO TC In-Reply-To: <49668235.1010704@tiscali.co.uk> References: <49668235.1010704@tiscali.co.uk> Message-ID: <49668404.3020107@febo.com> You can cure it by accepting the certificate... Since I'm not doing ecommerce from febo.com, I'm not willing to pay the hundred dollar plus per year fee for an "official" SSL certificate, and use a home-grown one, which is fine for stopping eavesdropping on the wire. It will give the "self-signed" error because, well, it is. :-) John ---- Dave Ackrill said the following on 01/08/2009 05:46 PM: > Can someone cure this fail message please? > > Thanks... > > Secure Connection Failed > > > > > > > > > > > > > > www.febo.com uses an invalid security certificate. > > The certificate is not trusted because it is self signed. > The certificate is only valid for febo.com. > The certificate expired on 11/11/2008 14:57. > > (Error code: sec_error_expired_issuer_certificate) > > > > > > > > > > * This could be a problem with the server's configuration, or it could > be someone trying to impersonate the server. > > > * If you have connected to this server successfully in the past, the > error may be temporary, and you can try again later. From bruce.griffiths at xtra.co.nz Thu Jan 8 22:58:11 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 11:58:11 +1300 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed (Roberto Barrios) In-Reply-To: References: Message-ID: <49668503.4050808@xtra.co.nz> Roberto Barrios wrote: >> The GPSDO I want to use has an output rich in harmonics. In some> cases that is good, but Murphy rules and in the application I have> today, it is not good.> > I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something> small with SMA connectors would be ideal, but I can live with BNC.> > Anyone have such a beast or know where I can get one ? I checked Mini-Circuits> and choked on the price !!> > Thanks, Dick, W1KSZ> >> > Hi Dick, > > There are plans for a simple nine section low pass filter here: > http://jwmeng.com/AppNote/AppNote003.html > > You can also use (I did) a filter from an old 10mbit ethernet network card, as suggested here: > http://www.uhf-satcom.com/misc/10MHz_dist/ > > I joined this list just yesterday, so hello to everyone. I live in Madrid and I'm interested in frequency measurement for HAM purposes. Not understanding most of the things you guys discuss here, I thought I would never have the opportunity to give my 2 cents... I?m currently working on a simple GPSDO that (luckily) some of you may find interesting. I'll send you details in a few days so I can get your opinions and (hopefully) it inspires/helps someone. > > Bests Regards & 73's > Roberto Barrios, EB4EQA > Madrid, Spain > > > Roberto But what is the filter phase shift tempco? In the presence of temperature changes the filter phase shift variation is equivalent to phase and frequency modulation of the output of the filter. One cure is to use low tempco filter parts and place the filter in an oven. Bruce From magnus at rubidium.dyndns.org Thu Jan 8 23:08:49 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 09 Jan 2009 00:08:49 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: <1231451725.15547.56.camel@bg-desktop> References: <49667003.8040403@xtra.co.nz> <1231451725.15547.56.camel@bg-desktop> Message-ID: <49668781.2070106@rubidium.dyndns.org> >> As always, the problem is how do you know that the time constant you are >> using is anywhere near optimum? >> >> >> Bruce > > So what is optimum... from control theory we learn, that with an even > better model of your system, you can push performance to the edge! But > you always loose robustness in doing that. Trouble is, we have many more variables and our set of goodness measurements are the ADEV and friends, which is much more troublesome to analyse than traditional variance and noise bandwidth values. The variance for a PLL is an integral over f multiplying the noise power function of f with the square of the amplitude response over f. It is traditional to simplify this by assume a white noise power N0 (V?/Hz) in which case the noise level creeps out of the integral (since it now is a variable independent of f) and the remaining integral is that of the squared amplitude response of the filter. This can then further be generalized to the noise bandwidth formula. Notice how we started from the variance measure, our traditional sigma value. We already know that it is insufficient to qualify the noise since the the f^-n noise powers does not converge on integration. Using derivate formulations like noise bandwidth those inherit the analysis problems. It even becomes hard achieving something similar as it now is a balance between different noise powers and filtering combines them in new interesting ways. I think we need to either do hard analysis or we notice the tendencies in measures and try to explain them in other general tendencies and knowledge and draw some simplified conclusions and get away with it. > So what is the implication of a to large TC here? Nothing going instable > in the control loop? We are just following the "freerunning" OCXO curve > past the point where GPS goes downhill? For a second degree loop it would mean loosing lock or not be able to pull in properly. The actual problem is dynamics. Loop bandwidth will scale drift rate numbers with the square. Cheers, Magnus From sar10538 at gmail.com Thu Jan 8 23:18:04 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Fri, 9 Jan 2009 12:18:04 +1300 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed (Roberto Barrios) In-Reply-To: <49668503.4050808@xtra.co.nz> References: <49668503.4050808@xtra.co.nz> Message-ID: <1231b6a80901081518q45349aa7x20ac1d0737b55177@mail.gmail.com> Hi Roberto, Congratulations! On your very first visit here, you have hit the Bruce Effect. Do not be alarmed! Just place your filter in a temperature controlled oven regulated to a change of 1E-99C for external temp changes of -100C to +200C and you may be alright, I did say "may". But then, for ham purposes, the phase/frequency changes should make no difference to you. If you were NIST, well that would be another matter. But this is a time-nuts forum and people here think in the 1E-16 range. Some of us here just strive for the best and find that some of our needs are easily covered with much more modest equipment. That does not mean we are happy to accept this limited capability for projects we may wish to do in the future. You have made a wise choice coming here, it has low noise (accept for my posts) and some of the best minds contributing. Keep watching this space and join in to ask question and give ideas. Do not be put off by any comments on what you post, there are high ideals here and some may not be the most tactful people when they make their comments. You will learn a great deal here and you will certainly get the time bug. 73, Steve - ZL3TUV & G8KVD 2009/1/9 Bruce Griffiths : > Roberto Barrios wrote: >>> The GPSDO I want to use has an output rich in harmonics. In some> cases that is good, but Murphy rules and in the application I have> today, it is not good.> > I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something> small with SMA connectors would be ideal, but I can live with BNC.> > Anyone have such a beast or know where I can get one ? I checked Mini-Circuits> and choked on the price !!> > Thanks, Dick, W1KSZ> >>> >> Hi Dick, >> >> There are plans for a simple nine section low pass filter here: >> http://jwmeng.com/AppNote/AppNote003.html >> >> You can also use (I did) a filter from an old 10mbit ethernet network card, as suggested here: >> http://www.uhf-satcom.com/misc/10MHz_dist/ >> >> I joined this list just yesterday, so hello to everyone. I live in Madrid and I'm interested in frequency measurement for HAM purposes. Not understanding most of the things you guys discuss here, I thought I would never have the opportunity to give my 2 cents... I?m currently working on a simple GPSDO that (luckily) some of you may find interesting. I'll send you details in a few days so I can get your opinions and (hopefully) it inspires/helps someone. >> >> Bests Regards & 73's >> Roberto Barrios, EB4EQA >> Madrid, Spain >> >> >> > Roberto > > But what is the filter phase shift tempco? > In the presence of temperature changes the filter phase shift variation > is equivalent to phase and frequency modulation of the output of the filter. > One cure is to use low tempco filter parts and place the filter in an oven. > > Bruce > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From phk at phk.freebsd.dk Thu Jan 8 23:26:48 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Jan 2009 23:26:48 +0000 Subject: [time-nuts] GPSDO TC In-Reply-To: Your message of "Fri, 09 Jan 2009 00:08:49 +0100." <49668781.2070106@rubidium.dyndns.org> Message-ID: <1896.1231457208@critter.freebsd.dk> >> So what is optimum... from control theory we learn, that with an even >> better model of your system, you can push performance to the edge! But >> you always loose robustness in doing that. One thing to remember: control theory is akin to a taxinomy which has only "elephants" and "non elephants", in that sense that non-linear control theory is not widely taught and generally considered an evil to stay away from at all cost. Traditional PLL methods are inherently linear and consequently limited in what they can do, but you can achive suprisingly good results by combining a classical PLL with non-linear higher modes or mode switches. You can of course, in the absense of solid theory for what you are attempting, also get it horribly wrong, as in the NTP PLL :-) But the machine-control and robotics community has finally realized that to get machines to "have the moves" they have to abandon classical control theory, drop the poles and zeros of the plane and instead build physical predictive models. The first area to pick up on this big time were disk drive arm actuators, which are nowhere near a simple differential equation any more. And timekeeping lends itself well to experiment with this, not the least because getting it wrong doesn't smash anything valuable :-) For instance, one thing to think about in the context of GPSDO's is that in addition to the PPS signal, we also have all the other information. For intance it would make sense to loosen the PLL a bit when satellites enter and leave the solution, because that often moves the GPS signal a few nanoseconds abrubtly, which is enough to throw most PLLs into thinking you had a phase jump. There is also the complex 12h signal in most GPS receivers PPS, should that be notched out of the PLL so that it will not react to offsets that have a 12h period ? (obviously only in stationary applications.) So many things to try, so little time... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From james.p.lux at jpl.nasa.gov Fri Jan 9 00:00:45 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 8 Jan 2009 16:00:45 -0800 Subject: [time-nuts] GPSDO TC In-Reply-To: <1896.1231457208@critter.freebsd.dk> References: Your message of "Fri, 09 Jan 2009 00:08:49 +0100." <49668781.2070106@rubidium.dyndns.org> <1896.1231457208@critter.freebsd.dk> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Poul-Henning Kamp > Sent: Thursday, January 08, 2009 3:27 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] GPSDO TC > > > > And timekeeping lends itself well to experiment with this, > not the least because getting it wrong doesn't smash anything > valuable :-) But you might show up early or late for dinner, which could have dire consequences. > > For instance, one thing to think about in the context of > GPSDO's is that in addition to the PPS signal, we also have > all the other information. > > For intance it would make sense to loosen the PLL a bit when > satellites enter and leave the solution, because that often > moves the GPS signal a few nanoseconds abrubtly, which is > enough to throw most PLLs into thinking you had a phase jump. This brings up an interesting question. A lot of the discussion here is about taking an off the shelf GPS receiver of one sort or another, and then putting something around it to "improve" the system. A goodly part of what's in the "around it" is essentially deconvolving (conceptually) the peculiarities of the receiver. These days, it's not that hard to build the RF section of a GPS receiver, and one can do the processing in an FPGA and attached CPU. Is there an "open source" signal processing chain (i.e. to acquire and track the PN codes, and generate the raw observables, and then to do the timing/nav solution)? If such a thing exists, or can be created, then you can do a fancier nav solution that explicitly accounts for all the satellites and weights them differently as they appear and disappear. Navsys sells a product that generates GPS signals by simulation and then you load them into a USRP and play them with Gnuradio. They also sell the receiver software. Here's a review of Matlab toolboxes: http://www.constell.org/Downloads/gpsmatlab.article.pdf Xilinx has an article: http://www.xilinx.com/publications/magazines/dsp_01/xc_pdf/p50-53_dsp-gps.pdf That describes a GPS receiver implemented using SystemGenerator, etc., but I suspect that they're not distributing the source code. There's this paper, too: http://old.gps.aau.dk/downloads/IONGNSS2005_BorreAkos_paper.pdf Here's someone who did it as a project in school: http://cegt201.bradley.edu/projects/proj2008/gps/ He tried to convert the Matlab from Akos, et al., to C++ > > There is also the complex 12h signal in most GPS receivers > PPS, should that be notched out of the PLL so that it will > not react to offsets that have a 12h period ? (obviously > only in stationary > applications.) > > So many things to try, so little time... Indeed... But hey.. Why not start hooking up a USRP or Xilinx Eval board.. Jim From magnus at rubidium.dyndns.org Fri Jan 9 00:14:32 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 09 Jan 2009 01:14:32 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: References: Your message of "Fri, 09 Jan 2009 00:08:49 +0100." <49668781.2070106@rubidium.dyndns.org> <1896.1231457208@critter.freebsd.dk> Message-ID: <496696E8.7010704@rubidium.dyndns.org> Lux, James P skrev: >> -----Original Message----- >> From: time-nuts-bounces at febo.com >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Poul-Henning Kamp >> Sent: Thursday, January 08, 2009 3:27 PM >> To: Discussion of precise time and frequency measurement >> Subject: Re: [time-nuts] GPSDO TC >> >> >> >> And timekeeping lends itself well to experiment with this, >> not the least because getting it wrong doesn't smash anything >> valuable :-) > > But you might show up early or late for dinner, which could have dire consequences. True. I was more expecting that when you get it wrong, GPS satellites starts falling from the sky, and they are pretty expensive things to smash flat into the atmosphere. >> For instance, one thing to think about in the context of >> GPSDO's is that in addition to the PPS signal, we also have >> all the other information. >> >> For intance it would make sense to loosen the PLL a bit when >> satellites enter and leave the solution, because that often >> moves the GPS signal a few nanoseconds abrubtly, which is >> enough to throw most PLLs into thinking you had a phase jump. > > > This brings up an interesting question. A lot of the discussion here is > about taking an off the shelf GPS receiver of one sort or another, and > then putting something around it to "improve" the system. A goodly part > of what's in the "around it" is essentially deconvolving (conceptually) > the peculiarities of the receiver. > > These days, it's not that hard to build the RF section of a GPS receiver, > and one can do the processing in an FPGA and attached CPU. Is there an > "open source" signal processing chain (i.e. to acquire and track the PN > codes, and generate the raw observables, and then to do the timing/nav > solution)? If such a thing exists, or can be created, then you can do a > fancier nav solution that explicitly accounts for all the satellites and > weights them differently as they appear and disappear. I happens to have some VHDL code lying around. However, the digital front-end is not that much magic involved with. The real work is in the tracking-processing, for which I have some partial C code lying around and there is open source code available. If someone gives me a good RF frontend we could fool around some. > Navsys sells a product that generates GPS signals by simulation and then > you load them into a USRP and play them with Gnuradio. They also sell the > receiver software. > Here's a review of Matlab toolboxes: > http://www.constell.org/Downloads/gpsmatlab.article.pdf > > Xilinx has an article: > http://www.xilinx.com/publications/magazines/dsp_01/xc_pdf/p50-53_dsp-gps.pdf > That describes a GPS receiver implemented using SystemGenerator, etc., but I > suspect that they're not distributing the source code. > > There's this paper, too: > http://old.gps.aau.dk/downloads/IONGNSS2005_BorreAkos_paper.pdf > > Here's someone who did it as a project in school: > http://cegt201.bradley.edu/projects/proj2008/gps/ > He tried to convert the Matlab from Akos, et al., to C++ We are a few that has a GNSS Sampler, which is basically a GPS frontend hooked to a USB chip and you do correlation etc in the computer. It is a bit of a challenge to get it to track in real time thought there are those that do that. >> There is also the complex 12h signal in most GPS receivers >> PPS, should that be notched out of the PLL so that it will >> not react to offsets that have a 12h period ? (obviously >> only in stationary >> applications.) >> >> So many things to try, so little time... > > Indeed... > > > But hey.. Why not start hooking up a USRP or Xilinx Eval board.. Let's do that... some day. Cheers, Magnus From gwinn at raytheon.com Fri Jan 9 00:51:50 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Thu, 8 Jan 2009 19:51:50 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <49657762.5060504@rubidium.dyndns.org> Message-ID: Magnus, time-nuts-bounces at febo.com wrote on 01/07/2009 10:47:46 PM: > Joseph, > > >>> Could be a differential TX and RX. I recall that they send a RS422 > > signal. > >> Depending on the speed, RS422 works fine with transformers. > > > > Yes. It would be 10 MHz or 20 MHz, depending on coding. Or 5 MHz, so the > > transitions are at 10 MHz. I don't recall, or never knew. > > RS422 does not imply any encoding as such so it would be 10 MHz but > naturally there is twice that many transitions, but it is the frequency > of the signal you are interested in for this case. I know that RS422 is not the encoding. I cheated, and talked to the relevant engineer. For digital signals (1PPS, various triggers), it's RS422 over 100 ohm twinax (fancy shielded twisted pair). The 10 MHz sinewave is sent over a pair of 50 ohm coax links, with the signals 180 degrees out of phase. This is acheived with a pair of hybrid transformers which convert from one-cable to two-cable and then back to one-cable, where all cables are 50 ohm coax. > >>> I imagine that the shield is grounded at both ends, if only for > >>> safety reasons. > >> That is actually a very unsafe practice, unless there is another > >> much thicker and reliable ground connection between the two domains. > > > > There is a very heavy grounding grid, and such systems almost always > > ground the (outer) shields at every connector. > > Which would imply that if the signal passes through a connector jack or > through a wall, much of the current would be sent back to its EMF source > locally in the room. This does have its merits. Yes, but that isn't the reason. It's really a safety and EMC rationale. > >> But you should never let the screen float in the far end, you should > >> terminate it with a 10M resistor and a sparkgap in parallel to the > >> local ground. > >> > >> The resistor takes care of static electricity and the sparkgap will > >> do lightnings. > > > > I've done such things, but with a 100 ohm resistor (and a safety ground to > > ensure that the voltage doesn't get too large. But this was > a lab lashup. > > The trouble with 100 ohm is that still can be a little low in relation > to ground loop impedances, it still allow some fair current to roll down > the cable. A capacitor in parallel would cut most of the transient > energy straight through and allow for a higher resistive path for the > low frequency energy. The ground grid impedance between any two points is well less than one ohm, so 100 ohms will pretty much abolish all ground loops. I've used 10 ohms in like labs, with success. I'll grant that this would not work with long wires outside. By the way, I also finally talked to one of our most experienced EMI/EMC engineers. He suggested using MIL-STD-461 test CS109, even though CS109 was developed for enclosures. It turns out he was involved in developing CS109 when he worked for the US Navy. Joe From james.p.lux at jpl.nasa.gov Fri Jan 9 00:54:15 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Thu, 8 Jan 2009 16:54:15 -0800 Subject: [time-nuts] GPSDO TC In-Reply-To: <496696E8.7010704@rubidium.dyndns.org> References: Your message of "Fri, 09 Jan 2009 00:08:49 +0100." <49668781.2070106@rubidium.dyndns.org> <1896.1231457208@critter.freebsd.dk> <496696E8.7010704@rubidium.dyndns.org> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Magnus Danielson > Sent: Thursday, January 08, 2009 4:15 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] GPSDO TC > > If someone gives me a good RF frontend we could fool around some. > > Maxim MAX2741 L1 GPS receiver IC http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4323 MAX2741EVKIT is maybe available.. 2745 is another MAX2745EVKIT (not available for purchase) Maxim recommends: MAX2769 Universal GPS receiver but it's one of those "request the data sheet" parts.. Anyway, there's probably something out there. From gwinn at raytheon.com Fri Jan 9 01:11:37 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Thu, 8 Jan 2009 20:11:37 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <7171.1231404449@critter.freebsd.dk> Message-ID: time-nuts-bounces at febo.com wrote on 01/08/2009 03:47:29 AM: > In message 00817C56 at mck.us.ray.com>, Joseph M Gwinn writes: > > > >Was there a big bang? What was the source of the 600 amps? > > They replaced the separation transformer with a UPS, and they > connected the two sides ground together at the UPS. > > Unfortunately the grounding on our secondary side was much better > than the power companys grounding on the primary side, which was the > entire point of having the the transformer in the first place. One assumes that there were too many cooks. > Yes, there were a significant bang and his two-hand wire-cutter was > recategorized from "tool" to "industrial art". He probably needed a stiff drink after that. Joe From die at dieconsulting.com Fri Jan 9 01:38:59 2009 From: die at dieconsulting.com (David I. Emery) Date: Thu, 8 Jan 2009 20:38:59 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: <7217.1231404705@critter.freebsd.dk> References: <49657762.5060504@rubidium.dyndns.org> <7217.1231404705@critter.freebsd.dk> Message-ID: <20090109013859.GA18179@pig.dieconsulting.com> On Thu, Jan 08, 2009 at 08:51:45AM +0000, Poul-Henning Kamp wrote: > In message <49657762.5060504 at rubidium.dyndns.org>, Magnus Danielson writes: > > > >> Was there a big bang? What was the source of the 600 amps? > > > >I think there (with some delay) was some awfull scream of dispare. > >The cost of Ethernet interfaces where much more significant back then. > > The most expensive one we lost was in a UNISYS 2200, where three > microprocessors worked together to limit bandwidth to 100 kB/s. > I belive the sticker prices as $15k. I'm somewhat confused about how this took out Ethernet transceivers or interfaces... from the beginning even vampire tap RG-8 yellow cable Ethernet transceivers were ground isolated from chassis ground of the computer system just exactly to avoid ground loops and back path ground currents. Both power and transmit/receive and control signals are isolated... and usually transformer coupled... and as I remember it rather a substantial voltage difference between shield on the cable and computer system ground had to be tolerated (hundreds of volts at least)... I guess, however, if someone grounded the yellow cable at more than one point enough current could flow on its outer conductor to induce substantial voltage between the shield and the center conductor which could trash the driver/receiver/carrier sense chips or protective clamp diodes ... One was never, of course, supposed to ground the yellow cable at more than one point... -- Dave Emery N1PRE/AE, die at dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." From darrell at shaw.ca Fri Jan 9 05:22:12 2009 From: darrell at shaw.ca (Darrell Robinson) Date: Thu, 8 Jan 2009 21:22:12 -0800 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Message-ID: <001c01c9721a$3a791620$9400a8c0@shaw.ca> If you're simply looking for purity of signal maybe a crystal filter. Intersil application note AN9815 is interesting. Darrell ----- Original Message ----- From: "Richard W. Solomon" To: Sent: Thursday, January 08, 2009 10:11 AM Subject: [time-nuts] 10 MHz Band-Pass Filter Needed > The GPSDO I want to use has an output rich in harmonics. In some > cases that is good, but Murphy rules and in the application I have > today, it is not good. > > I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something > small with SMA connectors would be ideal, but I can live with BNC. > > Anyone have such a beast or know where I can get one ? I checked Mini-Circuits > and choked on the price !! > > Thanks, Dick, W1KSZ > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From kirbybq at bellsouth.net Fri Jan 9 05:33:30 2009 From: kirbybq at bellsouth.net (Brian Kirby) Date: Thu, 08 Jan 2009 23:33:30 -0600 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed In-Reply-To: <001c01c9721a$3a791620$9400a8c0@shaw.ca> References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <001c01c9721a$3a791620$9400a8c0@shaw.ca> Message-ID: <4966E1AA.8030700@bellsouth.net> A quick filter would be a series resonance circuit. My notes show that on a circuit that was 10 Mhz and terminated into 50 ohms load, I used a 10uH choke and a 22 pF cap. Both of these items were off the shelf , the cap was a silver mica 5%. Brian KD4FM Darrell Robinson wrote: > If you're simply looking for purity of signal maybe a crystal filter. > > Intersil application note AN9815 is interesting. > > Darrell > > > ----- Original Message ----- > From: "Richard W. Solomon" > To: > Sent: Thursday, January 08, 2009 10:11 AM > Subject: [time-nuts] 10 MHz Band-Pass Filter Needed > > >> The GPSDO I want to use has an output rich in harmonics. In some >> cases that is good, but Murphy rules and in the application I have >> today, it is not good. >> >> I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something >> small with SMA connectors would be ideal, but I can live with BNC. >> >> Anyone have such a beast or know where I can get one ? I checked > Mini-Circuits >> and choked on the price !! >> >> Thanks, Dick, W1KSZ >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From richiem at hughes.net Fri Jan 9 06:00:46 2009 From: richiem at hughes.net (Richard Moore) Date: Thu, 8 Jan 2009 22:00:46 -0800 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: References: Message-ID: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> On Jan 8, 2009, at 2:46 PM, time-nuts-request at febo.com wrote: > Message: 1 > Date: Fri, 09 Jan 2009 10:28:35 +1300 > From: Bruce Griffiths > Subject: Re: [time-nuts] GPSDO TC > To: Discussion of precise time and frequency measurement > > > Richard Moore wrote: >> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: >> >> >>> Message: 6 >>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>> From: Magnus Danielson >>> Subject: Re: [time-nuts] GPSDO time constant >>> To: Tom Van Baak , Discussion of precise >>> time and >>> frequency measurement >>> >>> For ThunderBolt owners it is pretty straightforward to adjust the >>> TC and >>> damping, which is very nice. Use this oppertunity! >>> >> >> So, Magnus (and Tom), what damping factor do you suggest for a TBolt? >> I'm running a verrry long TC now. If 1.2 is not actually critically >> damped, what value would be? Any guesses? BTW, I really like that >> plot of Tom's that tracks the oven and then gets better from the >> GPS... >> >> Dick Moore >> >> > Richard > > As always, the problem is how do you know that the time constant > you are > using is anywhere near optimum? > > > Bruce Well, like many here, I don't actually have the equipment, especially the reference std., to do these MDEV, ADEV and other analyses, so, since I use the GPSDO for a frequency standard and not for UTC, I thought I'd get the expert opinions. Magnus has several times indicated here that a TC laying somewhere in and around 100 to 1000 secs is probably optimum. When I enquired some time back about damping in the TBolt, the consensus seemed to be "leave it at 1.2". I have, but it just seems to me that won't be optimum for a fixed- position, lab-located frequency standard -- at the moment, I'm leaning toward the 0.7to 1.0 area. Tom's recent chart was quite helpful, especially the 1000 sec curve. Now, I hope that Tom or someone else follows up on the suggestion to track performance vs. damping factor. I do understand that the results for any one GPSDO don't *necessarily* translate to other devices, but they don't necessarily don't, either. At least for the TBolts a lot of us are playing with, one good example (like Tom's) may well put mine in a better ballpark than the ballpark the factory wants it to play in, given the factors that you all have described. Thx everyone for the comments. Look forward to the next round! Dick Moore From bruce.griffiths at xtra.co.nz Fri Jan 9 06:07:22 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 19:07:22 +1300 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed In-Reply-To: <001c01c9721a$3a791620$9400a8c0@shaw.ca> References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <001c01c9721a$3a791620$9400a8c0@shaw.ca> Message-ID: <4966E99A.9080303@xtra.co.nz> A crystal filter may not be a good choice for phase stability unless an oven is used. Some of the older frequency standards used crystal filters within an oven to cleanup the output signal. The limited crystal dissipation as may raise the phase noise floor of a low noise OCXO significantly. The implementation shown in AN9815 is particularly poor in this respect. A low Q resonant LC filter using low tempco components will have greater phase stability. Whilst obtaining capacitors with relatively low tempcos is relatively easy, the tempco of most off the shelf inductors is usually unspecified. The significance of the increased phase instability and /or raised phase noise floor depends on the application. If one is multiplying the output to 10GHz then even minor temperature fluctuations will be a concern. Bruce Darrell Robinson wrote: > If you're simply looking for purity of signal maybe a crystal filter. > > Intersil application note AN9815 is interesting. > > Darrell > > > ----- Original Message ----- > From: "Richard W. Solomon" > To: > Sent: Thursday, January 08, 2009 10:11 AM > Subject: [time-nuts] 10 MHz Band-Pass Filter Needed > > > >> The GPSDO I want to use has an output rich in harmonics. In some >> cases that is good, but Murphy rules and in the application I have >> today, it is not good. >> >> I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something >> small with SMA connectors would be ideal, but I can live with BNC. >> >> Anyone have such a beast or know where I can get one ? I checked >> > Mini-Circuits > >> and choked on the price !! >> >> Thanks, Dick, W1KSZ >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to >> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >> and follow the instructions there. >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From bruce.griffiths at xtra.co.nz Fri Jan 9 06:18:57 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 19:18:57 +1300 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> Message-ID: <4966EC51.5050300@xtra.co.nz> Richard Moore wrote: > On Jan 8, 2009, at 2:46 PM, time-nuts-request at febo.com wrote: > > >> Message: 1 >> Date: Fri, 09 Jan 2009 10:28:35 +1300 >> From: Bruce Griffiths >> Subject: Re: [time-nuts] GPSDO TC >> To: Discussion of precise time and frequency measurement >> >> >> Richard Moore wrote: >> >>> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: >>> >>> >>> >>>> Message: 6 >>>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>>> From: Magnus Danielson >>>> Subject: Re: [time-nuts] GPSDO time constant >>>> To: Tom Van Baak , Discussion of precise >>>> time and >>>> frequency measurement >>>> >>>> For ThunderBolt owners it is pretty straightforward to adjust the >>>> TC and >>>> damping, which is very nice. Use this oppertunity! >>>> >>>> >>> So, Magnus (and Tom), what damping factor do you suggest for a TBolt? >>> I'm running a verrry long TC now. If 1.2 is not actually critically >>> damped, what value would be? Any guesses? BTW, I really like that >>> plot of Tom's that tracks the oven and then gets better from the >>> GPS... >>> >>> Dick Moore >>> >>> >>> >> Richard >> >> As always, the problem is how do you know that the time constant >> you are >> using is anywhere near optimum? >> >> >> Bruce >> > > Well, like many here, I don't actually have the equipment, especially > the reference std., to do these MDEV, ADEV and other analyses, so, > since I use the GPSDO for a frequency standard and not for UTC, I > thought I'd get the expert opinions. Magnus has several times > indicated here that a TC laying somewhere in and around 100 to 1000 > secs is probably optimum. When I enquired some time back about > damping in the TBolt, the consensus seemed to be "leave it at 1.2". I > have, but it just seems to me that won't be optimum for a fixed- > position, lab-located frequency standard -- at the moment, I'm > leaning toward the 0.7to 1.0 area. > > Why, since it has been demonstrated that a damping factor of 1.2 is better than one of 0.7 for a particular Thunderbolt this would tend to indicate that adjusting the damping without good justification is somewhat foolhardy. If in fact the phase noise characteristics of your OCXO are similar toi the one in the Thunderbolt that Tom measured this would degrade the performance. With no way of measuring the effect of such adjustments you are just hoping that your particular Thunderbolt is similar to the one Tom measured. Thats not engineering its more like witchcraft. > Tom's recent chart was quite helpful, especially the 1000 sec curve. > Now, I hope that Tom or someone else follows up on the suggestion to > track performance vs. damping factor. I do understand that the > results for any one GPSDO don't *necessarily* translate to other > devices, but they don't necessarily don't, either. At least for the > TBolts a lot of us are playing with, one good example (like Tom's) > may well put mine in a better ballpark than the ballpark the factory > wants it to play in, given the factors that you all have described. > Thx everyone for the comments. Look forward to the next round! > > Dick Moore > The probability that you will improve the performance significantly without a means of measuring the resultant performance is fairly low. You will never know if either an improvement or a degradation in performance has occurred. The one saving grace being that the factory defaults can always be restored. Bruce From mac at checa.us Fri Jan 9 06:34:28 2009 From: mac at checa.us (Miguel Checa) Date: Fri, 09 Jan 2009 01:34:28 -0500 Subject: [time-nuts] 20Hz p-p / 24 hours with a Mini-T In-Reply-To: References: Message-ID: <4966EFF4.4000300@checa.us> Hi group! I need some opinions, counsel, help, whatever you can send my way: I need to maintain the Mini-T within 20 Hz p-p in a 24 h period. I use T=450 and all is well until the thing starts to lose satellites one by one and goes into holdover and after a while, the VCO voltage jumps to the start value and with it the frequency (up to -150Hz). The antenna is not in a good place and it can't be moved, but if I restart the Mini-T, all satellites that were grayed out come alive and strong. Any clues? Thanks, Miguel W4/LU9AXC From sar10538 at gmail.com Fri Jan 9 06:44:37 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Fri, 9 Jan 2009 19:44:37 +1300 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed In-Reply-To: <4966E99A.9080303@xtra.co.nz> References: <12244457.1231438270683.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <001c01c9721a$3a791620$9400a8c0@shaw.ca> <4966E99A.9080303@xtra.co.nz> Message-ID: <1231b6a80901082244u79ea8af7j1b17bb1a9befeda1@mail.gmail.com> 2009/1/9 Bruce Griffiths : > A crystal filter may not be a good choice for phase stability unless an > oven is used. > Some of the older frequency standards used crystal filters within an > oven to cleanup the output signal. There is the other issue of xtal jumps occuring randomly (?) which could cause rapid phase changes. 73, Steve > The limited crystal dissipation as may raise the phase noise floor of a > low noise OCXO significantly. > The implementation shown in AN9815 is particularly poor in this respect. > > A low Q resonant LC filter using low tempco components will have greater > phase stability. > Whilst obtaining capacitors with relatively low tempcos is relatively > easy, the tempco of most off the shelf inductors is usually unspecified. > > The significance of the increased phase instability and /or raised phase > noise floor depends on the application. > If one is multiplying the output to 10GHz then even minor temperature > fluctuations will be a concern. > > Bruce > > Darrell Robinson wrote: >> If you're simply looking for purity of signal maybe a crystal filter. >> >> Intersil application note AN9815 is interesting. >> >> Darrell >> >> >> ----- Original Message ----- >> From: "Richard W. Solomon" >> To: >> Sent: Thursday, January 08, 2009 10:11 AM >> Subject: [time-nuts] 10 MHz Band-Pass Filter Needed >> >> >> >>> The GPSDO I want to use has an output rich in harmonics. In some >>> cases that is good, but Murphy rules and in the application I have >>> today, it is not good. >>> >>> I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something >>> small with SMA connectors would be ideal, but I can live with BNC. >>> >>> Anyone have such a beast or know where I can get one ? I checked >>> >> Mini-Circuits >> >>> and choked on the price !! >>> >>> Thanks, Dick, W1KSZ >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to >>> >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> >>> and follow the instructions there. >>> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From bruce.griffiths at xtra.co.nz Fri Jan 9 06:51:28 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 19:51:28 +1300 Subject: [time-nuts] 20Hz p-p / 24 hours with a Mini-T In-Reply-To: <4966EFF4.4000300@checa.us> References: <4966EFF4.4000300@checa.us> Message-ID: <4966F3F0.8090609@xtra.co.nz> Miguel Checa wrote: > Hi group! > > I need some opinions, counsel, help, whatever you can send my way: > > I need to maintain the Mini-T within 20 Hz p-p in a 24 h period. I use > T=450 and all is well until the thing starts to lose satellites one by > one and goes into holdover and after a while, the VCO voltage jumps to > the start value and with it the frequency (up to -150Hz). > > The antenna is not in a good place and it can't be moved, but if I > restart the Mini-T, all satellites that were grayed out come alive and > strong. Any clues? > > Thanks, > > Miguel > W4/LU9AXC > > > Miguel 20Hz is a fairly wide tolerance that one could easily maintain with a good OCXO with periodic manual frequency adjustments of perhaps once per year. If the Mini-T never sees a sufficient number of SVs uninterrupted for somewhat longer than 450 sec then you need to reduce T to a value such that sufficient SVs are seen for longer than T. Do you have anyu idea of sky coverage and maximum observed SV track lenghts? Bruce From sar10538 at gmail.com Fri Jan 9 08:10:32 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Fri, 9 Jan 2009 21:10:32 +1300 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: <4966EC51.5050300@xtra.co.nz> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> Message-ID: <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> Maybe this should be the subject of a separate thread but to enable ordinary time-nuts to be able to test their ocxo's and gpsdo's for phase stability at "home", what would it take as a minimum to be able to perform something like an ADEV test? This would enable us (the other half) to see the results of our experiments and tuning of the gear we have otherwise it is a lot like working blind. I appreciate that what is normally used is a counter which can continually timestamp a dut as opposed to a gated counter but what would be the cheapest way we could achieve this sort of setup? Thanks and 73, Steve 2009/1/9 Bruce Griffiths : > Richard Moore wrote: >> On Jan 8, 2009, at 2:46 PM, time-nuts-request at febo.com wrote: >> >> >>> Message: 1 >>> Date: Fri, 09 Jan 2009 10:28:35 +1300 >>> From: Bruce Griffiths >>> Subject: Re: [time-nuts] GPSDO TC >>> To: Discussion of precise time and frequency measurement >>> >>> >>> Richard Moore wrote: >>> >>>> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote: >>>> >>>> >>>> >>>>> Message: 6 >>>>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>>>> From: Magnus Danielson >>>>> Subject: Re: [time-nuts] GPSDO time constant >>>>> To: Tom Van Baak , Discussion of precise >>>>> time and >>>>> frequency measurement >>>>> >>>>> For ThunderBolt owners it is pretty straightforward to adjust the >>>>> TC and >>>>> damping, which is very nice. Use this oppertunity! >>>>> >>>>> >>>> So, Magnus (and Tom), what damping factor do you suggest for a TBolt? >>>> I'm running a verrry long TC now. If 1.2 is not actually critically >>>> damped, what value would be? Any guesses? BTW, I really like that >>>> plot of Tom's that tracks the oven and then gets better from the >>>> GPS... >>>> >>>> Dick Moore >>>> >>>> >>>> >>> Richard >>> >>> As always, the problem is how do you know that the time constant >>> you are >>> using is anywhere near optimum? >>> >>> >>> Bruce >>> >> >> Well, like many here, I don't actually have the equipment, especially >> the reference std., to do these MDEV, ADEV and other analyses, so, >> since I use the GPSDO for a frequency standard and not for UTC, I >> thought I'd get the expert opinions. Magnus has several times >> indicated here that a TC laying somewhere in and around 100 to 1000 >> secs is probably optimum. When I enquired some time back about >> damping in the TBolt, the consensus seemed to be "leave it at 1.2". I >> have, but it just seems to me that won't be optimum for a fixed- >> position, lab-located frequency standard -- at the moment, I'm >> leaning toward the 0.7to 1.0 area. >> >> > Why, since it has been demonstrated that a damping factor of 1.2 is > better than one of 0.7 for a particular Thunderbolt this would tend to > indicate that adjusting the damping without good justification is > somewhat foolhardy. > If in fact the phase noise characteristics of your OCXO are similar toi > the one in the Thunderbolt that Tom measured this would degrade the > performance. > > With no way of measuring the effect of such adjustments you are just > hoping that your particular Thunderbolt is similar to the one Tom measured. > Thats not engineering its more like witchcraft. > >> Tom's recent chart was quite helpful, especially the 1000 sec curve. >> Now, I hope that Tom or someone else follows up on the suggestion to >> track performance vs. damping factor. I do understand that the >> results for any one GPSDO don't *necessarily* translate to other >> devices, but they don't necessarily don't, either. At least for the >> TBolts a lot of us are playing with, one good example (like Tom's) >> may well put mine in a better ballpark than the ballpark the factory >> wants it to play in, given the factors that you all have described. >> Thx everyone for the comments. Look forward to the next round! >> >> Dick Moore >> > The probability that you will improve the performance significantly > without a means of measuring the resultant performance is fairly low. > You will never know if either an improvement or a degradation in > performance has occurred. > The one saving grace being that the factory defaults can always be restored. > > Bruce > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From Paul.Reeves at uk.thalesgroup.com Fri Jan 9 08:19:39 2009 From: Paul.Reeves at uk.thalesgroup.com (Reeves Paul) Date: Fri, 9 Jan 2009 08:19:39 -0000 Subject: [time-nuts] 10 MHz Band-Pass Filter Needed Message-ID: <8E8D23D235D70840B6582917DF27898006935BEF@temps153538.tms-ltd.com> Try an old 10MBs Ethernet card - they have a nice packaged filter (contains 2 filters actually, 5 & 7 pole) which tidies up a 10MHz signal. Package is 'YCL 20F001N' but similar ones may exist. Essentially zero cost. Info from the UHF-Satcom group. cheers, Paul G8GJA -----Original Message----- From: Richard W. Solomon [mailto:w1ksz at earthlink.net] Sent: 08 January 2009 18:11 To: time-nuts at febo.com Subject: [time-nuts] 10 MHz Band-Pass Filter Needed The GPSDO I want to use has an output rich in harmonics. In some cases that is good, but Murphy rules and in the application I have today, it is not good. I need a 10 MHz Band-Pass Filter, Bandwidth is not critical, something small with SMA connectors would be ideal, but I can live with BNC. Anyone have such a beast or know where I can get one ? I checked Mini-Circuits and choked on the price !! Thanks, Dick, W1KSZ _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. This email, including any attachment, is a confidential communication intended solely for the use of the individual or entity to whom it is addressed. It contains information which is private and may be proprietary or covered by legal professional privilege. If you have received this email in error, please notify the sender upon receipt, and immediately delete it from your system. Anything contained in this email that is not connected with the businesses of this company is neither endorsed by nor is the liability of this company. Whilst we have taken reasonable precautions to ensure that any attachment to this email has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. From magnus at rubidium.dyndns.org Fri Jan 9 09:27:05 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 09 Jan 2009 10:27:05 +0100 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> Message-ID: <49671869.2030903@rubidium.dyndns.org> Dick, > Well, like many here, I don't actually have the equipment, especially > the reference std., to do these MDEV, ADEV and other analyses, so, > since I use the GPSDO for a frequency standard and not for UTC, I > thought I'd get the expert opinions. Magnus has several times > indicated here that a TC laying somewhere in and around 100 to 1000 > secs is probably optimum. I think you have misinterpreted my postings. I never claimed it was optimum, or at least never intended to. I think 100 secs is good for doing additional experiments with damping parameters. It would be interesting to see just how low the bulb may go. This only since it is obvious that it makes such a clear difference at 100 secs. It's a choice out of measurement and interpretation practicality, not optimum from a use perspective. If you consider my postings you would see that I rather promote the concept of adjusting the time constant dynamically to situations rather than say 1234.5678 seconds is the optimum. Cheers, Magnus From david.partridge at dsl.pipex.com Fri Jan 9 09:29:33 2009 From: david.partridge at dsl.pipex.com (David C. Partridge) Date: Fri, 9 Jan 2009 09:29:33 -0000 Subject: [time-nuts] GPSDO TC In-Reply-To: References: Your message of "Fri, 09 Jan 2009 00:08:49 +0100."<49668781.2070106@rubidium.dyndns.org><1896.1231457208@critter.freebsd.dk> Message-ID: >But you might show up early or late for dinner, which could have dire consequences. I don't think my wife would notice if I arrived a few hundred pico-seconds earlier or later!!! Dave From sar10538 at gmail.com Fri Jan 9 09:48:39 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Fri, 9 Jan 2009 22:48:39 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: References: <49668781.2070106@rubidium.dyndns.org> <1896.1231457208@critter.freebsd.dk> Message-ID: <1231b6a80901090148j393aed52n3114f41ce9027446@mail.gmail.com> 2009/1/9 David C. Partridge : > >But you might show up early or late for dinner, which could have dire > consequences. > > I don't think my wife would notice if I arrived a few hundred pico-seconds > earlier or later!!! Wow! Your a lucky one! -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From bruce.griffiths at xtra.co.nz Fri Jan 9 10:02:00 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 23:02:00 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> Message-ID: <49672098.3000303@xtra.co.nz> Steve If we take TvB's measurements on a Thunderbolt as some guide as to what to expect: http://www.leapsecond.com/pages/tbolt-tc/ Then to make meaningful measurements on a Thunderbolt for example one needs: 1) An independent frequency standard with an MDEV better than 1E-12 or so for 1 s Maybe this should be the subject of a separate thread but to enable > ordinary time-nuts to be able to test their ocxo's and gpsdo's for > phase stability at "home", what would it take as a minimum to be able > to perform something like an ADEV test? This would enable us (the > other half) to see the results of our experiments and tuning of the > gear we have otherwise it is a lot like working blind. I appreciate > that what is normally used is a counter which can continually > timestamp a dut as opposed to a gated counter but what would be the > cheapest way we could achieve this sort of setup? > > Thanks and 73, Steve > From bruce.griffiths at xtra.co.nz Fri Jan 9 10:24:06 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 09 Jan 2009 23:24:06 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <49672098.3000303@xtra.co.nz> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> Message-ID: <496725C6.4000307@xtra.co.nz> Addendum: Timestamping using a conventioanl gated counter is easily accomplished using Greenhall's picket fence technique: http://horology.jpl.nasa.gov/papers/picket_uffc.pdf The Acam TDC ICs (http://www.acam.de) have a resolution of a few tens of ps and a range of up to 200ms or so depending on the chip. These can easily be interfaced to most micros. Bruce Griffiths wrote: > Steve > > If we take TvB's measurements on a Thunderbolt as some guide as to what > to expect: > http://www.leapsecond.com/pages/tbolt-tc/ > > Then to make meaningful measurements on a Thunderbolt for example one needs: > > 1) An independent frequency standard with an MDEV better than 1E-12 or > so for 1 s > 2) A means of measuring MDEV with a resolution and internal noise << > 1E-12 1s < Tau < 1000 s > > If one relaxes the Tau range to say 100s < tau < 1000s, then a wider > range of techniques that have adequate resolution are available. > For most GPSDOs the relevant loop time constant will be somewhere within > the (100 - 1000) s range. > > One point often missed when quoting/plotting MDEV, ADEV measures is the > measurement system noise bandwidth. > The ADEV and MDEV measures are, in general, dependent on the measurement > system noise bandwidth. > Different systems with different noise bandwidths measuring the relative > ADEV or MDEV of the same pair of OCXOs will produce different results > for ADEV, MDEV. > > Possible measurement systems: > > 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. > The system can have a well defined noise bandwidth together with > adequate resolution if the phase comparator output drives an ADC with a > resolution of 12 bits or more ( a sigma delta ADC is perhaps the most > suitable). However the frequencies of the 2 sources must match closely > and in the case of digital phase detectors the non linearity at the ends > of the range should be avoided. > > 2) Heterodyne system where a low noise offset oscillator is used to mix > down to a beat frequency in the audio range. > The beat frequency output is low pass filtered and amplified before > driving either: > > A) a sound card the samples from which are processed to derive the > phase of the beat frequency. > > B) A well designed cascaded amplifier limiter low pass filter system > that progressively amplifies the beat frequency signal. The output stage > is a linear comparator and line driver which drives a conventional time > interval counter with a resolution of 100ns or better. Using the beat > frequency output to drive the counter directly results in excessive noise. > > 3) Dual mixer system with an offset oscillator the performance > requirements of which are relaxed somewhat because only the differential > phase shift between the 2 beat frequency outputs is of interest. > > Whilst in principle a high resolution (100ps or better) counter with > interpolator could be employed to measure the phase of the divided down > output of the UUT with respect to the standard, the system noise > bandwidth is large and ill defined unless one resorts to crystal and/or > passive RC or LC filters etc with their attendant phase stability problems. > > Lacking a suitable frequency standard the best you can do is log the > phase and frequency errors of the thunderbolt when the OCXO is free > running and plot the resultant MDEV. > The best value for the loop time constant should be somewhere in the > close to the value of Tau corresponding to the location of the minimum > value of MDEV. > Perhaps TvB can help by making measurements of the free running MDEV of > a Thunderbolt as measured by the Thunderbolt itself to check the > viability of this method of setting the loop TC. > > NOTES: > > 1) Assembling a high resolution timestamping counter with 100ps or so > resolution should be reasonably practical. > > 2) Designing a optimised bandpass slope amplifier limiter cascade is > relatively straightforward. > > 3) Optical or equivalent isolation is critical. Where mixers are used > selecting one which allows the IF ports to be isolated at low > frequencies is best - Minicircuits have several through-hole models that > allow this. > > 4) The real stumbling block is obtaining a suitable reference. > An FTS1200 or an OSA8607 may be suitable, however these are either rare > or expensive. > Some rubidium standards are also suitable. > TvB only appears to have ADEV plots for the LPRO, however since MDEV is > somewhat lower than ADEV an LPRO may well be suitable. > > 5) Using a sound card to timestamp beat frequency zero crossings or an > equivalent technique is the most flexible and reliable provided that a > high resolution sound card is used. > Such a sound card can also be used for phase noise measurements for > offset frequencies in the 20Hz to 20kHz range. > Some care is required to keep mains related spurs sufficiently low. I > have obtained mains related spur levels below 1uV rms by suitably > arranging the 6m input cables for a balanced input PCI sound card. Since > this sound card has a full scale input of 4Vrms the effect of 1uV spurs > is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. > > 6) A relatively low noise offset source can be assembled from a DDS > based system provided that a truncation spur free output frequency is > chosen. > > Bruce > > Steve Rooke wrote: > >> Maybe this should be the subject of a separate thread but to enable >> ordinary time-nuts to be able to test their ocxo's and gpsdo's for >> phase stability at "home", what would it take as a minimum to be able >> to perform something like an ADEV test? This would enable us (the >> other half) to see the results of our experiments and tuning of the >> gear we have otherwise it is a lot like working blind. I appreciate >> that what is normally used is a counter which can continually >> timestamp a dut as opposed to a gated counter but what would be the >> cheapest way we could achieve this sort of setup? >> >> Thanks and 73, Steve >> >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From sar10538 at gmail.com Fri Jan 9 11:18:12 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Sat, 10 Jan 2009 00:18:12 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <496725C6.4000307@xtra.co.nz> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> Message-ID: <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> Bruce, Thanks for the detailed rundown. Looking at the picket-fence method, this looks possible for me but I will have to get hold of the reference standard. I have a Racal-Dana 1992 with IEEE488 but need to get an interface card for the PC end. These are fairly cheap to buy. You spoke about some types of rubidium standards being suitable, would you care to elaborate on that please? Would something like an Efratom FRS be suitable? Generating the picket-fence itself should not be hard as long as care is taken not to introduce noise. Do you have any links to articles on the design for the mixer/zero-crossing/square-wave beat circuit? One question, assuming that I have a 10MHz reference standard and I'm measuring a 10MHz dut, how do I arrange for them to be about 1Hz apart, given that we are measuring for accuracy here? 1HZ different would make the accuracy 1E-7 out anyway, or am I missing something here? So the real thing for the budget-conscious time-nut seems to be the reference standard. The ocxos you spoke about do seem to be on the rare/expensive side and are an order of magnitude or two better than the Option 4E I have in the 1992. 73, Steve 2009/1/9 Bruce Griffiths : > Addendum: > > Timestamping using a conventioanl gated counter is easily accomplished > using Greenhall's picket fence technique: > http://horology.jpl.nasa.gov/papers/picket_uffc.pdf > > The Acam TDC ICs (http://www.acam.de) have a resolution of a few tens > of ps and a range of up to 200ms or so depending on the chip. > These can easily be interfaced to most micros. > > > Bruce Griffiths wrote: >> Steve >> >> If we take TvB's measurements on a Thunderbolt as some guide as to what >> to expect: >> http://www.leapsecond.com/pages/tbolt-tc/ >> >> Then to make meaningful measurements on a Thunderbolt for example one needs: >> >> 1) An independent frequency standard with an MDEV better than 1E-12 or >> so for 1 s > >> 2) A means of measuring MDEV with a resolution and internal noise << >> 1E-12 1s < Tau < 1000 s >> >> If one relaxes the Tau range to say 100s < tau < 1000s, then a wider >> range of techniques that have adequate resolution are available. >> For most GPSDOs the relevant loop time constant will be somewhere within >> the (100 - 1000) s range. >> >> One point often missed when quoting/plotting MDEV, ADEV measures is the >> measurement system noise bandwidth. >> The ADEV and MDEV measures are, in general, dependent on the measurement >> system noise bandwidth. >> Different systems with different noise bandwidths measuring the relative >> ADEV or MDEV of the same pair of OCXOs will produce different results >> for ADEV, MDEV. >> >> Possible measurement systems: >> >> 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. >> The system can have a well defined noise bandwidth together with >> adequate resolution if the phase comparator output drives an ADC with a >> resolution of 12 bits or more ( a sigma delta ADC is perhaps the most >> suitable). However the frequencies of the 2 sources must match closely >> and in the case of digital phase detectors the non linearity at the ends >> of the range should be avoided. >> >> 2) Heterodyne system where a low noise offset oscillator is used to mix >> down to a beat frequency in the audio range. >> The beat frequency output is low pass filtered and amplified before >> driving either: >> >> A) a sound card the samples from which are processed to derive the >> phase of the beat frequency. >> >> B) A well designed cascaded amplifier limiter low pass filter system >> that progressively amplifies the beat frequency signal. The output stage >> is a linear comparator and line driver which drives a conventional time >> interval counter with a resolution of 100ns or better. Using the beat >> frequency output to drive the counter directly results in excessive noise. >> >> 3) Dual mixer system with an offset oscillator the performance >> requirements of which are relaxed somewhat because only the differential >> phase shift between the 2 beat frequency outputs is of interest. >> >> Whilst in principle a high resolution (100ps or better) counter with >> interpolator could be employed to measure the phase of the divided down >> output of the UUT with respect to the standard, the system noise >> bandwidth is large and ill defined unless one resorts to crystal and/or >> passive RC or LC filters etc with their attendant phase stability problems. >> >> Lacking a suitable frequency standard the best you can do is log the >> phase and frequency errors of the thunderbolt when the OCXO is free >> running and plot the resultant MDEV. >> The best value for the loop time constant should be somewhere in the >> close to the value of Tau corresponding to the location of the minimum >> value of MDEV. >> Perhaps TvB can help by making measurements of the free running MDEV of >> a Thunderbolt as measured by the Thunderbolt itself to check the >> viability of this method of setting the loop TC. >> >> NOTES: >> >> 1) Assembling a high resolution timestamping counter with 100ps or so >> resolution should be reasonably practical. >> >> 2) Designing a optimised bandpass slope amplifier limiter cascade is >> relatively straightforward. >> >> 3) Optical or equivalent isolation is critical. Where mixers are used >> selecting one which allows the IF ports to be isolated at low >> frequencies is best - Minicircuits have several through-hole models that >> allow this. >> >> 4) The real stumbling block is obtaining a suitable reference. >> An FTS1200 or an OSA8607 may be suitable, however these are either rare >> or expensive. >> Some rubidium standards are also suitable. >> TvB only appears to have ADEV plots for the LPRO, however since MDEV is >> somewhat lower than ADEV an LPRO may well be suitable. >> >> 5) Using a sound card to timestamp beat frequency zero crossings or an >> equivalent technique is the most flexible and reliable provided that a >> high resolution sound card is used. >> Such a sound card can also be used for phase noise measurements for >> offset frequencies in the 20Hz to 20kHz range. >> Some care is required to keep mains related spurs sufficiently low. I >> have obtained mains related spur levels below 1uV rms by suitably >> arranging the 6m input cables for a balanced input PCI sound card. Since >> this sound card has a full scale input of 4Vrms the effect of 1uV spurs >> is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. >> >> 6) A relatively low noise offset source can be assembled from a DDS >> based system provided that a truncation spur free output frequency is >> chosen. >> >> Bruce >> >> Steve Rooke wrote: >> >>> Maybe this should be the subject of a separate thread but to enable >>> ordinary time-nuts to be able to test their ocxo's and gpsdo's for >>> phase stability at "home", what would it take as a minimum to be able >>> to perform something like an ADEV test? This would enable us (the >>> other half) to see the results of our experiments and tuning of the >>> gear we have otherwise it is a lot like working blind. I appreciate >>> that what is normally used is a counter which can continually >>> timestamp a dut as opposed to a gated counter but what would be the >>> cheapest way we could achieve this sort of setup? >>> >>> Thanks and 73, Steve >>> >>> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From rexa at sonic.net Fri Jan 9 11:37:35 2009 From: rexa at sonic.net (Rex) Date: Fri, 09 Jan 2009 03:37:35 -0800 Subject: [time-nuts] Sound cards Message-ID: <496736FF.90402@sonic.net> In the uber-thread "Sub Pico Second Phase logger", this exchange took place on 12/16: Bruce Griffiths wrote: > > Joseph M Gwinn wrote: >> >> time-nuts-bounces at febo.com wrote on 12/15/2008 06:42:59 PM: >>> >>> I've also looked at the specs for several other high end sound cards. >>> Quite a few only have single ended inputs. >>> Maybe, I should document the various cards and highlight their >>> shortcomings etc for this application. >>> >> That would be very useful. >> > I'll start on this shortly. Maybe I lost track and missed something, but I don't think I ever saw more on the subject of specific high-end sound cards that might be useful for nutty measurements. I'd be interested to hear what any of the group has to share about relative merits of current sound cards that can be interfaced for measurements like what was being discussed in that earlier thread. (And some before and since.) From my own point of view, I'd most like to hear about any that are external -- connected by USB or 1394, rather than an internal card. This makes it more portable and easier to move between different PC's. Bruce or anyone, got more to share? From mfeher at eozinc.com Fri Jan 9 13:00:24 2009 From: mfeher at eozinc.com (Mike Feher) Date: Fri, 9 Jan 2009 08:00:24 -0500 Subject: [time-nuts] 20Hz p-p / 24 hours with a Mini-T In-Reply-To: <4966EFF4.4000300@checa.us> References: <4966EFF4.4000300@checa.us> Message-ID: Mike - You may want to mention that this requirement is to be met at 30.5 GHz. Regards - Mike Mike B. Feher, N4FS 89 Arnold Blvd. Howell, NJ, 07731 732-886-5960 -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Miguel Checa Sent: Friday, January 09, 2009 1:34 AM To: time-nuts at febo.com Subject: [time-nuts] 20Hz p-p / 24 hours with a Mini-T Hi group! I need some opinions, counsel, help, whatever you can send my way: I need to maintain the Mini-T within 20 Hz p-p in a 24 h period. I use T=450 and all is well until the thing starts to lose satellites one by one and goes into holdover and after a while, the VCO voltage jumps to the start value and with it the frequency (up to -150Hz). The antenna is not in a good place and it can't be moved, but if I restart the Mini-T, all satellites that were grayed out come alive and strong. Any clues? Thanks, Miguel W4/LU9AXC _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From jra at febo.com Fri Jan 9 13:37:47 2009 From: jra at febo.com (John Ackermann N8UR) Date: Fri, 09 Jan 2009 08:37:47 -0500 Subject: [time-nuts] Sound cards In-Reply-To: <496736FF.90402@sonic.net> References: <496736FF.90402@sonic.net> Message-ID: <4967532B.2070008@febo.com> Rex said the following on 01/09/2009 06:37 AM: > Maybe I lost track and missed something, but I don't think I ever saw > more on the subject of specific high-end sound cards that might be > useful for nutty measurements. > > I'd be interested to hear what any of the group has to share about > relative merits of current sound cards that can be interfaced for > measurements like what was being discussed in that earlier thread. (And > some before and since.) > > From my own point of view, I'd most like to hear about any that are > external -- connected by USB or 1394, rather than an internal card. This > makes it more portable and easier to move between different PC's. [Shameless Plug] One very interesting possibility is the HPSDR (High Performance Software Defined Radio) boards called Ozy and Janus. Together with a passive backplane called Atlas, they provide an extremely high performance ADC/DAC that supports sampling to 192k and output via USB. The system was designed for use as the interface between a PC and an SDR and special attention was paid to low noise and flat frequency response. I am not certain, but I *think* that the inputs are DC coupled. The two boards, assembled and tested, run about $320, with a discount for TAPR members. The backplane is a fairly simple kit (lots of connector pins to solder, but not much complexity) that sells for $28, also with a discount for TAPR members. Bare boards, but not kits, for Ozy and Janus are also available for the adventurous. I'm not aware of anyone using this system for T&F work, but it has some interesting possibilities. [/Shameless Plug] John From tvb at LeapSecond.com Fri Jan 9 14:29:45 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Fri, 9 Jan 2009 06:29:45 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> Message-ID: <323E658EDACD4944806D02246DBE8E39@pc52> > 4) The real stumbling block is obtaining a suitable reference. > An FTS1200 or an OSA8607 may be suitable, however these are either rare > or expensive. > Some rubidium standards are also suitable. Bruce, Note that my Tbolt time constant plots were made using just a 58503B GPSDO as the reference; not something more exotic. /tvb From magnus at rubidium.dyndns.org Fri Jan 9 15:04:26 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 09 Jan 2009 16:04:26 +0100 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <49672098.3000303@xtra.co.nz> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> Message-ID: <4967677A.9090506@rubidium.dyndns.org> Bruce Griffiths skrev: > Steve > > If we take TvB's measurements on a Thunderbolt as some guide as to what > to expect: > http://www.leapsecond.com/pages/tbolt-tc/ > > Then to make meaningful measurements on a Thunderbolt for example one needs: > > 1) An independent frequency standard with an MDEV better than 1E-12 or > so for 1 s > 2) A means of measuring MDEV with a resolution and internal noise << > 1E-12 1s < Tau < 1000 s > > If one relaxes the Tau range to say 100s < tau < 1000s, then a wider > range of techniques that have adequate resolution are available. > For most GPSDOs the relevant loop time constant will be somewhere within > the (100 - 1000) s range. I think it is of interest to measure the 10s - 10 ks range. > One point often missed when quoting/plotting MDEV, ADEV measures is the > measurement system noise bandwidth. > The ADEV and MDEV measures are, in general, dependent on the measurement > system noise bandwidth. > Different systems with different noise bandwidths measuring the relative > ADEV or MDEV of the same pair of OCXOs will produce different results > for ADEV, MDEV. There is another mistake being done regularly is not to compensate for frequency drift. ADEV, MDEV and TDEV measures is insensitive to phase offset and frequency offset, where as drift goes straigh thru, which is even very easy to show by manually insertion of a linear model into the respective formulas. On several occasions I have shown that the linear drift apparent in peoples measurements is where their naive ADEV calculations "floors out" where as a compensated dataset keeps going further down. When using a Rubidium as reference for longer taus, such considerations needs to be done, but it remains purely a post-processing aspect on the TIE data. > Possible measurement systems: > > 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. > The system can have a well defined noise bandwidth together with > adequate resolution if the phase comparator output drives an ADC with a > resolution of 12 bits or more ( a sigma delta ADC is perhaps the most > suitable). However the frequencies of the 2 sources must match closely > and in the case of digital phase detectors the non linearity at the ends > of the range should be avoided. > > 2) Heterodyne system where a low noise offset oscillator is used to mix > down to a beat frequency in the audio range. > The beat frequency output is low pass filtered and amplified before > driving either: > > A) a sound card the samples from which are processed to derive the > phase of the beat frequency. > > B) A well designed cascaded amplifier limiter low pass filter system > that progressively amplifies the beat frequency signal. The output stage > is a linear comparator and line driver which drives a conventional time > interval counter with a resolution of 100ns or better. Using the beat > frequency output to drive the counter directly results in excessive noise. > > 3) Dual mixer system with an offset oscillator the performance > requirements of which are relaxed somewhat because only the differential > phase shift between the 2 beat frequency outputs is of interest. > > Whilst in principle a high resolution (100ps or better) counter with > interpolator could be employed to measure the phase of the divided down > output of the UUT with respect to the standard, the system noise > bandwidth is large and ill defined unless one resorts to crystal and/or > passive RC or LC filters etc with their attendant phase stability problems. > > Lacking a suitable frequency standard the best you can do is log the > phase and frequency errors of the thunderbolt when the OCXO is free > running and plot the resultant MDEV. > The best value for the loop time constant should be somewhere in the > close to the value of Tau corresponding to the location of the minimum > value of MDEV. > Perhaps TvB can help by making measurements of the free running MDEV of > a Thunderbolt as measured by the Thunderbolt itself to check the > viability of this method of setting the loop TC. What I have been pondering over is what story does the time deviations of the ThunderBolt itself says. Just recording that over time and do the ADEV/MDEV dance would be kind of interesting. > NOTES: > > 1) Assembling a high resolution timestamping counter with 100ps or so > resolution should be reasonably practical. > > 2) Designing a optimised bandpass slope amplifier limiter cascade is > relatively straightforward. > > 3) Optical or equivalent isolation is critical. Where mixers are used > selecting one which allows the IF ports to be isolated at low > frequencies is best - Minicircuits have several through-hole models that > allow this. I migth add that it may not be apparent from their datasheets. I have Minicircuits mixers which is not documented to be isolated, but when looking at them closely you discover that they are isolated and that their foot-pattern is also very nice. Some of them is open on the PCB side so you can actually see exactly how they are wired. > 4) The real stumbling block is obtaining a suitable reference. > An FTS1200 or an OSA8607 may be suitable, however these are either rare > or expensive. > Some rubidium standards are also suitable. > TvB only appears to have ADEV plots for the LPRO, however since MDEV is > somewhat lower than ADEV an LPRO may well be suitable. > > 5) Using a sound card to timestamp beat frequency zero crossings or an > equivalent technique is the most flexible and reliable provided that a > high resolution sound card is used. > Such a sound card can also be used for phase noise measurements for > offset frequencies in the 20Hz to 20kHz range. Another thing to recall is that there exist sound cards with more than two channels, allowing for 3 or 4 channels to be sampled simultaneously, allowing for a fairly cheap three-corner hat solution among other things. FFT based cross-correlation techniques can be swooped up with a few ten lines of wrapping code around FFT libraries such as FFTW for arbitrary FFT lengths of choice. > Some care is required to keep mains related spurs sufficiently low. I > have obtained mains related spur levels below 1uV rms by suitably > arranging the 6m input cables for a balanced input PCI sound card. Since > this sound card has a full scale input of 4Vrms the effect of 1uV spurs > is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. It could be added that soundcards having balanced signal input is used and should be an assumed level. > 6) A relatively low noise offset source can be assembled from a DDS > based system provided that a truncation spur free output frequency is > chosen. Another choice for smaller offsets is a standard OCXO. Mixing the output signal with an external frequency reference (if not being one of the measured signals) allow for separate locking. Actually, any input could be used as frequency reference, but if a separate is wanted, it is just "one more of the same". The locking loop would be the only actual processing that needs to be done in real time, and it is a fairly low-intensive processing. Cheers, Magnus From wd6cmu at earthlink.net Fri Jan 9 16:31:34 2009 From: wd6cmu at earthlink.net (Eric Williams) Date: Fri, 09 Jan 2009 08:31:34 -0800 Subject: [time-nuts] Sound cards In-Reply-To: <496736FF.90402@sonic.net> References: <496736FF.90402@sonic.net> Message-ID: <49677BE6.4050302@earthlink.net> I've been using a Edirol FA-66, a firewire box with two balanced inputs plus four more unbalanced. I think it can handle 192ks/24bit on 4 channels. A lot of hams use it for software defined radios, but I just know it has better sound, especially the lows, for playing MP3s compared to most sound cards and iPods. Rex wrote: > I'd be interested to hear what any of the group has to share about > relative merits of current sound cards that can be interfaced for > measurements like what was being discussed in that earlier thread. (And > some before and since.) > > From my own point of view, I'd most like to hear about any that are > external -- connected by USB or 1394, rather than an internal card. This > makes it more portable and easier to move between different PC's. > From EWKehren at aol.com Fri Jan 9 17:52:16 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Fri, 9 Jan 2009 12:52:16 EST Subject: [time-nuts] PCM61P Message-ID: Does any one know where I can buy two PCM61P or AD1861? Thank you. Bert Kehren WB5MZJ **************New year...new news. Be the first to know what is making headlines. (http://www.aol.com/?ncid=emlcntaolcom00000026) From warrensjmail-one at yahoo.com Fri Jan 9 20:04:12 2009 From: warrensjmail-one at yahoo.com (WarrenS) Date: Fri, 9 Jan 2009 12:04:12 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net><4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com><49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> Message-ID: <00a801c97295$715c7cb0$6401a8c0@WSOffice> >> What would it take as a minimum for ordinary time-nuts to be able >> to perform an ADEV test on their ocxo's and gpsdo's for phase stability at "home", I have noticed that Given enough expertise, anything can be made more complicated than need be. For doing noise testing, there is an option to an expensive osc reference, that has been pointed out many times before. Its advantages is, that unlike other reference standards this one does not have a limit in how low it can measure, and most time-nuts seem to already one or more laying around. The alternative is to just use another one of the same things you are testing (or ANY thing better). When comparing two independent noise sources, you get an answer that is the RMS sum of the two. That is the answer will be up to 1.414 times the noise of the worse one. It's not too hard to find which is the worse one if you need to with a few more test. There are also some simple analog alternatives for measuring Phase noise that do not need high resolution Digital TIC, time stamp etc. and can give higher resolution results. I use a XOR phase detector, an analog filter and a radio shack multimeter with PC interface capability. The ADEV, ODEV and MDEV can then be calculated from the text file data using any of the many great downloadable programs that are available . The 2G test with a strip chart record of the EFC can be used as a simple way to measure the control loop Time constant and see how the control loop responses to an Osc step function error. Another interesting and useful effect that can be used if one is careful interrupting the results is the fact that common errors will tend to cancel. If you compare the noise of two different PLL controlled Osc driven by the SAME 1PPS signal, you will see Just the effect of the control loops and Osc and NOT the effect of the 1pps GPS noise itself. Not what you really want to know when matching an OSC's noise to a GPS signal, but it can provide some interesting insights and results about the control loop and Osc. I do acknowledge that there are limitations in any of the above and many ways that it can be done wrong, But it can provide a Simple usable test, and in some cases near state of the art testing, for the beginning time-nut that has not yet collected all the great test equipment that is so often referred to. WarrenS ******************* ----- Original Message ----- From: "Steve Rooke" To: "Discussion of precise time and frequency measurement" Sent: Friday, January 09, 2009 3:18 AM Subject: Re: [time-nuts] ADEV test setup [was GPSDO TC & Damping] > Bruce, > > Thanks for the detailed rundown. Looking at the picket-fence method, > this looks possible for me but I will have to get hold of the > reference standard. I have a Racal-Dana 1992 with IEEE488 but need to > get an interface card for the PC end. These are fairly cheap to buy. > > You spoke about some types of rubidium standards being suitable, would > you care to elaborate on that please? Would something like an Efratom > FRS be suitable? Generating the picket-fence itself should not be > hard as long as care is taken not to introduce noise. Do you have any > links to articles on the design for the > mixer/zero-crossing/square-wave beat circuit? One question, assuming > that I have a 10MHz reference standard and I'm measuring a 10MHz dut, > how do I arrange for them to be about 1Hz apart, given that we are > measuring for accuracy here? 1HZ different would make the accuracy > 1E-7 out anyway, or am I missing something here? > > So the real thing for the budget-conscious time-nut seems to be the > reference standard. The ocxos you spoke about do seem to be on the > rare/expensive side and are an order of magnitude or two better than > the Option 4E I have in the 1992. > > 73, Steve > > 2009/1/9 Bruce Griffiths : >> Addendum: >> >> Timestamping using a conventioanl gated counter is easily accomplished >> using Greenhall's picket fence technique: >> http://horology.jpl.nasa.gov/papers/picket_uffc.pdf >> >> The Acam TDC ICs (http://www.acam.de) have a resolution of a few tens >> of ps and a range of up to 200ms or so depending on the chip. >> These can easily be interfaced to most micros. >> >> >> Bruce Griffiths wrote: >>> Steve >>> >>> If we take TvB's measurements on a Thunderbolt as some guide as to what >>> to expect: >>> http://www.leapsecond.com/pages/tbolt-tc/ >>> >>> Then to make meaningful measurements on a Thunderbolt for example one needs: >>> >>> 1) An independent frequency standard with an MDEV better than 1E-12 or >>> so for 1 s >> >>> 2) A means of measuring MDEV with a resolution and internal noise << >>> 1E-12 1s < Tau < 1000 s >>> >>> If one relaxes the Tau range to say 100s < tau < 1000s, then a wider >>> range of techniques that have adequate resolution are available. >>> For most GPSDOs the relevant loop time constant will be somewhere within >>> the (100 - 1000) s range. >>> >>> One point often missed when quoting/plotting MDEV, ADEV measures is the >>> measurement system noise bandwidth. >>> The ADEV and MDEV measures are, in general, dependent on the measurement >>> system noise bandwidth. >>> Different systems with different noise bandwidths measuring the relative >>> ADEV or MDEV of the same pair of OCXOs will produce different results >>> for ADEV, MDEV. >>> >>> Possible measurement systems: >>> >>> 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. >>> The system can have a well defined noise bandwidth together with >>> adequate resolution if the phase comparator output drives an ADC with a >>> resolution of 12 bits or more ( a sigma delta ADC is perhaps the most >>> suitable). However the frequencies of the 2 sources must match closely >>> and in the case of digital phase detectors the non linearity at the ends >>> of the range should be avoided. >>> >>> 2) Heterodyne system where a low noise offset oscillator is used to mix >>> down to a beat frequency in the audio range. >>> The beat frequency output is low pass filtered and amplified before >>> driving either: >>> >>> A) a sound card the samples from which are processed to derive the >>> phase of the beat frequency. >>> >>> B) A well designed cascaded amplifier limiter low pass filter system >>> that progressively amplifies the beat frequency signal. The output stage >>> is a linear comparator and line driver which drives a conventional time >>> interval counter with a resolution of 100ns or better. Using the beat >>> frequency output to drive the counter directly results in excessive noise. >>> >>> 3) Dual mixer system with an offset oscillator the performance >>> requirements of which are relaxed somewhat because only the differential >>> phase shift between the 2 beat frequency outputs is of interest. >>> >>> Whilst in principle a high resolution (100ps or better) counter with >>> interpolator could be employed to measure the phase of the divided down >>> output of the UUT with respect to the standard, the system noise >>> bandwidth is large and ill defined unless one resorts to crystal and/or >>> passive RC or LC filters etc with their attendant phase stability problems. >>> >>> Lacking a suitable frequency standard the best you can do is log the >>> phase and frequency errors of the thunderbolt when the OCXO is free >>> running and plot the resultant MDEV. >>> The best value for the loop time constant should be somewhere in the >>> close to the value of Tau corresponding to the location of the minimum >>> value of MDEV. >>> Perhaps TvB can help by making measurements of the free running MDEV of >>> a Thunderbolt as measured by the Thunderbolt itself to check the >>> viability of this method of setting the loop TC. >>> >>> NOTES: >>> >>> 1) Assembling a high resolution timestamping counter with 100ps or so >>> resolution should be reasonably practical. >>> >>> 2) Designing a optimised bandpass slope amplifier limiter cascade is >>> relatively straightforward. >>> >>> 3) Optical or equivalent isolation is critical. Where mixers are used >>> selecting one which allows the IF ports to be isolated at low >>> frequencies is best - Minicircuits have several through-hole models that >>> allow this. >>> >>> 4) The real stumbling block is obtaining a suitable reference. >>> An FTS1200 or an OSA8607 may be suitable, however these are either rare >>> or expensive. >>> Some rubidium standards are also suitable. >>> TvB only appears to have ADEV plots for the LPRO, however since MDEV is >>> somewhat lower than ADEV an LPRO may well be suitable. >>> >>> 5) Using a sound card to timestamp beat frequency zero crossings or an >>> equivalent technique is the most flexible and reliable provided that a >>> high resolution sound card is used. >>> Such a sound card can also be used for phase noise measurements for >>> offset frequencies in the 20Hz to 20kHz range. >>> Some care is required to keep mains related spurs sufficiently low. I >>> have obtained mains related spur levels below 1uV rms by suitably >>> arranging the 6m input cables for a balanced input PCI sound card. Since >>> this sound card has a full scale input of 4Vrms the effect of 1uV spurs >>> is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. >>> >>> 6) A relatively low noise offset source can be assembled from a DDS >>> based system provided that a truncation spur free output frequency is >>> chosen. >>> >>> Bruce >>> >>> Steve Rooke wrote: >>> This would enable us (the >>>> other half) to see the results of our experiments and tuning of the >>>> gear we have otherwise it is a lot like working blind. I appreciate >>>> that what is normally used is a counter which can continually >>>> timestamp a dut as opposed to a gated counter but what would be the >>>> cheapest way we could achieve this sort of setup? >>>> >>>> Thanks and 73, Steve >>>> >>>> >>> >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > > > -- > Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW > Omnium finis imminet > > > From SAIDJACK at aol.com Fri Jan 9 20:25:48 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Fri, 9 Jan 2009 15:25:48 EST Subject: [time-nuts] 20Hz p-p / 24 hours with a Mini-T Message-ID: Hi Miguel, mike mentioned that this is for an 30.5GHz application? If it is for the Government Ka-band Terminal application then you may not be able to use Trimble for that. They apparently cannot meet the spec due to crystal jumps on their units. Sorry for the shameless promotion, but we have a product that is qualified to meet that spec. Contact me offline if you are interested. bye, Said In a message dated 1/8/2009 22:35:23 Pacific Standard Time, mac at checa.us writes: Hi group! I need some opinions, counsel, help, whatever you can send my way: I need to maintain the Mini-T within 20 Hz p-p in a 24 h period. I use T=450 and all is well until the thing starts to lose satellites one by one and goes into holdover and after a while, the VCO voltage jumps to the start value and with it the frequency (up to -150Hz). The antenna is not in a good place and it can't be moved, but if I restart the Mini-T, all satellites that were grayed out come alive and strong. Any clues? Thanks, Miguel W4/LU9AXC From bruce.griffiths at xtra.co.nz Fri Jan 9 21:04:10 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 10:04:10 +1300 Subject: [time-nuts] Sound cards In-Reply-To: <49677BE6.4050302@earthlink.net> References: <496736FF.90402@sonic.net> <49677BE6.4050302@earthlink.net> Message-ID: <4967BBCA.1010904@xtra.co.nz> Eric Williams wrote: > I've been using a Edirol FA-66, a firewire box with two balanced inputs > plus four more unbalanced. I think it can handle 192ks/24bit on 4 > channels. A lot of hams use it for software defined radios, but I just > know it has better sound, especially the lows, for playing MP3s compared > to most sound cards and iPods. > > Rex wrote: > >> I'd be interested to hear what any of the group has to share about >> relative merits of current sound cards that can be interfaced for >> measurements like what was being discussed in that earlier thread. (And >> some before and since.) >> >> From my own point of view, I'd most like to hear about any that are >> external -- connected by USB or 1394, rather than an internal card. This >> makes it more portable and easier to move between different PC's. >> >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Like many external Firewire sound boxes it has +48V phantom power available, which can be something of a hazard for this application unless all external preamps etc are designed to survive accidental application of +48V to their outputs. It also has a relatively low maximum input (+4dBu ~1.2Vrms) making it perhaps a little less robust than one with a Bruce From bruce.griffiths at xtra.co.nz Fri Jan 9 21:06:26 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 10:06:26 +1300 Subject: [time-nuts] Sound cards In-Reply-To: <496736FF.90402@sonic.net> References: <496736FF.90402@sonic.net> Message-ID: <4967BC52.5070000@xtra.co.nz> Rex wrote: > In the uber-thread "Sub Pico Second Phase logger", this exchange took > place on 12/16: > > Bruce Griffiths wrote: > > > > Joseph M Gwinn wrote: > >> > >> time-nuts-bounces at febo.com wrote on 12/15/2008 06:42:59 PM: > >>> > >>> I've also looked at the specs for several other high end sound cards. > >>> Quite a few only have single ended inputs. > >>> Maybe, I should document the various cards and highlight their > >>> shortcomings etc for this application. > >>> > >> That would be very useful. > >> > > I'll start on this shortly. > > Maybe I lost track and missed something, but I don't think I ever saw > more on the subject of specific high-end sound cards that might be > useful for nutty measurements. > > I'd be interested to hear what any of the group has to share about > relative merits of current sound cards that can be interfaced for > measurements like what was being discussed in that earlier thread. (And > some before and since.) > > From my own point of view, I'd most like to hear about any that are > external -- connected by USB or 1394, rather than an internal card. This > makes it more portable and easier to move between different PC's. > > Bruce or anyone, got more to share? > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > I did start compiling info on sound cards and boxes that are suitable. However I have yet to find a suitable simple way of presenting it. A spreadsheet doesnt work that well. I'll look at this again. Bruce From jmiles at pop.net Fri Jan 9 21:09:11 2009 From: jmiles at pop.net (John Miles) Date: Fri, 9 Jan 2009 13:09:11 -0800 Subject: [time-nuts] Enrico Rubiola's new book Message-ID: Phase Noise and Frequency Stability in Oscillators: http://www.amazon.com/gp/product/0521886775/ The UPS driver handed it to me 30 seconds ago, and I can already give it a favorable review after opening it to a random page. Exercise 6.2 on page 191: "Hack as many microwave oscillators as you can." This book -- which I can immediately tell isn't long, dry, or unreasonably-expensive -- seems like an effective marriage of math and pragmatics, likely because it's based on the author's JPL tutorials and industry lectures. Looking through it, I'm seeing a lot of PN graphs which are annotated with explanations of corner frequencies, slopes, and comparisons with other sources, which are (IMHO) a great way to understand what to expect from your own measurements. Anyway: the book looks very approachable, relevant, and well-grounded in hardware and processes often discussed on the list. I'm looking forward to spending some more time with it. -- john, KE5FX From bruce.griffiths at xtra.co.nz Fri Jan 9 21:23:43 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 10:23:43 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <00a801c97295$715c7cb0$6401a8c0@WSOffice> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net><4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com><49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> <00a801c97295$715c7cb0$6401a8c0@WSOffice> Message-ID: <4967C05F.8030907@xtra.co.nz> Warren WarrenS wrote: >>> What would it take as a minimum for ordinary time-nuts to be able >>> to perform an ADEV test on their ocxo's and gpsdo's for phase stability at "home", >>> > > I have noticed that Given enough expertise, anything can be made more complicated than need be. > > For doing noise testing, there is an option to an expensive osc reference, that has been pointed out many times before. Its advantages is, that unlike other reference standards this one does not have a limit in how low it can measure, and most time-nuts seem to already one or more laying around. The alternative is to just use another one of the same things you are testing (or ANY thing better). > When comparing two independent noise sources, you get an answer that is the RMS sum of the two. That is the answer will be up to 1.414 times the noise of the worse one. It's not too hard to find which is the worse one if you need to with a few more test. > > The critical requirement is that the 2 standards being compared are statistically independent. Comparing a pair of Thunderbolts GPSDOs with similar time constants and damping will give optimistic results for Tau comparable with or greater than the loop time constant. Its is even better is to use 3 or more similar standards simultaneously logging phase differences between the various pairs (0.5*N(N-1) pairs for N standards). It is then possible to obtain estimates for ADEV, MDEV etc for each standard. > There are also some simple analog alternatives for measuring Phase noise that do not need high resolution Digital TIC, time stamp etc. and can give higher resolution results. I use a XOR phase detector, an analog filter and a radio shack multimeter with PC interface capability. > > Like all digital phase detectors its best to avoid, if possible, the nonlinearity inherent at the ends of the range. > The ADEV, ODEV and MDEV can then be calculated from the text file data using any of the many great downloadable programs that are available . > > The 2G test with a strip chart record of the EFC can be used as a simple way to measure the control loop Time constant and see how the control loop responses to an Osc step function error. > > Another interesting and useful effect that can be used if one is careful interrupting the results is the fact that common errors will tend to cancel. > If you compare the noise of two different PLL controlled Osc driven by the SAME 1PPS signal, you will see Just the effect of the control loops and Osc and NOT the effect of the 1pps GPS noise itself. Not what you really want to know when matching an OSC's noise to a GPS signal, but it can provide some interesting insights and results about the control loop and Osc. > > I do acknowledge that there are limitations in any of the above and many ways that it can be done wrong, But it can provide a Simple usable test, and in some cases near state of the art testing, for the beginning time-nut that has not yet collected all the great test equipment that is so often referred to. > > WarrenS > ******************* > > ----- Original Message ----- > From: "Steve Rooke" > To: "Discussion of precise time and frequency measurement" > Sent: Friday, January 09, 2009 3:18 AM > Subject: Re: [time-nuts] ADEV test setup [was GPSDO TC & Damping] > > > >> Bruce, >> >> Thanks for the detailed rundown. Looking at the picket-fence method, >> this looks possible for me but I will have to get hold of the >> reference standard. I have a Racal-Dana 1992 with IEEE488 but need to >> get an interface card for the PC end. These are fairly cheap to buy. >> >> You spoke about some types of rubidium standards being suitable, would >> you care to elaborate on that please? Would something like an Efratom >> FRS be suitable? Generating the picket-fence itself should not be >> hard as long as care is taken not to introduce noise. Do you have any >> links to articles on the design for the >> mixer/zero-crossing/square-wave beat circuit? One question, assuming >> that I have a 10MHz reference standard and I'm measuring a 10MHz dut, >> how do I arrange for them to be about 1Hz apart, given that we are >> measuring for accuracy here? 1HZ different would make the accuracy >> 1E-7 out anyway, or am I missing something here? >> >> So the real thing for the budget-conscious time-nut seems to be the >> reference standard. The ocxos you spoke about do seem to be on the >> rare/expensive side and are an order of magnitude or two better than >> the Option 4E I have in the 1992. >> >> 73, Steve >> >> 2009/1/9 Bruce Griffiths : >> >>> Addendum: >>> >>> Timestamping using a conventioanl gated counter is easily accomplished >>> using Greenhall's picket fence technique: >>> http://horology.jpl.nasa.gov/papers/picket_uffc.pdf >>> >>> The Acam TDC ICs (http://www.acam.de) have a resolution of a few tens >>> of ps and a range of up to 200ms or so depending on the chip. >>> These can easily be interfaced to most micros. >>> >>> >>> Bruce Griffiths wrote: >>> >>>> Steve >>>> >>>> If we take TvB's measurements on a Thunderbolt as some guide as to what >>>> to expect: >>>> http://www.leapsecond.com/pages/tbolt-tc/ >>>> >>>> Then to make meaningful measurements on a Thunderbolt for example one needs: >>>> >>>> 1) An independent frequency standard with an MDEV better than 1E-12 or >>>> so for 1 s >>> >>>> 2) A means of measuring MDEV with a resolution and internal noise << >>>> 1E-12 1s < Tau < 1000 s >>>> >>>> If one relaxes the Tau range to say 100s < tau < 1000s, then a wider >>>> range of techniques that have adequate resolution are available. >>>> For most GPSDOs the relevant loop time constant will be somewhere within >>>> the (100 - 1000) s range. >>>> >>>> One point often missed when quoting/plotting MDEV, ADEV measures is the >>>> measurement system noise bandwidth. >>>> The ADEV and MDEV measures are, in general, dependent on the measurement >>>> system noise bandwidth. >>>> Different systems with different noise bandwidths measuring the relative >>>> ADEV or MDEV of the same pair of OCXOs will produce different results >>>> for ADEV, MDEV. >>>> >>>> Possible measurement systems: >>>> >>>> 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. >>>> The system can have a well defined noise bandwidth together with >>>> adequate resolution if the phase comparator output drives an ADC with a >>>> resolution of 12 bits or more ( a sigma delta ADC is perhaps the most >>>> suitable). However the frequencies of the 2 sources must match closely >>>> and in the case of digital phase detectors the non linearity at the ends >>>> of the range should be avoided. >>>> >>>> 2) Heterodyne system where a low noise offset oscillator is used to mix >>>> down to a beat frequency in the audio range. >>>> The beat frequency output is low pass filtered and amplified before >>>> driving either: >>>> >>>> A) a sound card the samples from which are processed to derive the >>>> phase of the beat frequency. >>>> >>>> B) A well designed cascaded amplifier limiter low pass filter system >>>> that progressively amplifies the beat frequency signal. The output stage >>>> is a linear comparator and line driver which drives a conventional time >>>> interval counter with a resolution of 100ns or better. Using the beat >>>> frequency output to drive the counter directly results in excessive noise. >>>> >>>> 3) Dual mixer system with an offset oscillator the performance >>>> requirements of which are relaxed somewhat because only the differential >>>> phase shift between the 2 beat frequency outputs is of interest. >>>> >>>> Whilst in principle a high resolution (100ps or better) counter with >>>> interpolator could be employed to measure the phase of the divided down >>>> output of the UUT with respect to the standard, the system noise >>>> bandwidth is large and ill defined unless one resorts to crystal and/or >>>> passive RC or LC filters etc with their attendant phase stability problems. >>>> >>>> Lacking a suitable frequency standard the best you can do is log the >>>> phase and frequency errors of the thunderbolt when the OCXO is free >>>> running and plot the resultant MDEV. >>>> The best value for the loop time constant should be somewhere in the >>>> close to the value of Tau corresponding to the location of the minimum >>>> value of MDEV. >>>> Perhaps TvB can help by making measurements of the free running MDEV of >>>> a Thunderbolt as measured by the Thunderbolt itself to check the >>>> viability of this method of setting the loop TC. >>>> >>>> NOTES: >>>> >>>> 1) Assembling a high resolution timestamping counter with 100ps or so >>>> resolution should be reasonably practical. >>>> >>>> 2) Designing a optimised bandpass slope amplifier limiter cascade is >>>> relatively straightforward. >>>> >>>> 3) Optical or equivalent isolation is critical. Where mixers are used >>>> selecting one which allows the IF ports to be isolated at low >>>> frequencies is best - Minicircuits have several through-hole models that >>>> allow this. >>>> >>>> 4) The real stumbling block is obtaining a suitable reference. >>>> An FTS1200 or an OSA8607 may be suitable, however these are either rare >>>> or expensive. >>>> Some rubidium standards are also suitable. >>>> TvB only appears to have ADEV plots for the LPRO, however since MDEV is >>>> somewhat lower than ADEV an LPRO may well be suitable. >>>> >>>> 5) Using a sound card to timestamp beat frequency zero crossings or an >>>> equivalent technique is the most flexible and reliable provided that a >>>> high resolution sound card is used. >>>> Such a sound card can also be used for phase noise measurements for >>>> offset frequencies in the 20Hz to 20kHz range. >>>> Some care is required to keep mains related spurs sufficiently low. I >>>> have obtained mains related spur levels below 1uV rms by suitably >>>> arranging the 6m input cables for a balanced input PCI sound card. Since >>>> this sound card has a full scale input of 4Vrms the effect of 1uV spurs >>>> is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. >>>> >>>> 6) A relatively low noise offset source can be assembled from a DDS >>>> based system provided that a truncation spur free output frequency is >>>> chosen. >>>> >>>> Bruce >>>> >>>> Steve Rooke wrote: >>>> >>>> > This would enable us (the > >>>>> other half) to see the results of our experiments and tuning of the >>>>> gear we have otherwise it is a lot like working blind. I appreciate >>>>> that what is normally used is a counter which can continually >>>>> timestamp a dut as opposed to a gated counter but what would be the >>>>> cheapest way we could achieve this sort of setup? >>>>> >>>>> Thanks and 73, Steve >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts at febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >>>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> >> >> -- >> Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW >> Omnium finis imminet >> >> >> >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Bruce From bruce.griffiths at xtra.co.nz Fri Jan 9 21:25:59 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 10:25:59 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <323E658EDACD4944806D02246DBE8E39@pc52> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> <323E658EDACD4944806D02246DBE8E39@pc52> Message-ID: <4967C0E7.5080602@xtra.co.nz> Tom Van Baak wrote: >> 4) The real stumbling block is obtaining a suitable reference. >> An FTS1200 or an OSA8607 may be suitable, however these are either rare >> or expensive. >> Some rubidium standards are also suitable. >> > > Bruce, > > Note that my Tbolt time constant plots were made using just a > 58503B GPSDO as the reference; not something more exotic. > > /tvb > > Tom Doesnt that introduce some correlations for larger tau as both the Thunderbolt and the 58503B are both locked to GPS? Bruce From james.p.lux at jpl.nasa.gov Fri Jan 9 21:30:51 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Fri, 9 Jan 2009 13:30:51 -0800 Subject: [time-nuts] Enrico Rubiola's new book In-Reply-To: References: Message-ID: I like how you can get *Used* copies from Amazon for more than twice the brand new price (even from the exact same seller!). Surely some sort of artifact of the used book sellers' pricing algorithms. (or, maybe, you're paying for someone to buy the book new, open it up, scuff the covers a bit, page through it while sipping a Caffe Latte, and then putting into the box) http://www.amazon.com/gp/offer-listing/0521886775/ref=dp_olp_used?ie=UTF8&condition=used Jim > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of John Miles > Sent: Friday, January 09, 2009 1:09 PM > To: time-nuts at febo.com > Subject: [time-nuts] Enrico Rubiola's new book > > Phase Noise and Frequency Stability in Oscillators: > http://www.amazon.com/gp/product/0521886775/ > > From jpawlan at pawlan.com Fri Jan 9 21:32:14 2009 From: jpawlan at pawlan.com (Jeffrey Pawlan) Date: Fri, 9 Jan 2009 13:32:14 -0800 (PST) Subject: [time-nuts] Enrico Rubiola's new book In-Reply-To: References: Message-ID: I had hoped to meet him at the UFFC last Spring but he cancelled at the last moment owing to a family emergency. Take a look at his webpage: http://www.femto-st.fr/~rubiola/ Jeffrey Pawlan WA6KBL sr member IEEE UFFS & MTT From bruce.griffiths at xtra.co.nz Fri Jan 9 21:56:19 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 10:56:19 +1300 Subject: [time-nuts] Sound cards In-Reply-To: <4967532B.2070008@febo.com> References: <496736FF.90402@sonic.net> <4967532B.2070008@febo.com> Message-ID: <4967C803.6020400@xtra.co.nz> John John Ackermann N8UR wrote: > Rex said the following on 01/09/2009 06:37 AM: > > >> Maybe I lost track and missed something, but I don't think I ever saw >> more on the subject of specific high-end sound cards that might be >> useful for nutty measurements. >> >> I'd be interested to hear what any of the group has to share about >> relative merits of current sound cards that can be interfaced for >> measurements like what was being discussed in that earlier thread. (And >> some before and since.) >> >> From my own point of view, I'd most like to hear about any that are >> external -- connected by USB or 1394, rather than an internal card. This >> makes it more portable and easier to move between different PC's. >> > > [Shameless Plug] > > One very interesting possibility is the HPSDR (High Performance Software > Defined Radio) boards called Ozy and Janus. Together with a passive > backplane called Atlas, they provide an extremely high performance > ADC/DAC that supports sampling to 192k and output via USB. The system > was designed for use as the interface between a PC and an SDR and > special attention was paid to low noise and flat frequency response. I > am not certain, but I *think* that the inputs are DC coupled. > > Not according to the circuit schematic. The input coupling is 10uF + 10K with a corresponding low frequency 3dB cutoff of 1.6Hz. Default inputs are single ended, balanced inputs are accessible via a pair of headers. Input full scale is that of the AKM5394 ADC chip (1.7Vrms nominal). There is a small dc offset between the differential inputs to the AKM5394 to eliminate an idle tone related spurious output. > The two boards, assembled and tested, run about $320, with a discount > for TAPR members. The backplane is a fairly simple kit (lots of > connector pins to solder, but not much complexity) that sells for $28, > also with a discount for TAPR members. Bare boards, but not kits, for > Ozy and Janus are also available for the adventurous. > > I'm not aware of anyone using this system for T&F work, but it has some > interesting possibilities. > > [/Shameless Plug] > > John > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Bruce From jmiles at pop.net Fri Jan 9 21:32:32 2009 From: jmiles at pop.net (John Miles) Date: Fri, 9 Jan 2009 13:32:32 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <4967C0E7.5080602@xtra.co.nz> Message-ID: I'd like to see a similar test conducted against a local Cs clock (and/or maser), just to get everything on one graph. -- john, KE5FX > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On > Behalf Of Bruce Griffiths > Sent: Friday, January 09, 2009 1:26 PM > To: Tom Van Baak; Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] ADEV test setup [was GPSDO TC & Damping] > > > Tom Van Baak wrote: > >> 4) The real stumbling block is obtaining a suitable reference. > >> An FTS1200 or an OSA8607 may be suitable, however these are either rare > >> or expensive. > >> Some rubidium standards are also suitable. > >> > > > > Bruce, > > > > Note that my Tbolt time constant plots were made using just a > > 58503B GPSDO as the reference; not something more exotic. > > > > /tvb > > > > > Tom > > Doesnt that introduce some correlations for larger tau as both the > Thunderbolt and the 58503B are both locked to GPS? > > Bruce > > From GandalfG8 at aol.com Fri Jan 9 22:22:52 2009 From: GandalfG8 at aol.com (GandalfG8 at aol.com) Date: Fri, 9 Jan 2009 17:22:52 EST Subject: [time-nuts] Enrico Rubiola's new book Message-ID: In a message dated 09/01/2009 21:09:51 GMT Standard Time, jmiles at pop.net writes: Phase Noise and Frequency Stability in Oscillators: http://www.amazon.com/gp/product/0521886775/ ------- Thanks John for the information, that looks like a very worthwhile investment.. Apologies if what follows is common knowledge but, whilst performing a Google search on the current title, I discovered that this supersedes a 2005 draft version, "The Leeson effect - Phase noise in quasilinear oscillators", copies of which are freely, and legally:-), available online. One link to that is....... _http://arxiv.org/abs/physics/0502143_ (http://arxiv.org/abs/physics/0502143) Another interesting link, and where I found the reference to the earlier work, offers some supplementary material to the current book in the form of seminar texts.... _http://www.femto-st.fr/~rubiola/indexx-oscillator-noise.html_ (http://www.femto-st.fr/~rubiola/indexx-oscillator-noise.html) regards Nigel GM8PZR From bruce.griffiths at xtra.co.nz Fri Jan 9 22:34:16 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 11:34:16 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> Message-ID: <4967D0E8.4060003@xtra.co.nz> Steve The Efratom FRS may be OK, its hard to say without some MDEV measurements. The specifications only give ADEV for 1s, 10s and 100s. One way to find out is to compare 3 of them in a 3 cornered hat arrangement. Bruce Steve Rooke wrote: > Bruce, > > Thanks for the detailed rundown. Looking at the picket-fence method, > this looks possible for me but I will have to get hold of the > reference standard. I have a Racal-Dana 1992 with IEEE488 but need to > get an interface card for the PC end. These are fairly cheap to buy. > > You spoke about some types of rubidium standards being suitable, would > you care to elaborate on that please? Would something like an Efratom > FRS be suitable? Generating the picket-fence itself should not be > hard as long as care is taken not to introduce noise. Do you have any > links to articles on the design for the > mixer/zero-crossing/square-wave beat circuit? One question, assuming > that I have a 10MHz reference standard and I'm measuring a 10MHz dut, > how do I arrange for them to be about 1Hz apart, given that we are > measuring for accuracy here? 1HZ different would make the accuracy > 1E-7 out anyway, or am I missing something here? > > So the real thing for the budget-conscious time-nut seems to be the > reference standard. The ocxos you spoke about do seem to be on the > rare/expensive side and are an order of magnitude or two better than > the Option 4E I have in the 1992. > > 73, Steve > > 2009/1/9 Bruce Griffiths : > >> Addendum: >> >> Timestamping using a conventioanl gated counter is easily accomplished >> using Greenhall's picket fence technique: >> http://horology.jpl.nasa.gov/papers/picket_uffc.pdf >> >> The Acam TDC ICs (http://www.acam.de) have a resolution of a few tens >> of ps and a range of up to 200ms or so depending on the chip. >> These can easily be interfaced to most micros. >> >> >> Bruce Griffiths wrote: >> >>> Steve >>> >>> If we take TvB's measurements on a Thunderbolt as some guide as to what >>> to expect: >>> http://www.leapsecond.com/pages/tbolt-tc/ >>> >>> Then to make meaningful measurements on a Thunderbolt for example one needs: >>> >>> 1) An independent frequency standard with an MDEV better than 1E-12 or >>> so for 1 s >> >>> 2) A means of measuring MDEV with a resolution and internal noise << >>> 1E-12 1s < Tau < 1000 s >>> >>> If one relaxes the Tau range to say 100s < tau < 1000s, then a wider >>> range of techniques that have adequate resolution are available. >>> For most GPSDOs the relevant loop time constant will be somewhere within >>> the (100 - 1000) s range. >>> >>> One point often missed when quoting/plotting MDEV, ADEV measures is the >>> measurement system noise bandwidth. >>> The ADEV and MDEV measures are, in general, dependent on the measurement >>> system noise bandwidth. >>> Different systems with different noise bandwidths measuring the relative >>> ADEV or MDEV of the same pair of OCXOs will produce different results >>> for ADEV, MDEV. >>> >>> Possible measurement systems: >>> >>> 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. >>> The system can have a well defined noise bandwidth together with >>> adequate resolution if the phase comparator output drives an ADC with a >>> resolution of 12 bits or more ( a sigma delta ADC is perhaps the most >>> suitable). However the frequencies of the 2 sources must match closely >>> and in the case of digital phase detectors the non linearity at the ends >>> of the range should be avoided. >>> >>> 2) Heterodyne system where a low noise offset oscillator is used to mix >>> down to a beat frequency in the audio range. >>> The beat frequency output is low pass filtered and amplified before >>> driving either: >>> >>> A) a sound card the samples from which are processed to derive the >>> phase of the beat frequency. >>> >>> B) A well designed cascaded amplifier limiter low pass filter system >>> that progressively amplifies the beat frequency signal. The output stage >>> is a linear comparator and line driver which drives a conventional time >>> interval counter with a resolution of 100ns or better. Using the beat >>> frequency output to drive the counter directly results in excessive noise. >>> >>> 3) Dual mixer system with an offset oscillator the performance >>> requirements of which are relaxed somewhat because only the differential >>> phase shift between the 2 beat frequency outputs is of interest. >>> >>> Whilst in principle a high resolution (100ps or better) counter with >>> interpolator could be employed to measure the phase of the divided down >>> output of the UUT with respect to the standard, the system noise >>> bandwidth is large and ill defined unless one resorts to crystal and/or >>> passive RC or LC filters etc with their attendant phase stability problems. >>> >>> Lacking a suitable frequency standard the best you can do is log the >>> phase and frequency errors of the thunderbolt when the OCXO is free >>> running and plot the resultant MDEV. >>> The best value for the loop time constant should be somewhere in the >>> close to the value of Tau corresponding to the location of the minimum >>> value of MDEV. >>> Perhaps TvB can help by making measurements of the free running MDEV of >>> a Thunderbolt as measured by the Thunderbolt itself to check the >>> viability of this method of setting the loop TC. >>> >>> NOTES: >>> >>> 1) Assembling a high resolution timestamping counter with 100ps or so >>> resolution should be reasonably practical. >>> >>> 2) Designing a optimised bandpass slope amplifier limiter cascade is >>> relatively straightforward. >>> >>> 3) Optical or equivalent isolation is critical. Where mixers are used >>> selecting one which allows the IF ports to be isolated at low >>> frequencies is best - Minicircuits have several through-hole models that >>> allow this. >>> >>> 4) The real stumbling block is obtaining a suitable reference. >>> An FTS1200 or an OSA8607 may be suitable, however these are either rare >>> or expensive. >>> Some rubidium standards are also suitable. >>> TvB only appears to have ADEV plots for the LPRO, however since MDEV is >>> somewhat lower than ADEV an LPRO may well be suitable. >>> >>> 5) Using a sound card to timestamp beat frequency zero crossings or an >>> equivalent technique is the most flexible and reliable provided that a >>> high resolution sound card is used. >>> Such a sound card can also be used for phase noise measurements for >>> offset frequencies in the 20Hz to 20kHz range. >>> Some care is required to keep mains related spurs sufficiently low. I >>> have obtained mains related spur levels below 1uV rms by suitably >>> arranging the 6m input cables for a balanced input PCI sound card. Since >>> this sound card has a full scale input of 4Vrms the effect of 1uV spurs >>> is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. >>> >>> 6) A relatively low noise offset source can be assembled from a DDS >>> based system provided that a truncation spur free output frequency is >>> chosen. >>> >>> Bruce >>> >>> > From jsrobbins at earthlink.net Fri Jan 9 22:38:13 2009 From: jsrobbins at earthlink.net (James Robbins) Date: Fri, 9 Jan 2009 17:38:13 -0500 Subject: [time-nuts] Z3805A Message-ID: Does anyone have any links to any materials on the Z3805A receiver, especially as to the RS422 pinouts? I'm having trouble getting the receiver to talk with a Sealevel RS232 to USB converter (which works fine with the Z3801A). Thanks much. Jim Robbins, N1JR From warrensjmail-one at yahoo.com Sat Jan 10 01:02:48 2009 From: warrensjmail-one at yahoo.com (WarrenS) Date: Fri, 9 Jan 2009 17:02:48 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net><4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com><49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com><00a801c97295$715c7cb0$6401a8c0@WSOffice> <4967C05F.8030907@xtra.co.nz> Message-ID: <017001c972bf$27d99260$6401a8c0@WSOffice> >Bruce said: > The critical requirement is that the 2 standards being compared are statistically independent. > Comparing a pair of Thunderbolts GPSDOs with similar time constants and > damping will give optimistic results for Tau comparable with or greater than the loop time constant. > Its is even better is to use 3 or more similar standards simultaneously > logging phase differences between the various pairs (0.5*N(N-1) pairs for N standards). > It is then possible to obtain estimates for ADEV, MDEV etc for each standard. The optimistic results at and above the loop time constant, that results even when 3 or more units are used, is because the noise is then mostly due to the GPS signal itself and NOT the local oscillators in the GPSDO. In effect you are then using the same 1PPS signal into each unit, and any common noise on the GPS 1PPS signal will cancel and not be seen. So I think what Bruce is saying is that you can not (or is it should not?) use the GPS signal to measure the GPS's noise. But the point is, if you want to compare your GPSDO with different settings, or compare it to another OCXO, It can be done this way, if you do not have a better ref to use. You could then add the noise of the GPS nose above the control loop time to your optimistic results if you want true results at high Tau values. Also note that having the GPS noise cancle is not necessary a bad thing, It can be a good thing especially if the GPS noise is not what it is that you want to measure. > Like all digital phase detectors its best to avoid, if possible, the nonlinearity inherent at the ends of the range. Using a phase detector near its end point (or at its crossover point if there is any deadband) is something that needs to be avoided. The two basic standard ways to insure that just the center of the phase detector's range is use: 1) Divide the signals down just enough before sending them to the phase detector so that the end points is not an issue. This works when both signals are from devices that are locked to a common signal such as the GPS. 2) When one of signals is from a non locked source such as a OCXO whose phase can drift any amount overtime, One of ways to limit phase detector issues, and use just the very accurate zero phase point, is to use the Phase detector's output to lock the OCXO in a fast control loop and then by knowing the gain of the EFC input, the filtered EFC voltage can be use as freq drift information to find the ADEV's. WarrenS *************: >>> What would it take as a minimum for ordinary time-nuts to be able >>> to perform an ADEV test on their ocxo's and gpsdo's for phase stability at "home", >Warren wrote: >> I have noticed that Given enough expertise, anything can be made more complicated than need be. >> >> For doing noise testing, there is an option to an expensive osc reference, >> that has been pointed out many times before. Its advantages is, that unlike other reference >> standards this one does not have a limit in how low it can measure, and most time-nuts seem >> to already one or more laying around. >> The alternative is to just use another one of the same things you are testing (or ANY thing better). >> When comparing two independent noise sources, you get an answer that is the RMS sum of the two. >> That is the answer will be up to 1.414 times the noise of the worse one. It's not too hard to find >> which is the worse one if you need to with a few more test. >> >> > The critical requirement is that the 2 standards being compared are statistically independent. > Comparing a pair of Thunderbolts GPSDOs with similar time constants and > damping will give optimistic results for Tau comparable with or greater than the loop time constant. > Its is even better is to use 3 or more similar standards simultaneously > logging phase differences between the various pairs (0.5*N(N-1) pairs for N standards). > It is then possible to obtain estimates for ADEV, MDEV etc for each standard. >> There are also some simple analog alternatives for measuring Phase noise that do not need high >> resolution Digital TIC, time stamp etc. and can give higher resolution results. >> I use a XOR phase detector, an analog filter and a radio shack multimeter with PC interface capability. > Like all digital phase detectors its best to avoid, if possible, the nonlinearity inherent at the ends of the range. > >> The ADEV, ODEV and MDEV can then be calculated from the text file data using any of the >> many great downloadable programs that are available . >> >> The 2G test with a strip chart record of the EFC can be used as a simple way to measure >> the control loop Time constant and see how the control loop responses to an Osc step function error. >> >> Another interesting and useful effect that can be used if one is careful interrupting the results is the >> fact that common errors will tend to cancel. >> If you compare the noise of two different PLL controlled Osc driven by the SAME 1PPS signal, >> you will see Just the effect of the control loops and Osc and NOT the effect of the 1pps GPS noise >> itself. Not what you really want to know when matching an OSC's noise to a GPS signal, but it can >> provide some interesting insights and results about the control loop and Osc. >> >> I do acknowledge that there are limitations in any of the above and many ways that it can >> be done wrong, But it can provide a Simple usable test, and in some cases near state of the >> art testing, for the beginning time-nut that has not yet collected all the great test equipment >> that is so often referred to. >> >> WarrenS ***************** > > ----- Original Message ----- > From: "Steve Rooke" > To: "Discussion of precise time and frequency measurement" > Sent: Friday, January 09, 2009 3:18 AM > Subject: Re: [time-nuts] ADEV test setup [was GPSDO TC & Damping] > > > >> Bruce, >> >> Thanks for the detailed rundown. Looking at the picket-fence method, >> this looks possible for me but I will have to get hold of the >> reference standard. I have a Racal-Dana 1992 with IEEE488 but need to >> get an interface card for the PC end. These are fairly cheap to buy. >> >> You spoke about some types of rubidium standards being suitable, would >> you care to elaborate on that please? Would something like an Efratom >> FRS be suitable? Generating the picket-fence itself should not be >> hard as long as care is taken not to introduce noise. Do you have any >> links to articles on the design for the >> mixer/zero-crossing/square-wave beat circuit? One question, assuming >> that I have a 10MHz reference standard and I'm measuring a 10MHz dut, >> how do I arrange for them to be about 1Hz apart, given that we are >> measuring for accuracy here? 1HZ different would make the accuracy >> 1E-7 out anyway, or am I missing something here? >> >> So the real thing for the budget-conscious time-nut seems to be the >> reference standard. The ocxos you spoke about do seem to be on the >> rare/expensive side and are an order of magnitude or two better than >> the Option 4E I have in the 1992. >> >> 73, Steve >> >> 2009/1/9 Bruce Griffiths : >> >>> Addendum: >>> >>> Timestamping using a conventioanl gated counter is easily accomplished >>> using Greenhall's picket fence technique: >>> http://horology.jpl.nasa.gov/papers/picket_uffc.pdf >>> >>> The Acam TDC ICs (http://www.acam.de) have a resolution of a few tens >>> of ps and a range of up to 200ms or so depending on the chip. >>> These can easily be interfaced to most micros. >>> >>> >>> Bruce Griffiths wrote: >>> >>>> Steve >>>> >>>> If we take TvB's measurements on a Thunderbolt as some guide as to what >>>> to expect: >>>> http://www.leapsecond.com/pages/tbolt-tc/ >>>> >>>> Then to make meaningful measurements on a Thunderbolt for example one needs: >>>> >>>> 1) An independent frequency standard with an MDEV better than 1E-12 or >>>> so for 1 s >>> >>>> 2) A means of measuring MDEV with a resolution and internal noise << >>>> 1E-12 1s < Tau < 1000 s >>>> >>>> If one relaxes the Tau range to say 100s < tau < 1000s, then a wider >>>> range of techniques that have adequate resolution are available. >>>> For most GPSDOs the relevant loop time constant will be somewhere within >>>> the (100 - 1000) s range. >>>> >>>> One point often missed when quoting/plotting MDEV, ADEV measures is the >>>> measurement system noise bandwidth. >>>> The ADEV and MDEV measures are, in general, dependent on the measurement >>>> system noise bandwidth. >>>> Different systems with different noise bandwidths measuring the relative >>>> ADEV or MDEV of the same pair of OCXOs will produce different results >>>> for ADEV, MDEV. >>>> >>>> Possible measurement systems: >>>> >>>> 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. >>>> The system can have a well defined noise bandwidth together with >>>> adequate resolution if the phase comparator output drives an ADC with a >>>> resolution of 12 bits or more ( a sigma delta ADC is perhaps the most >>>> suitable). However the frequencies of the 2 sources must match closely >>>> and in the case of digital phase detectors the non linearity at the ends >>>> of the range should be avoided. >>>> >>>> 2) Heterodyne system where a low noise offset oscillator is used to mix >>>> down to a beat frequency in the audio range. >>>> The beat frequency output is low pass filtered and amplified before >>>> driving either: >>>> >>>> A) a sound card the samples from which are processed to derive the >>>> phase of the beat frequency. >>>> >>>> B) A well designed cascaded amplifier limiter low pass filter system >>>> that progressively amplifies the beat frequency signal. The output stage >>>> is a linear comparator and line driver which drives a conventional time >>>> interval counter with a resolution of 100ns or better. Using the beat >>>> frequency output to drive the counter directly results in excessive noise. >>>> >>>> 3) Dual mixer system with an offset oscillator the performance >>>> requirements of which are relaxed somewhat because only the differential >>>> phase shift between the 2 beat frequency outputs is of interest. >>>> >>>> Whilst in principle a high resolution (100ps or better) counter with >>>> interpolator could be employed to measure the phase of the divided down >>>> output of the UUT with respect to the standard, the system noise >>>> bandwidth is large and ill defined unless one resorts to crystal and/or >>>> passive RC or LC filters etc with their attendant phase stability problems. >>>> >>>> Lacking a suitable frequency standard the best you can do is log the >>>> phase and frequency errors of the thunderbolt when the OCXO is free >>>> running and plot the resultant MDEV. >>>> The best value for the loop time constant should be somewhere in the >>>> close to the value of Tau corresponding to the location of the minimum >>>> value of MDEV. >>>> Perhaps TvB can help by making measurements of the free running MDEV of >>>> a Thunderbolt as measured by the Thunderbolt itself to check the >>>> viability of this method of setting the loop TC. >>>> >>>> NOTES: >>>> >>>> 1) Assembling a high resolution timestamping counter with 100ps or so >>>> resolution should be reasonably practical. >>>> >>>> 2) Designing a optimised bandpass slope amplifier limiter cascade is >>>> relatively straightforward. >>>> >>>> 3) Optical or equivalent isolation is critical. Where mixers are used >>>> selecting one which allows the IF ports to be isolated at low >>>> frequencies is best - Minicircuits have several through-hole models that >>>> allow this. >>>> >>>> 4) The real stumbling block is obtaining a suitable reference. >>>> An FTS1200 or an OSA8607 may be suitable, however these are either rare >>>> or expensive. >>>> Some rubidium standards are also suitable. >>>> TvB only appears to have ADEV plots for the LPRO, however since MDEV is >>>> somewhat lower than ADEV an LPRO may well be suitable. >>>> >>>> 5) Using a sound card to timestamp beat frequency zero crossings or an >>>> equivalent technique is the most flexible and reliable provided that a >>>> high resolution sound card is used. >>>> Such a sound card can also be used for phase noise measurements for >>>> offset frequencies in the 20Hz to 20kHz range. >>>> Some care is required to keep mains related spurs sufficiently low. I >>>> have obtained mains related spur levels below 1uV rms by suitably >>>> arranging the 6m input cables for a balanced input PCI sound card. Since >>>> this sound card has a full scale input of 4Vrms the effect of 1uV spurs >>>> is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. >>>> >>>> 6) A relatively low noise offset source can be assembled from a DDS >>>> based system provided that a truncation spur free output frequency is >>>> chosen. >>>> >>>> Bruce >>>> >>>> Steve Rooke wrote: >>>> >>>> > This would enable us (the > >>>>> other half) to see the results of our experiments and tuning of the >>>>> gear we have otherwise it is a lot like working blind. I appreciate >>>>> that what is normally used is a counter which can continually >>>>> timestamp a dut as opposed to a gated counter but what would be the >>>>> cheapest way we could achieve this sort of setup? >>>>> >>>>> Thanks and 73, Steve >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts at febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >>>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> >> >> -- >> Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW >> Omnium finis imminet >> >> >> >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Bruce From tvb at LeapSecond.com Sat Jan 10 01:11:52 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Fri, 9 Jan 2009 17:11:52 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] References: Message-ID: <271164F1A0C04AF49C6FC3166B48F87F@pc52> > I'd like to see a similar test conducted against a local Cs clock (and/or > maser), just to get everything on one graph. > > -- john, KE5FX It's on the list. One earlier idea was to measure tc=1 10 100 1000 10k simultaneously with 5 Thunderbolts, but I suspected that unit to unit variations among the GPSDO would partially cloud the results. So that's why I did back-to-back runs using the same TBolt, same reference, and same TIC for each run. All I changed was the TC in the GUI, figuring that was the safest thing to do. /tvb From tvb at LeapSecond.com Sat Jan 10 01:35:29 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Fri, 9 Jan 2009 17:35:29 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> <323E658EDACD4944806D02246DBE8E39@pc52> <4967C0E7.5080602@xtra.co.nz> Message-ID: <5B227DEDDC3048389BB8824DA0278D9C@pc52> > Tom > > Doesnt that introduce some correlations for larger tau as both the > Thunderbolt and the 58503B are both locked to GPS? > > Bruce Correct, the choice of reference often has some impact on the plots. Since I used a GPSDO (a nice one), if the plot extended well past 10^4 or 10^5 the GPS correlation effects would show up in the long-term, I think. In that case the plots would start to appear slightly optimistic. On the other hand, because I used a GPSDO instead of a maser reference, the plot I posted appears slightly pessimistic in the short- and mid-term. So the main thing about the plot was just how well the difference between tc=10, 100, 1000 showed up, regardless if the reference was a maser or a GPSDO. A nice Rb might work too. That the TC setting was so visible using (only) a GPSDO as a reference is promising. It means normal time-nuts (oxymoron?) who don't have cesium or masers lying around have a good chance to investigate the optimal TC for their GPSDO. Looks like a 5370 or SR620 would also work for the TI counter. /tvb From bruce.griffiths at xtra.co.nz Sat Jan 10 01:52:32 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 14:52:32 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <017001c972bf$27d99260$6401a8c0@WSOffice> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net><4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com><49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com><00a801c97295$715c7cb0$6401a8c0@WSOffice> <4967C05F.8030907@xtra.co.nz> <017001c972bf$27d99260$6401a8c0@WSOffice> Message-ID: <4967FF60.60507@xtra.co.nz> Warren Another limitation of such phase detectors is that the 2 frequencies being compared have to be within a small fraction of 1Hz of one another. This rules out using a low noise reference that happens to have drifted/aged out of the adjustment range but which is otherwise OK. Bruce WarrenS wrote: >> Bruce said: >> The critical requirement is that the 2 standards being compared are statistically independent. >> Comparing a pair of Thunderbolts GPSDOs with similar time constants and >> damping will give optimistic results for Tau comparable with or greater than the loop time constant. >> Its is even better is to use 3 or more similar standards simultaneously >> logging phase differences between the various pairs (0.5*N(N-1) pairs for N standards). >> It is then possible to obtain estimates for ADEV, MDEV etc for each standard. >> > > The optimistic results at and above the loop time constant, that results even when 3 or more units are used, > is because the noise is then mostly due to the GPS signal itself and NOT the local oscillators in the GPSDO. > In effect you are then using the same 1PPS signal into each unit, and any common noise on the > GPS 1PPS signal will cancel and not be seen. > So I think what Bruce is saying is that you can not (or is it should not?) use the GPS signal to > measure the GPS's noise. > But the point is, if you want to compare your GPSDO with different settings, or compare it to > another OCXO, It can be done this way, if you do not have a better ref to use. > You could then add the noise of the GPS nose above the control loop time to your > optimistic results if you want true results at high Tau values. > > Also note that having the GPS noise cancle is not necessary a bad thing, It can be a good thing > especially if the GPS noise is not what it is that you want to measure. > > >> Like all digital phase detectors its best to avoid, if possible, the nonlinearity inherent at the ends of the range. >> > > Using a phase detector near its end point (or at its crossover point if there is any deadband) > is something that needs to be avoided. > The two basic standard ways to insure that just the center of the phase detector's range is use: > 1) Divide the signals down just enough before sending them to the phase detector so that > the end points is not an issue. This works when both signals are from devices that are > locked to a common signal such as the GPS. > > 2) When one of signals is from a non locked source such as a OCXO whose phase can drift > any amount overtime, One of ways to limit phase detector issues, and use just the very accurate zero phase point, is to use the Phase detector's output to lock the OCXO in a fast control loop and then by knowing the gain of the EFC input, the filtered EFC voltage can be use as freq drift information to find the ADEV's. > > WarrenS > > *************: > Bruce >>>> What would it take as a minimum for ordinary time-nuts to be able >>>> to perform an ADEV test on their ocxo's and gpsdo's for phase stability at "home", >>>> > > >> Warren wrote: >> >>> I have noticed that Given enough expertise, anything can be made more complicated than need be. >>> >>> For doing noise testing, there is an option to an expensive osc reference, >>> that has been pointed out many times before. Its advantages is, that unlike other reference >>> standards this one does not have a limit in how low it can measure, and most time-nuts seem >>> to already one or more laying around. >>> The alternative is to just use another one of the same things you are testing (or ANY thing better). >>> When comparing two independent noise sources, you get an answer that is the RMS sum of the two. >>> That is the answer will be up to 1.414 times the noise of the worse one. It's not too hard to find >>> which is the worse one if you need to with a few more test. >>> >>> >>> >> The critical requirement is that the 2 standards being compared are statistically independent. >> Comparing a pair of Thunderbolts GPSDOs with similar time constants and >> damping will give optimistic results for Tau comparable with or greater than the loop time constant. >> Its is even better is to use 3 or more similar standards simultaneously >> logging phase differences between the various pairs (0.5*N(N-1) pairs for N standards). >> It is then possible to obtain estimates for ADEV, MDEV etc for each standard. >> > > >>> There are also some simple analog alternatives for measuring Phase noise that do not need high >>> resolution Digital TIC, time stamp etc. and can give higher resolution results. >>> I use a XOR phase detector, an analog filter and a radio shack multimeter with PC interface capability. >>> > > >> Like all digital phase detectors its best to avoid, if possible, the nonlinearity inherent at the ends of the range. >> >> > > >>> The ADEV, ODEV and MDEV can then be calculated from the text file data using any of the >>> many great downloadable programs that are available . >>> >>> The 2G test with a strip chart record of the EFC can be used as a simple way to measure >>> the control loop Time constant and see how the control loop responses to an Osc step function error. >>> >>> Another interesting and useful effect that can be used if one is careful interrupting the results is the >>> fact that common errors will tend to cancel. >>> If you compare the noise of two different PLL controlled Osc driven by the SAME 1PPS signal, >>> you will see Just the effect of the control loops and Osc and NOT the effect of the 1pps GPS noise >>> itself. Not what you really want to know when matching an OSC's noise to a GPS signal, but it can >>> provide some interesting insights and results about the control loop and Osc. >>> >>> I do acknowledge that there are limitations in any of the above and many ways that it can >>> be done wrong, But it can provide a Simple usable test, and in some cases near state of the >>> art testing, for the beginning time-nut that has not yet collected all the great test equipment >>> that is so often referred to. >>> >>> WarrenS >>> > > ***************** > >> ----- Original Message ----- >> From: "Steve Rooke" >> To: "Discussion of precise time and frequency measurement" >> Sent: Friday, January 09, 2009 3:18 AM >> Subject: Re: [time-nuts] ADEV test setup [was GPSDO TC & Damping] >> >> >> >> >>> Bruce, >>> >>> Thanks for the detailed rundown. Looking at the picket-fence method, >>> this looks possible for me but I will have to get hold of the >>> reference standard. I have a Racal-Dana 1992 with IEEE488 but need to >>> get an interface card for the PC end. These are fairly cheap to buy. >>> >>> You spoke about some types of rubidium standards being suitable, would >>> you care to elaborate on that please? Would something like an Efratom >>> FRS be suitable? Generating the picket-fence itself should not be >>> hard as long as care is taken not to introduce noise. Do you have any >>> links to articles on the design for the >>> mixer/zero-crossing/square-wave beat circuit? One question, assuming >>> that I have a 10MHz reference standard and I'm measuring a 10MHz dut, >>> how do I arrange for them to be about 1Hz apart, given that we are >>> measuring for accuracy here? 1HZ different would make the accuracy >>> 1E-7 out anyway, or am I missing something here? >>> >>> So the real thing for the budget-conscious time-nut seems to be the >>> reference standard. The ocxos you spoke about do seem to be on the >>> rare/expensive side and are an order of magnitude or two better than >>> the Option 4E I have in the 1992. >>> >>> 73, Steve >>> >>> 2009/1/9 Bruce Griffiths : >>> >>> >>>> Addendum: >>>> >>>> Timestamping using a conventioanl gated counter is easily accomplished >>>> using Greenhall's picket fence technique: >>>> http://horology.jpl.nasa.gov/papers/picket_uffc.pdf >>>> >>>> The Acam TDC ICs (http://www.acam.de) have a resolution of a few tens >>>> of ps and a range of up to 200ms or so depending on the chip. >>>> These can easily be interfaced to most micros. >>>> >>>> >>>> Bruce Griffiths wrote: >>>> >>>> >>>>> Steve >>>>> >>>>> If we take TvB's measurements on a Thunderbolt as some guide as to what >>>>> to expect: >>>>> http://www.leapsecond.com/pages/tbolt-tc/ >>>>> >>>>> Then to make meaningful measurements on a Thunderbolt for example one needs: >>>>> >>>>> 1) An independent frequency standard with an MDEV better than 1E-12 or >>>>> so for 1 s >>>> >>>>> 2) A means of measuring MDEV with a resolution and internal noise << >>>>> 1E-12 1s < Tau < 1000 s >>>>> >>>>> If one relaxes the Tau range to say 100s < tau < 1000s, then a wider >>>>> range of techniques that have adequate resolution are available. >>>>> For most GPSDOs the relevant loop time constant will be somewhere within >>>>> the (100 - 1000) s range. >>>>> >>>>> One point often missed when quoting/plotting MDEV, ADEV measures is the >>>>> measurement system noise bandwidth. >>>>> The ADEV and MDEV measures are, in general, dependent on the measurement >>>>> system noise bandwidth. >>>>> Different systems with different noise bandwidths measuring the relative >>>>> ADEV or MDEV of the same pair of OCXOs will produce different results >>>>> for ADEV, MDEV. >>>>> >>>>> Possible measurement systems: >>>>> >>>>> 1) Phase comparator directly comparing phases of the 2 (10MHz?) sources. >>>>> The system can have a well defined noise bandwidth together with >>>>> adequate resolution if the phase comparator output drives an ADC with a >>>>> resolution of 12 bits or more ( a sigma delta ADC is perhaps the most >>>>> suitable). However the frequencies of the 2 sources must match closely >>>>> and in the case of digital phase detectors the non linearity at the ends >>>>> of the range should be avoided. >>>>> >>>>> 2) Heterodyne system where a low noise offset oscillator is used to mix >>>>> down to a beat frequency in the audio range. >>>>> The beat frequency output is low pass filtered and amplified before >>>>> driving either: >>>>> >>>>> A) a sound card the samples from which are processed to derive the >>>>> phase of the beat frequency. >>>>> >>>>> B) A well designed cascaded amplifier limiter low pass filter system >>>>> that progressively amplifies the beat frequency signal. The output stage >>>>> is a linear comparator and line driver which drives a conventional time >>>>> interval counter with a resolution of 100ns or better. Using the beat >>>>> frequency output to drive the counter directly results in excessive noise. >>>>> >>>>> 3) Dual mixer system with an offset oscillator the performance >>>>> requirements of which are relaxed somewhat because only the differential >>>>> phase shift between the 2 beat frequency outputs is of interest. >>>>> >>>>> Whilst in principle a high resolution (100ps or better) counter with >>>>> interpolator could be employed to measure the phase of the divided down >>>>> output of the UUT with respect to the standard, the system noise >>>>> bandwidth is large and ill defined unless one resorts to crystal and/or >>>>> passive RC or LC filters etc with their attendant phase stability problems. >>>>> >>>>> Lacking a suitable frequency standard the best you can do is log the >>>>> phase and frequency errors of the thunderbolt when the OCXO is free >>>>> running and plot the resultant MDEV. >>>>> The best value for the loop time constant should be somewhere in the >>>>> close to the value of Tau corresponding to the location of the minimum >>>>> value of MDEV. >>>>> Perhaps TvB can help by making measurements of the free running MDEV of >>>>> a Thunderbolt as measured by the Thunderbolt itself to check the >>>>> viability of this method of setting the loop TC. >>>>> >>>>> NOTES: >>>>> >>>>> 1) Assembling a high resolution timestamping counter with 100ps or so >>>>> resolution should be reasonably practical. >>>>> >>>>> 2) Designing a optimised bandpass slope amplifier limiter cascade is >>>>> relatively straightforward. >>>>> >>>>> 3) Optical or equivalent isolation is critical. Where mixers are used >>>>> selecting one which allows the IF ports to be isolated at low >>>>> frequencies is best - Minicircuits have several through-hole models that >>>>> allow this. >>>>> >>>>> 4) The real stumbling block is obtaining a suitable reference. >>>>> An FTS1200 or an OSA8607 may be suitable, however these are either rare >>>>> or expensive. >>>>> Some rubidium standards are also suitable. >>>>> TvB only appears to have ADEV plots for the LPRO, however since MDEV is >>>>> somewhat lower than ADEV an LPRO may well be suitable. >>>>> >>>>> 5) Using a sound card to timestamp beat frequency zero crossings or an >>>>> equivalent technique is the most flexible and reliable provided that a >>>>> high resolution sound card is used. >>>>> Such a sound card can also be used for phase noise measurements for >>>>> offset frequencies in the 20Hz to 20kHz range. >>>>> Some care is required to keep mains related spurs sufficiently low. I >>>>> have obtained mains related spur levels below 1uV rms by suitably >>>>> arranging the 6m input cables for a balanced input PCI sound card. Since >>>>> this sound card has a full scale input of 4Vrms the effect of 1uV spurs >>>>> is negligible (< 5 fs with 10MHz mixer inputs) for these purposes. >>>>> >>>>> 6) A relatively low noise offset source can be assembled from a DDS >>>>> based system provided that a truncation spur free output frequency is >>>>> chosen. >>>>> >>>>> Bruce >>>>> >>>>> Steve Rooke wrote: >>>>> >>>>> >>>>> >> This would enable us (the >> >> >>>>>> other half) to see the results of our experiments and tuning of the >>>>>> gear we have otherwise it is a lot like working blind. I appreciate >>>>>> that what is normally used is a counter which can continually >>>>>> timestamp a dut as opposed to a gated counter but what would be the >>>>>> cheapest way we could achieve this sort of setup? >>>>>> >>>>>> Thanks and 73, Steve >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> time-nuts mailing list -- time-nuts at febo.com >>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>> and follow the instructions there. >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts at febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >>>> >>> -- >>> Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW >>> Omnium finis imminet >>> >>> >>> >>> >>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> >> > > Bruce > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From bruce.griffiths at xtra.co.nz Sat Jan 10 01:56:16 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 14:56:16 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <5B227DEDDC3048389BB8824DA0278D9C@pc52> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> <323E658EDACD4944806D02246DBE8E39@pc52> <4967C0E7.5080602@xtra.co.nz> <5B227DEDDC3048389BB8824DA0278D9C@pc52> Message-ID: <49680040.8080509@xtra.co.nz> Tom Van Baak wrote: >> Tom >> >> Doesnt that introduce some correlations for larger tau as both the >> Thunderbolt and the 58503B are both locked to GPS? >> >> Bruce >> > > Correct, the choice of reference often has some impact on the plots. > > Since I used a GPSDO (a nice one), if the plot extended well > past 10^4 or 10^5 the GPS correlation effects would show up in > the long-term, I think. In that case the plots would start to appear > slightly optimistic. > > On the other hand, because I used a GPSDO instead of a maser > reference, the plot I posted appears slightly pessimistic in the > short- and mid-term. > > So the main thing about the plot was just how well the difference > between tc=10, 100, 1000 showed up, regardless if the reference > was a maser or a GPSDO. A nice Rb might work too. > > That the TC setting was so visible using (only) a GPSDO as a > reference is promising. It means normal time-nuts (oxymoron?) > who don't have cesium or masers lying around have a good > chance to investigate the optimal TC for their GPSDO. Looks > like a 5370 or SR620 would also work for the TI counter. > > /tvb > > > Tom What does the MDEV plot for the particular Thunderbolt look like when the Thunderbolt itself measures the phase error of the its unlocked OCXO against GPS? In other words how reliable a guide is setting the loop TC to coincide with the value of Tau at the minimum of such an MDEV plot? Bruce From warrensjmail-one at yahoo.com Sat Jan 10 03:01:11 2009 From: warrensjmail-one at yahoo.com (WarrenS) Date: Fri, 9 Jan 2009 19:01:11 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] Message-ID: <017101c972cf$b22c6360$6401a8c0@WSOffice> Bruce True, but not a problem for me, because I don't have any like that. I know you have brought this up many times. Is it a real problem that exist enough to even think about? What kind of Osc are you referring to that is worth keeping even though it can not be adjusted to be on freq. How far off is it? How do you know it is good enough? Trick question, why not just continue to use what it is that you tested it with? Maybe could use the dual 90 deg phase detector system, so there is at least one phase signal near the center of the range at all times. There is probable some simpler solution also. WarrenS ***************** Warren Another limitation of such phase detectors is that the 2 frequencies being compared have to be within a small fraction of 1Hz of one another. This rules out using a low noise reference that happens to have drifted/aged out of the adjustment range but which is otherwise OK. Bruce From mac at checa.us Sat Jan 10 03:34:08 2009 From: mac at checa.us (Miguel Checa) Date: Fri, 09 Jan 2009 22:34:08 -0500 Subject: [time-nuts] 20Hz p-p / 24 hours with a Mini-T (Mike Feher) In-Reply-To: References: Message-ID: <49681730.2060708@checa.us> Mike, Yes, sorry. 10MHz x 2900 for the LO, +/- 10Hz at 29GHz. In fact, the mini-t has good stability, it goes down to +/- 6Hz ---EXCEPT--- when it loses the last satellite and we don't know why it does that. With Time constant=3600sec the unit can do +/-3Hz. As I said, the satellites are there but it uses the best for time, the monitor reports all the others as tracked but not used, funny thing is the signal (AMU) reported is either 0.8 or 1.0 for all those, my guess is the unit ignores them and forgets all about them and when the one in use goes down, the mini-t goes to bed... Trimble said today they have a solution...we'll see. Regards, Miguel W4/LU4AXC > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Jan 2009 08:00:24 -0500 > From: "Mike Feher" > Subject: Re: [time-nuts] 20Hz p-p / 24 hours with a Mini-T > To: "'Discussion of precise time and frequency measurement'" > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Mike - > > You may want to mention that this requirement is to be met at 30.5 GHz. > Regards - Mike > > > > Mike B. Feher, N4FS > 89 Arnold Blvd. > Howell, NJ, 07731 > 732-886-5960 > > > From bruce.griffiths at xtra.co.nz Sat Jan 10 03:47:50 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 16:47:50 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <017101c972cf$b22c6360$6401a8c0@WSOffice> References: <017101c972cf$b22c6360$6401a8c0@WSOffice> Message-ID: <49681A66.6000908@xtra.co.nz> Warren Yes its a real problem several of us have such OCXOs. They are typically a few Hz off. If they can be shown to have low noise and low drift they are worth keeping. Its a pity to discard such OCXOs just because ones measurement system cant verify their performance. The only way to know if such an OCXO is still good enough is to compare it with a better standard or with a pair of low noise OCXOs using a 3 cornered hat technique. Unfortunately one can't easily use 3 digital phase detectors plus ADCs for this unless the associated low pass filter cutoff frequency is increased. One would then also need to use something like a sigma delta ADC rather than a cheap DVM to ensure that the low pass filter output sampling rate is high enough. An ADC with an input multiplexer could also be used (several microprocessor have such ADCs built in). Such a setup is not that much simpler than using an array of timestamp counters based on a suitable microprocessor. A dual mixer scheme would require 6 timestamp counters or 6 simultaneous sound card inputs. In principle one could use 3 dividers setup so that the output transitions of each divider are well separated from the output transitions of the other dividers. A standard time interval counter with an external input multiplexer could then be used in a variation of the picket fence technique to sequentially time stamp the divider output transitions. Bruce WarrenS wrote: > Bruce > > True, but not a problem for me, because I don't have any like that. > I know you have brought this up many times. Is it a real problem that > exist enough to even think about? What kind of Osc are you referring to > that is worth keeping even though it can not be adjusted to be on freq. > How far off is it? > How do you know it is good enough? > Trick question, why not just continue to use what it is that you tested it with? > Maybe could use the dual 90 deg phase detector system, > so there is at least one phase signal near the center of the range at all times. > There is probable some simpler solution also. > > > WarrenS > > ***************** > > Warren > > Another limitation of such phase detectors is that the 2 frequencies > being compared have to be within a small fraction of 1Hz of one another. > This rules out using a low noise reference that happens to have > drifted/aged out of the adjustment range but which is otherwise OK. > > Bruce > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From richiem at hughes.net Sat Jan 10 03:48:10 2009 From: richiem at hughes.net (Richard Moore) Date: Fri, 9 Jan 2009 19:48:10 -0800 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: References: Message-ID: <005C40F4-7970-4219-9D08-387688BC8BDA@hughes.net> On Jan 9, 2009, at 12:10 AM, time-nuts-request at febo.com wrote: > Message: 4 > Date: Fri, 09 Jan 2009 19:18:57 +1300 > From: Bruce Griffiths > Subject: Re: [time-nuts] GPSDO TC & Damping >> Well, like many here, I don't actually have the equipment, especially >> the reference std., to do these MDEV, ADEV and other analyses, so, >> since I use the GPSDO for a frequency standard and not for UTC, I >> thought I'd get the expert opinions. Magnus has several times >> indicated here that a TC laying somewhere in and around 100 to 1000 >> secs is probably optimum. When I enquired some time back about >> damping in the TBolt, the consensus seemed to be "leave it at 1.2". I >> have, but it just seems to me that won't be optimum for a fixed- >> position, lab-located frequency standard -- at the moment, I'm >> leaning toward the 0.7to 1.0 area. >> >> > Why, since it has been demonstrated that a damping factor of 1.2 is > better than one of 0.7 for a particular Thunderbolt this would tend to > indicate that adjusting the damping without good justification is > somewhat foolhardy. > If in fact the phase noise characteristics of your OCXO are similar > toi > the one in the Thunderbolt that Tom measured this would degrade the > performance. > > With no way of measuring the effect of such adjustments you are just > hoping that your particular Thunderbolt is similar to the one Tom > measured. > Thats not engineering its more like witchcraft. > >> Tom's recent chart was quite helpful, especially the 1000 sec curve. >> Now, I hope that Tom or someone else follows up on the suggestion to >> track performance vs. damping factor. I do understand that the >> results for any one GPSDO don't *necessarily* translate to other >> devices, but they don't necessarily don't, either. At least for the >> TBolts a lot of us are playing with, one good example (like Tom's) >> may well put mine in a better ballpark than the ballpark the factory >> wants it to play in, given the factors that you all have described. >> Thx everyone for the comments. Look forward to the next round! >> >> Dick Moore >> > The probability that you will improve the performance significantly > without a means of measuring the resultant performance is fairly low. > You will never know if either an improvement or a degradation in > performance has occurred. > The one saving grace being that the factory defaults can always be > restored. > > Bruce Bruce, thx for the reminder -- my friend and mentor Paul W. Klipsch was fond of saying that "You can't make what you can't measure 'cause you don't know when you've got it made!" At the same time, all sorts of wonderful things have come about thru just fooling around. Again, I remark that for all the reasons Tom enumerated -- er, listed -- the manufacturer's choice of settings may not be the best choice for a particular use. When in a strange country, local enquiry is usually recommended. For GPSDOs, a strange country to me, what better place to enquire than here? Dick Moore From richiem at hughes.net Sat Jan 10 04:05:34 2009 From: richiem at hughes.net (Richard Moore) Date: Fri, 9 Jan 2009 20:05:34 -0800 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: References: Message-ID: <6A4C1BD5-826C-4B7B-A2A6-EB15BFEEC9B7@hughes.net> On Jan 9, 2009, at 2:24 AM, time-nuts-request at febo.com wrote: > Message: 2 > Date: Fri, 09 Jan 2009 10:27:05 +0100 > From: Magnus Danielson > Subject: Re: [time-nuts] GPSDO TC & Damping > > Dick, > >> Well, like many here, I don't actually have the equipment, especially >> the reference std., to do these MDEV, ADEV and other analyses, so, >> since I use the GPSDO for a frequency standard and not for UTC, I >> thought I'd get the expert opinions. Magnus has several times >> indicated here that a TC laying somewhere in and around 100 to 1000 >> secs is probably optimum. > > I think you have misinterpreted my postings. I never claimed it was > optimum, or at least never intended to. I think 100 secs is good for > doing additional experiments with damping parameters. It would be > interesting to see just how low the bulb may go. This only since it is > obvious that it makes such a clear difference at 100 secs. It's a > choice > out of measurement and interpretation practicality, not optimum from a > use perspective. If you consider my postings you would see that I > rather > promote the concept of adjusting the time constant dynamically to > situations rather than say 1234.5678 seconds is the optimum. > > Cheers, > Magnus Sorry, Magnus, I didn't mean to put words in your mouth. I was remembering last Fall, when you suggested that people look at your ADEV plot and to be mindful of the of the bounding slopes of the curves. If I've mis-remembered the emphasis or the facts, I do apologize. I thought your argument then, as I remember it, was strong and valuable. Seems like it gave a good range of possible values to use for Tau in the measurements. I probably won't go far beyond the capabilities of the TBolt, such as implementing a PID controller with dynamic control of variables using a microcontroller and LPGAys and writing my own software, but I love it when you talk that way. Best, Dick Moore From bruce.griffiths at xtra.co.nz Sat Jan 10 04:11:50 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 17:11:50 +1300 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: <005C40F4-7970-4219-9D08-387688BC8BDA@hughes.net> References: <005C40F4-7970-4219-9D08-387688BC8BDA@hughes.net> Message-ID: <49682006.3000902@xtra.co.nz> Richard Moore wrote: > On Jan 9, 2009, at 12:10 AM, time-nuts-request at febo.com wrote: > > >> Message: 4 >> Date: Fri, 09 Jan 2009 19:18:57 +1300 >> From: Bruce Griffiths >> Subject: Re: [time-nuts] GPSDO TC & Damping >> > > >>> Well, like many here, I don't actually have the equipment, especially >>> the reference std., to do these MDEV, ADEV and other analyses, so, >>> since I use the GPSDO for a frequency standard and not for UTC, I >>> thought I'd get the expert opinions. Magnus has several times >>> indicated here that a TC laying somewhere in and around 100 to 1000 >>> secs is probably optimum. When I enquired some time back about >>> damping in the TBolt, the consensus seemed to be "leave it at 1.2". I >>> have, but it just seems to me that won't be optimum for a fixed- >>> position, lab-located frequency standard -- at the moment, I'm >>> leaning toward the 0.7to 1.0 area. >>> >>> >>> >> Why, since it has been demonstrated that a damping factor of 1.2 is >> better than one of 0.7 for a particular Thunderbolt this would tend to >> indicate that adjusting the damping without good justification is >> somewhat foolhardy. >> If in fact the phase noise characteristics of your OCXO are similar >> toi >> the one in the Thunderbolt that Tom measured this would degrade the >> performance. >> >> With no way of measuring the effect of such adjustments you are just >> hoping that your particular Thunderbolt is similar to the one Tom >> measured. >> Thats not engineering its more like witchcraft. >> >> >>> Tom's recent chart was quite helpful, especially the 1000 sec curve. >>> Now, I hope that Tom or someone else follows up on the suggestion to >>> track performance vs. damping factor. I do understand that the >>> results for any one GPSDO don't *necessarily* translate to other >>> devices, but they don't necessarily don't, either. At least for the >>> TBolts a lot of us are playing with, one good example (like Tom's) >>> may well put mine in a better ballpark than the ballpark the factory >>> wants it to play in, given the factors that you all have described. >>> Thx everyone for the comments. Look forward to the next round! >>> >>> Dick Moore >>> >>> >> The probability that you will improve the performance significantly >> without a means of measuring the resultant performance is fairly low. >> You will never know if either an improvement or a degradation in >> performance has occurred. >> The one saving grace being that the factory defaults can always be >> restored. >> >> Bruce >> > > Bruce, thx for the reminder -- my friend and mentor Paul W. Klipsch > was fond of saying that "You can't make what you can't measure 'cause > you don't know when you've got it made!" At the same time, all sorts > of wonderful things have come about thru just fooling around. Again, > I remark that for all the reasons Tom enumerated -- er, listed -- the > manufacturer's choice of settings may not be the best choice for a > particular use. When in a strange country, local enquiry is usually > recommended. For GPSDOs, a strange country to me, what better place > to enquire than here? > > Dick Moore > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Dick What does the plot of ADEV vs tau look like when the Thunderbolt OCXO is unlocked and one just logs the Thunderbolt's own measurements of the phase and frequency errors. It should exhibit a minimum at a value of certain value of tau. Setting the loop TC to somewhere near this vlue of Tau is perhaps a good start in the absence of any other data. No other equipment other than the Thunderbolt and a PC is required to do this. Bruce From bruce.griffiths at xtra.co.nz Sat Jan 10 05:32:30 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 18:32:30 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> Message-ID: <496832EE.8090305@xtra.co.nz> Steve Steve Rooke wrote: > Bruce, > > Thanks for the detailed rundown. Looking at the picket-fence method, > this looks possible for me but I will have to get hold of the > reference standard. I have a Racal-Dana 1992 with IEEE488 but need to > get an interface card for the PC end. These are fairly cheap to buy. > > You spoke about some types of rubidium standards being suitable, would > you care to elaborate on that please? Would something like an Efratom > FRS be suitable? Generating the picket-fence itself should not be > hard as long as care is taken not to introduce noise. Do you have any > links to articles on the design for the > mixer/zero-crossing/square-wave beat circuit? One question, assuming > that I have a 10MHz reference standard and I'm measuring a 10MHz dut, > how do I arrange for them to be about 1Hz apart, given that we are > measuring for accuracy here? 1HZ different would make the accuracy > 1E-7 out anyway, or am I missing something here? > > The best article I've come across on zero-crossing detector design is: The Design of Low Jitter Hard Limiters" Oliver Collins, IEEE transactions on Communications, Vol 44 No 5, May 1996 pp 601-608 Unfortunately its not free, however you may be able to access it via a Library. However if you only want to use the technique described in the paper, I have a couple of spreadsheets that calculate the stage gains and low pass filter time constants both for the simplified analysis in the paper and the more general case where the input noise spectral density differs for each stage. Some pointers on what to include in the noise calculations for each stage can be found at: http://www.ko4bb.com/~bruce/ZeroCrossingDetectors.html Some care is required, in that if the spreadsheet predicts a gain of less than unity for the input stage, it is in fact better to use a passive RC low pass filter in front of the first amplifier limiter stage (without a clamp as typically the IF signal amplitude at the mixer output is insufficient to cause the clamp diodes to conduct - more complex clamps are too noisy). The amplifier limiter chain is then redesigned to accommodate this change. Don't be taken in by those who would insist that everything should be linear as long as possible, the resultant deign is suboptimal. Such comments sprang from the fact that no one at that time had worked out how to include the effect of the clamps on the performance. Oliver Collins solved that problem, so there is no longer a valid excuse for such misguided recommendations. > So the real thing for the budget-conscious time-nut seems to be the > reference standard. The ocxos you spoke about do seem to be on the > rare/expensive side and are an order of magnitude or two better than > the Option 4E I have in the 1992. > > 73, Steve > Bruce From holrum at hotmail.com Sat Jan 10 05:38:26 2009 From: holrum at hotmail.com (Mark Sims) Date: Sat, 10 Jan 2009 05:38:26 +0000 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: References: Message-ID: The good Lady Heather's GPS Disciplined Oscillator Controller Program calculates and plots (also writes the results to the log file) ADEV and OADEV of the Thunderbolt's reported error estimates. My comparison of these "auto-ADEVs" to the values generated from a Tek DC5010 counter showed they agreed within a factor of two. Note that the DC5010 was measuring the Thunderbolt 10 MHz signal against a 1 MHz cesium reference. The data had to be massaged some where the phase rolled over (the DC5010 counter has a 5 nsec or so bogus zone where the time interval is wrapping). The counter was set up to calculate time intervals over 10 seconds (to get picosecond resolution) so ADEVs below 10 seconds were not available. ----------------- What does the plot of ADEV vs tau look like when the Thunderbolt OCXO is unlocked and one just logs the Thunderbolt's own measurements of the phase and frequency errors. It should exhibit a minimum at a value of certain value of tau. _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From bruce.griffiths at xtra.co.nz Sat Jan 10 05:57:25 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 10 Jan 2009 18:57:25 +1300 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: References: Message-ID: <496838C5.1050909@xtra.co.nz> Mark Sims wrote: > The good Lady Heather's GPS Disciplined Oscillator Controller Program calculates and plots (also writes the results to the log file) ADEV and OADEV of the Thunderbolt's reported error estimates. My comparison of these "auto-ADEVs" to the values generated from a Tek DC5010 counter showed they agreed within a factor of two. > > Note that the DC5010 was measuring the Thunderbolt 10 MHz signal against a 1 MHz cesium reference. The data had to be massaged some where the phase rolled over (the DC5010 counter has a 5 nsec or so bogus zone where the time interval is wrapping). The counter was set up to calculate time intervals over 10 seconds (to get picosecond resolution) so ADEVs below 10 seconds were not available. > > > > ----------------- > > What does the plot of ADEV vs tau look like when the Thunderbolt OCXO is > unlocked and one just logs the Thunderbolt's own measurements of the > phase and frequency errors. > It should exhibit a minimum at a value of certain value of tau. > > > _________________________________________________________________ > Windows Live?: Keep your life in sync. > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Mark Where these results obtained when the Thunderbolt OCXO was locked? Bruce From magnus at rubidium.dyndns.org Sat Jan 10 09:27:12 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 10 Jan 2009 10:27:12 +0100 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <271164F1A0C04AF49C6FC3166B48F87F@pc52> References: <271164F1A0C04AF49C6FC3166B48F87F@pc52> Message-ID: <496869F0.6030501@rubidium.dyndns.org> Tom Van Baak skrev: >> I'd like to see a similar test conducted against a local Cs clock (and/or >> maser), just to get everything on one graph. >> >> -- john, KE5FX > > It's on the list. > > One earlier idea was to measure tc=1 10 100 1000 10k > simultaneously with 5 Thunderbolts, but I suspected that > unit to unit variations among the GPSDO would partially > cloud the results. So that's why I did back-to-back runs > using the same TBolt, same reference, and same TIC for > each run. All I changed was the TC in the GUI, figuring > that was the safest thing to do. You could do thia, but in a rotating scheme such that you end up having measured all thunderbolts for all TCs. That would help decorrelate individual differences among the thunderbolts. Cheers, Magnus From sar10538 at gmail.com Sat Jan 10 09:46:38 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Sat, 10 Jan 2009 22:46:38 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <496832EE.8090305@xtra.co.nz> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net> <4966EC51.5050300@xtra.co.nz> <1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com> <49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com> <496832EE.8090305@xtra.co.nz> Message-ID: <1231b6a80901100146k4afdcdd3jbfd987540ffb9cbc@mail.gmail.com> Bruce, thanks, I'm soaking it all up. 73, Steve 2009/1/10 Bruce Griffiths : > Steve > > Steve Rooke wrote: >> Bruce, >> >> Thanks for the detailed rundown. Looking at the picket-fence method, >> this looks possible for me but I will have to get hold of the >> reference standard. I have a Racal-Dana 1992 with IEEE488 but need to >> get an interface card for the PC end. These are fairly cheap to buy. >> >> You spoke about some types of rubidium standards being suitable, would >> you care to elaborate on that please? Would something like an Efratom >> FRS be suitable? Generating the picket-fence itself should not be >> hard as long as care is taken not to introduce noise. Do you have any >> links to articles on the design for the >> mixer/zero-crossing/square-wave beat circuit? One question, assuming >> that I have a 10MHz reference standard and I'm measuring a 10MHz dut, >> how do I arrange for them to be about 1Hz apart, given that we are >> measuring for accuracy here? 1HZ different would make the accuracy >> 1E-7 out anyway, or am I missing something here? >> >> > The best article I've come across on zero-crossing detector design is: > > The Design of Low Jitter Hard Limiters" Oliver Collins, IEEE > transactions on Communications, Vol 44 No 5, May 1996 pp 601-608 > > Unfortunately its not free, however you may be able to access it via a > Library. > > However if you only want to use the technique described in the paper, I > have a couple of spreadsheets that calculate the stage gains and low > pass filter time constants both for the simplified analysis in the paper > and the more general case where the input noise spectral density differs > for each stage. > Some pointers on what to include in the noise calculations for each > stage can be found at: > > http://www.ko4bb.com/~bruce/ZeroCrossingDetectors.html > > > Some care is required, in that if the spreadsheet predicts a gain of > less than unity for the input stage, it is in fact better to use a > passive RC low pass filter in front of the first amplifier limiter stage > (without a clamp as typically the IF signal amplitude at the mixer > output is insufficient to cause the clamp diodes to conduct - more > complex clamps are too noisy). > The amplifier limiter chain is then redesigned to accommodate this change. > > Don't be taken in by those who would insist that everything should be > linear as long as possible, the resultant deign is suboptimal. > Such comments sprang from the fact that no one at that time had worked > out how to include the effect of the clamps on the performance. > Oliver Collins solved that problem, so there is no longer a valid excuse > for such misguided recommendations. > >> So the real thing for the budget-conscious time-nut seems to be the >> reference standard. The ocxos you spoke about do seem to be on the >> rare/expensive side and are an order of magnitude or two better than >> the Option 4E I have in the 1992. >> >> 73, Steve >> > Bruce > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From magnus at rubidium.dyndns.org Sat Jan 10 09:49:00 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 10 Jan 2009 10:49:00 +0100 Subject: [time-nuts] GPSDO TC & Damping In-Reply-To: <6A4C1BD5-826C-4B7B-A2A6-EB15BFEEC9B7@hughes.net> References: <6A4C1BD5-826C-4B7B-A2A6-EB15BFEEC9B7@hughes.net> Message-ID: <49686F0C.3070101@rubidium.dyndns.org> Dick, > Sorry, Magnus, I didn't mean to put words in your mouth. No worries, I just did not want it to be raised to "truth". > I was remembering last Fall, when you suggested that people look at your > ADEV plot and to be mindful of the of the bounding slopes of the > curves. If I've mis-remembered the emphasis or the facts, I do > apologize. I thought your argument then, as I remember it, was strong > and valuable. Seems like it gave a good range of possible values to > use for Tau in the measurements. Do not recall the particular discussion. A ref into the archives or date would be apprechiated. > I probably won't go far beyond the capabilities of the TBolt, such as > implementing a PID controller with dynamic control of variables using > a microcontroller and LPGAys and writing my own software, but I love > it when you talk that way. Sounds dangerous. :) I have been looking further into the variance, ADEV, MDEV and TDEV with respect to the effect of various dampings. It is becomming clear to me that the gain effect which can be attributed to damping will ripple over to all those measures. I have not had the time to convert this to a complete analysis, but I think I can do that. However, to give a partial answer to Bruce, I would like to point to a passage in Gardiner where the optimum damping for minimum flicker noise is being found, and that is for 1.14 rather than 0.5 which would be minimum noise bandwidth. Gardiner does not go into ADEV and friends, but does provide the refernces and gives an indication of convergance problems for flicker noise on variance, also indicating that this is a problem for further analysis. Using ADEV and friends in replacement analysis could be made analogously for other noise types and as it happends also work in cooperation with investigating the effect on various noisetypes. Regardless, it is an interesting little problem and I get to exercise the little grey and refresh my always failing abilities in integration. Cheers, Magnus From magnus at rubidium.dyndns.org Sat Jan 10 10:06:39 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 10 Jan 2009 11:06:39 +0100 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <4968732F.5080901@rubidium.dyndns.org> Joseph, > time-nuts-bounces at febo.com wrote on 01/07/2009 10:47:46 PM: > >> Joseph, >> >>>>> Could be a differential TX and RX. I recall that they send a RS422 >>> signal. >>>> Depending on the speed, RS422 works fine with transformers. >>> Yes. It would be 10 MHz or 20 MHz, depending on coding. Or 5 MHz, so > the >>> transitions are at 10 MHz. I don't recall, or never knew. >> RS422 does not imply any encoding as such so it would be 10 MHz but >> naturally there is twice that many transitions, but it is the frequency >> of the signal you are interested in for this case. > > I know that RS422 is not the encoding. I cheated, and talked to the > relevant engineer. That is to cheat! :) > For digital signals (1PPS, various triggers), it's RS422 over 100 ohm > twinax (fancy shielded twisted pair). > > The 10 MHz sinewave is sent over a pair of 50 ohm coax links, with the > signals 180 degrees out of phase. This is acheived with a pair of hybrid > transformers which convert from one-cable to two-cable and then back to > one-cable, where all cables are 50 ohm coax. OUCH! The trouble with that arrangement is that the coax cables MUST be twisted or else H-fields will induce differential mode current. It will induce current into both directions which through the 180 degree will not cancel but add up. The 0/180 degree arrangement will save you from common mode problems. You would prefer a twisted cable over a twisted cable pair, as the later allows for installation procedure errors to have huge impact and the twisting properties will not be as good either and thus compromising the quality. A single ended coax is not as sensitive to H fields to induce diffrential currents, but can have some other problems. >>>>> I imagine that the shield is grounded at both ends, if only for >>>>> safety reasons. >>>> That is actually a very unsafe practice, unless there is another >>>> much thicker and reliable ground connection between the two domains. >>> There is a very heavy grounding grid, and such systems almost always >>> ground the (outer) shields at every connector. >> Which would imply that if the signal passes through a connector jack or >> through a wall, much of the current would be sent back to its EMF source > >> locally in the room. This does have its merits. > > Yes, but that isn't the reason. It's really a safety and EMC rationale. As suspected, but this is really just another of these EMC rationales. >>>> But you should never let the screen float in the far end, you should >>>> terminate it with a 10M resistor and a sparkgap in parallel to the >>>> local ground. >>>> >>>> The resistor takes care of static electricity and the sparkgap will >>>> do lightnings. >>> I've done such things, but with a 100 ohm resistor (and a safety > ground to >>> ensure that the voltage doesn't get too large. But this was >> a lab lashup. >> >> The trouble with 100 ohm is that still can be a little low in relation >> to ground loop impedances, it still allow some fair current to roll down > >> the cable. A capacitor in parallel would cut most of the transient >> energy straight through and allow for a higher resistive path for the >> low frequency energy. > > The ground grid impedance between any two points is well less than one > ohm, so 100 ohms will pretty much abolish all ground loops. I've used 10 > ohms in like labs, with success. I'll grant that this would not work with > long wires outside. Should be sufficient then. But remember that capacitive coupling helps you in the RF area and impulse protection. > By the way, I also finally talked to one of our most experienced EMI/EMC > engineers. He suggested using MIL-STD-461 test CS109, even though CS109 > was developed for enclosures. It turns out he was involved in developing > CS109 when he worked for the US Navy. Need to look it up. Never had to do any of the MIL-STD-461 stuff. Cheers, Magnus From magnus at rubidium.dyndns.org Sat Jan 10 10:31:28 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 10 Jan 2009 11:31:28 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: <496683F4.4000309@xtra.co.nz> References: <49666E64.9030207@rubidium.dyndns.org> <49667362.2010202@xtra.co.nz> <49667E14.3070801@rubidium.dyndns.org> <496683F4.4000309@xtra.co.nz> Message-ID: <49687900.10709@rubidium.dyndns.org> Bruce, >> Yes, but the bump comes from the increase gain around the resonance and >> spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure >> does not really comply here since they usually build on a simplified >> model of noise type (white noise - gaussian). A simple check in Gardiner >> provides both the generic integrating formula, simplified results and a >> graph showing the smae numbers that you give. >> > Whilst the phase noise of a sawtooth corrected M12+T GPS timing receiver > approximates white phase noise (at least for tau < 1 day), this may not > be so for the receiver used in the Thunderbolt. > The phase noise of the OCXO certainly cannot be accurately modeled as > white phase noise for large tau. As the PLL filters the noise of the OCXO and passes noise from the input side and the noise have several different components to it from either source. You can't really extrapolate direction the results of an asynchronous reciever such as the M12+T to that of a synchronous receiver such as the Thunderbolt. The time-solution of thunderbolt is used in replacement of the time-interval counter fluff slapped onto a PPS based receiver such as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable reference than the M12+T which allows for narrower filters in the sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can be configured for different uses, they are direct hints to what the tracking loops may do as it reduces the physical dynamics of position as well as inflicted G effects on the OCXO. With just two Thunderbolts and a reasonable TIC you can infact build a three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be able to measure the OCXO1-OCXO2. An interesting aspect of this is that when lockedup, the PPSes of the Thunderbolts will be confined into a rather small area. This arrangement will, as any other, give not the standalone OCXO noise when beeing steered, but it is not entierly lying for those longer taus. >> I rather beleive what ADEV, MDEV and TDEV experience in this context. >> >> > Yes measurements are the key but if one doesnt have a suitable > statistically independent low noise frequency reference it isnt possible > to optimise the loop parameters for an individual GPSDO. True. However, I think there is still some more theoretical work to be done to give us better tools. These does not remove the need for measurements and I have never been foolish enougth to beleive so, but it could guide us in the right direction for selecting and steering our parameters. >> We could go back to the real integration formula, adapt it to various >> powers of f^-n noises and analyse it for the same set of PLL loop >> filters as analysed by Gardiner. Similarly we could cook up a simulation >> and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth >> measures can be calculated alongside. >> >> I am somewhat surprised that you missed the opportunity to correct me as >> I was giving the incorrect value for damping factor of a critically >> damped system. It is the square root of 1/2 and not 2, thus 0.7071 is >> the appropriate damping factor for critically damped systems. >> >> > I had noted that your quoted damping factor was incorrect but I > suspected that you would realise that. > > Actually according to Gardener critical damping factor is 1 ( minimum > settling with no overshoot for a phase step). > However a damping factor of 0.7071 is widely used. It is interesting to clear up why this difference exists. Could be "critical" is judged different for different applications. >> I am somewhat surprised that when we have been discussing the bandwidth >> of the PLLs and considering OCXOs being running with fairly high drift >> rate we have been assuming second degree loops. This form of >> acceleration requires third degree responses for proper handling, as >> being well documented in literature such as Gardiner. Going for third >> degree response the bandwidth of the loop can be (at least more freely) >> disconnected from tracking requirements due to drift rate. >> > I only mentioned second order type II loops as the analysis is somewhat > simpler and there is no indication from the number of tuning parameters > for the Thunderbolt that a higher order loop is involved. My point was that regardless of implementation, second order type II loops seems to be the reference mark, which not necessarilly is a good one. Third order loops should be considered as it removes or reduces a type of problem and allows a more freer setting of parameters with less things to compromise between. When doing the loop in digital processing it is not that more expensive. There are re-tunable architectures which is being used in for instance GPS receivers which is not hard at all to use for both PI and PID controllers. Cheers, Magnus From bruce.griffiths at xtra.co.nz Sat Jan 10 12:37:32 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 11 Jan 2009 01:37:32 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: <49687900.10709@rubidium.dyndns.org> References: <49666E64.9030207@rubidium.dyndns.org> <49667362.2010202@xtra.co.nz> <49667E14.3070801@rubidium.dyndns.org> <496683F4.4000309@xtra.co.nz> <49687900.10709@rubidium.dyndns.org> Message-ID: <4968968C.3010107@xtra.co.nz> Hej Magnus Magnus Danielson wrote: > Bruce, > > >>> Yes, but the bump comes from the increase gain around the resonance and >>> spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure >>> does not really comply here since they usually build on a simplified >>> model of noise type (white noise - gaussian). A simple check in Gardiner >>> provides both the generic integrating formula, simplified results and a >>> graph showing the smae numbers that you give. >>> >>> >> Whilst the phase noise of a sawtooth corrected M12+T GPS timing receiver >> approximates white phase noise (at least for tau < 1 day), this may not >> be so for the receiver used in the Thunderbolt. >> The phase noise of the OCXO certainly cannot be accurately modeled as >> white phase noise for large tau. >> > > As the PLL filters the noise of the OCXO and passes noise from the input > side and the noise have several different components to it from either > source. > > You can't really extrapolate direction the results of an asynchronous > reciever such as the M12+T to that of a synchronous receiver such as the > Thunderbolt. The time-solution of thunderbolt is used in replacement of > the time-interval counter fluff slapped onto a PPS based receiver such > as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable > reference than the M12+T which allows for narrower filters in the > sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can > be configured for different uses, they are direct hints to what the > tracking loops may do as it reduces the physical dynamics of position as > well as inflicted G effects on the OCXO. > > I wasn't attempting to do so. However the phase noise of the GPS receiver will still dominate for short tau whilst that of the OCXO is dominant for longer tau. > With just two Thunderbolts and a reasonable TIC you can infact build a > three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the > thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be > able to measure the OCXO1-OCXO2. An interesting aspect of this is that > when lockedup, the PPSes of the Thunderbolts will be confined into a > rather small area. This arrangement will, as any other, give not the > standalone OCXO noise when beeing steered, but it is not entierly lying > for those longer taus. > > The 3 cornered hat technique only works well (even in the extended form where finite correlations between sources are included) when the noise of each of the 3 sources are comparable. That is this technique will only work well in the vicinity of the point where the GPS receiver and OCXO ADEVs crossover or equivalently near the drift corrected minimum of the ADEV as measured by the Thunderbolt when the OCXO is undisciplined. For shorter tau the GPS phase noise dominates. >>> I rather beleive what ADEV, MDEV and TDEV experience in this context. >>> >>> >>> >> Yes measurements are the key but if one doesnt have a suitable >> statistically independent low noise frequency reference it isnt possible >> to optimise the loop parameters for an individual GPSDO. >> > > True. However, I think there is still some more theoretical work to be > done to give us better tools. These does not remove the need for > measurements and I have never been foolish enougth to beleive so, but it > could guide us in the right direction for selecting and steering our > parameters. > > It would be helpful if the ADEV (and MDEV) plots for several Thunderbolts were plotted using the Thunderbolt's internal phase error measures obtained when the OCXO is undisciplined. This can easily be setup using the Trimble Thunderbolt Monitor program. >>> We could go back to the real integration formula, adapt it to various >>> powers of f^-n noises and analyse it for the same set of PLL loop >>> filters as analysed by Gardiner. Similarly we could cook up a simulation >>> and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth >>> measures can be calculated alongside. >>> >>> I am somewhat surprised that you missed the opportunity to correct me as >>> I was giving the incorrect value for damping factor of a critically >>> damped system. It is the square root of 1/2 and not 2, thus 0.7071 is >>> the appropriate damping factor for critically damped systems. >>> >>> >>> >> I had noted that your quoted damping factor was incorrect but I >> suspected that you would realise that. >> >> Actually according to Gardener critical damping factor is 1 ( minimum >> settling with no overshoot for a phase step). >> However a damping factor of 0.7071 is widely used. >> > > It is interesting to clear up why this difference exists. Could be > "critical" is judged different for different applications. > > The usual meaning of critical damping in a second order differential equation is for no overshoot to a step input. Thus critical probably isn't the appropriate term when optimising for other factors. Optimum damping for a particular criterion is perhaps better description. >>> I am somewhat surprised that when we have been discussing the bandwidth >>> of the PLLs and considering OCXOs being running with fairly high drift >>> rate we have been assuming second degree loops. This form of >>> acceleration requires third degree responses for proper handling, as >>> being well documented in literature such as Gardiner. Going for third >>> degree response the bandwidth of the loop can be (at least more freely) >>> disconnected from tracking requirements due to drift rate. >>> >>> >> I only mentioned second order type II loops as the analysis is somewhat >> simpler and there is no indication from the number of tuning parameters >> for the Thunderbolt that a higher order loop is involved. >> > > My point was that regardless of implementation, second order type II > loops seems to be the reference mark, which not necessarilly is a good > one. Third order loops should be considered as it removes or reduces a > type of problem and allows a more freer setting of parameters with less > things to compromise between. When doing the loop in digital processing > it is not that more expensive. There are re-tunable architectures which > is being used in for instance GPS receivers which is not hard at all to > use for both PI and PID controllers. > > Cheers, > Magnus > > In particular the ability of a third order loop to track linear frequency drift can be very useful. The last time I let my Thunderbolt OCXO free run there was a very strong quasi parabolic component to the phase drift as measured by the Thunderbolt itself. However, this was soon after I first powered it up, its drift may have settled down somewhat by now. Bruce From magnus at rubidium.dyndns.org Sat Jan 10 13:06:42 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 10 Jan 2009 14:06:42 +0100 Subject: [time-nuts] GPSDO TC In-Reply-To: <4968968C.3010107@xtra.co.nz> References: <49666E64.9030207@rubidium.dyndns.org> <49667362.2010202@xtra.co.nz> <49667E14.3070801@rubidium.dyndns.org> <496683F4.4000309@xtra.co.nz> <49687900.10709@rubidium.dyndns.org> <4968968C.3010107@xtra.co.nz> Message-ID: <49689D62.7000109@rubidium.dyndns.org> Hej Bruce, >> As the PLL filters the noise of the OCXO and passes noise from the input >> side and the noise have several different components to it from either >> source. >> >> You can't really extrapolate direction the results of an asynchronous >> reciever such as the M12+T to that of a synchronous receiver such as the >> Thunderbolt. The time-solution of thunderbolt is used in replacement of >> the time-interval counter fluff slapped onto a PPS based receiver such >> as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable >> reference than the M12+T which allows for narrower filters in the >> sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can >> be configured for different uses, they are direct hints to what the >> tracking loops may do as it reduces the physical dynamics of position as >> well as inflicted G effects on the OCXO. >> >> > I wasn't attempting to do so. > However the phase noise of the GPS receiver will still dominate for > short tau whilst that of the OCXO is dominant for longer tau. Agreed. I'm just trying to keep various error sources separate here. The truncation noise isn't white noise one should recall. >> With just two Thunderbolts and a reasonable TIC you can infact build a >> three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the >> thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be >> able to measure the OCXO1-OCXO2. An interesting aspect of this is that >> when lockedup, the PPSes of the Thunderbolts will be confined into a >> rather small area. This arrangement will, as any other, give not the >> standalone OCXO noise when beeing steered, but it is not entierly lying >> for those longer taus. >> >> > The 3 cornered hat technique only works well (even in the extended form > where finite correlations between sources are included) when the noise > of each of the 3 sources are comparable. > That is this technique will only work well in the vicinity of the point > where the GPS receiver and OCXO ADEVs crossover or equivalently near the > drift corrected minimum of the ADEV as measured by the Thunderbolt when > the OCXO is undisciplined. For shorter tau the GPS phase noise dominates. Yes. I think it would be usefull to provide confidence intervals etc. to get a better "feel" of how good the measure is. As a reference measurement the thunderbolts could be driven into holdover. I think the thunderbolts keep reporting timing errors. >> True. However, I think there is still some more theoretical work to be >> done to give us better tools. These does not remove the need for >> measurements and I have never been foolish enougth to beleive so, but it >> could guide us in the right direction for selecting and steering our >> parameters. >> >> > It would be helpful if the ADEV (and MDEV) plots for several > Thunderbolts were plotted using the Thunderbolt's internal phase error > measures obtained when the OCXO is undisciplined. > This can easily be setup using the Trimble Thunderbolt Monitor program. Indeed. We should recall that the PLL locking fades over from the OCXO to the GPS (as received) noise at about the BW frequency/tau of the PLL. Finding the optimum crossover properties involves both balancing PLL bandwidth and damping. >>> I had noted that your quoted damping factor was incorrect but I >>> suspected that you would realise that. >>> >>> Actually according to Gardener critical damping factor is 1 ( minimum >>> settling with no overshoot for a phase step). >>> However a damping factor of 0.7071 is widely used. >>> >> It is interesting to clear up why this difference exists. Could be >> "critical" is judged different for different applications. >> >> > The usual meaning of critical damping in a second order differential > equation is for no overshoot to a step input. > Thus critical probably isn't the appropriate term when optimising for > other factors. > Optimum damping for a particular criterion is perhaps better description. Precisely. Critical damping is just a handy reference along the line, but should not be incorrectly interprented as optimum in some generic sense, there is several forms of optimum for different tasks. I think best ADEV or best TDEV might be more relevant here. >> My point was that regardless of implementation, second order type II >> loops seems to be the reference mark, which not necessarilly is a good >> one. Third order loops should be considered as it removes or reduces a >> type of problem and allows a more freer setting of parameters with less >> things to compromise between. When doing the loop in digital processing >> it is not that more expensive. There are re-tunable architectures which >> is being used in for instance GPS receivers which is not hard at all to >> use for both PI and PID controllers. >> >> Cheers, >> Magnus >> >> > In particular the ability of a third order loop to track linear frequency drift can be very useful. Indeed, this is why I prefer them for this application. > The last time I let my Thunderbolt OCXO free run there was a very strong > quasi parabolic component to the phase drift as measured by the > Thunderbolt itself. > However, this was soon after I first powered it up, its drift may have > settled down somewhat by now. You would expect a strong drift at that time, owing to the OCXO heating up. Actual drift in oscillators isn't a static value but a rather different curve. Cheers, Magnus From joegwinn at comcast.net Sat Jan 10 15:22:54 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Sat, 10 Jan 2009 10:22:54 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops Message-ID: Magnus, At 10:31 AM +0000 1/10/09, time-nuts-request at febo.com wrote: > >Message: 5 >Date: Sat, 10 Jan 2009 11:06:39 +0100 >From: Magnus Danielson >Subject: Re: [time-nuts] Standards sought for immunity of shielded > cable links to power-frequency ground loops >To: Discussion of precise time and frequency measurement > > >Joseph, > >> time-nuts-bounces at febo.com wrote on 01/07/2009 10:47:46 PM: >> >>> Joseph, >>> >>>>>> Could be a differential TX and RX. I recall that they send a RS422 >>>> signal. >>>>> Depending on the speed, RS422 works fine with transformers. >>>> Yes. It would be 10 MHz or 20 MHz, depending on coding. Or 5 MHz, so >> the >>>> transitions are at 10 MHz. I don't recall, or never knew. >>> RS422 does not imply any encoding as such so it would be 10 MHz but >>> naturally there is twice that many transitions, but it is the frequency >>> of the signal you are interested in for this case. >> >> I know that RS422 is not the encoding. I cheated, and talked to the >> relevant engineer. > >That is to cheat! :) > >> For digital signals (1PPS, various triggers), it's RS422 over 100 ohm >> twinax (fancy shielded twisted pair). >> >> The 10 MHz sinewave is sent over a pair of 50 ohm coax links, with the >> signals 180 degrees out of phase. This is acheived with a pair of hybrid > > transformers which convert from one-cable to two-cable and then back to >> one-cable, where all cables are 50 ohm coax. > >OUCH! The trouble with that arrangement is that the coax cables MUST be >twisted or else H-fields will induce differential mode current. It will >induce current into both directions which through the 180 degree will >not cancel but add up. The 0/180 degree arrangement will save you from >common mode problems. You would prefer a twisted cable over a twisted >cable pair, as the later allows for installation procedure errors to >have huge impact and the twisting properties will not be as good either >and thus compromising the quality. A single ended coax is not as >sensitive to H fields to induce diffrential currents, but can have some >other problems. You are right about the twisting. The cables are close and parallel, and ground offsets are the big problem, versus magnetic fields. My worry was that the ground currents might be enough to saturate the tiny ferrite cores in the hybrid transformers. The engineer's reaction to this was on the following day to say that if this turns out to be a problem, he will add DC blocks. This would have to be the kind that blocks both center and shield paths. The problem is that the radar and the ship are not yet built, so we cannot yet make tests. > >>>> But you should never let the screen float in the far end, you should >>>>> terminate it with a 10M resistor and a sparkgap in parallel to the >>>>> local ground. >>>>> >>>>> The resistor takes care of static electricity and the sparkgap will >>>>> do lightnings. >>>> I've done such things, but with a 100 ohm resistor (and a safety >> ground to >>>> ensure that the voltage doesn't get too large. But this was >>> a lab lashup. >>> >>> The trouble with 100 ohm is that still can be a little low in relation > >> to ground loop impedances, it still allow some fair current to roll down > >> the cable. A capacitor in parallel would cut most of the transient >>> energy straight through and allow for a higher resistive path for the >>> low frequency energy. >> >> The ground grid impedance between any two points is well less than one >> ohm, so 100 ohms will pretty much abolish all ground loops. I've used 10 >> ohms in like labs, with success. I'll grant that this would not work with >> long wires outside. > >Should be sufficient then. But remember that capacitive coupling helps >you in the RF area and impulse protection. True. > > By the way, I also finally talked to one of our most experienced EMI/EMC >> engineers. He suggested using MIL-STD-461 test CS109, even though CS109 > > was developed for enclosures. It turns out he was involved in developing >> CS109 when he worked for the US Navy. > >Need to look it up. Never had to do any of the MIL-STD-461 stuff. It's available for free on the web. Joe From magnus at rubidium.dyndns.org Sat Jan 10 18:02:09 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 10 Jan 2009 19:02:09 +0100 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <4968E2A1.3080309@rubidium.dyndns.org> Joe, >>> For digital signals (1PPS, various triggers), it's RS422 over 100 ohm >>> twinax (fancy shielded twisted pair). >>> >>> The 10 MHz sinewave is sent over a pair of 50 ohm coax links, with the >>> signals 180 degrees out of phase. This is acheived with a pair of hybrid >> > transformers which convert from one-cable to two-cable and then back to >>> one-cable, where all cables are 50 ohm coax. >> OUCH! The trouble with that arrangement is that the coax cables MUST be >> twisted or else H-fields will induce differential mode current. It will >> induce current into both directions which through the 180 degree will >> not cancel but add up. The 0/180 degree arrangement will save you from >> common mode problems. You would prefer a twisted cable over a twisted >> cable pair, as the later allows for installation procedure errors to >> have huge impact and the twisting properties will not be as good either >> and thus compromising the quality. A single ended coax is not as >> sensitive to H fields to induce diffrential currents, but can have some >> other problems. > > You are right about the twisting. The cables are close and parallel, > and ground offsets are the big problem, versus magnetic fields. I just want you to end up having that trouble instead. I think you should consider a shielded twisted pair instead. Use the transformer to go between 50 Ohm and 100-110 Ohm while also getting the common mode isolation. A double-transformer approach can be used in which the launch/receive-transformer has a center tap on the "inside" which is wired to local ground (needs to be very low impedance). This improves capacitive isolation for common mode currents. The inner transformers do impedance matching. This is really an alternative to getting isolation transformers, it might even be cheaper. Dual-shielded isolation transformers is better thought, as capacitive coupling as spread out over the coil is always terminated to each side own shield which reduces common-mode to diffrential mode conversion. > My worry was that the ground currents might be enough to saturate the > tiny ferrite cores in the hybrid transformers. The engineer's > reaction to this was on the following day to say that if this turns > out to be a problem, he will add DC blocks. This would have to be > the kind that blocks both center and shield paths. I have a bit hard to realize how the common mode ground current would saturate the hybrid transformers unless the current is so high that the asymmetry in the transformers helps. Some form of DC blocker or LF current limiting may be wise thought. > The problem is that the radar and the ship are not yet built, so we > cannot yet make tests. So much better. You have a chance to get things right before it is too late and too expensive. I am sure we can send a sub to sink it late if needed. >>>> energy straight through and allow for a higher resistive path for the >>>> low frequency energy. >>> The ground grid impedance between any two points is well less than one >>> ohm, so 100 ohms will pretty much abolish all ground loops. I've used 10 >>> ohms in like labs, with success. I'll grant that this would not work with >>> long wires outside. >> Should be sufficient then. But remember that capacitive coupling helps >> you in the RF area and impulse protection. > > True. The reason I keep mentioning it is since that it is easy to focus and make a design "optimum" for one case and forgetting about other aspects. Signal integrity, safety and EMC needs too be considered at the same time. >> > By the way, I also finally talked to one of our most experienced EMI/EMC >>> engineers. He suggested using MIL-STD-461 test CS109, even though CS109 >> > was developed for enclosures. It turns out he was involved in developing >>> CS109 when he worked for the US Navy. >> Need to look it up. Never had to do any of the MIL-STD-461 stuff. > > It's available for free on the web. > Another site which can't keep their certs up-to-date. By looking at it, it seems reasonably to use that or some suitable variant. Notice how the 10 MHz input/out wires is not included so some adaptation would be required. Essentially one where the 10 MHz generator is floating through isolation transformer and the current is induced on the generator ground. Cheers, Magnus From david.partridge at dsl.pipex.com Sat Jan 10 18:13:56 2009 From: david.partridge at dsl.pipex.com (David C. Partridge) Date: Sat, 10 Jan 2009 18:13:56 -0000 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops In-Reply-To: References: Message-ID: <06F60AB40CB240399194AB54692545A1@APOLLO> Get 'em to use twin-ax (twisted pair inside screen) like the IBM AS/400 terminals (5250?) send differential signal down the cable. Dave -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Joe Gwinn Sent: 10 January 2009 15:23 To: time-nuts at febo.com Subject: Re: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops Magnus, At 10:31 AM +0000 1/10/09, time-nuts-request at febo.com wrote: > >Message: 5 >Date: Sat, 10 Jan 2009 11:06:39 +0100 >From: Magnus Danielson >Subject: Re: [time-nuts] Standards sought for immunity of shielded > cable links to power-frequency ground loops >To: Discussion of precise time and frequency measurement > > >Joseph, > >> time-nuts-bounces at febo.com wrote on 01/07/2009 10:47:46 PM: >> >>> Joseph, >>> >>>>>> Could be a differential TX and RX. I recall that they send a >>>>>> RS422 >>>> signal. >>>>> Depending on the speed, RS422 works fine with transformers. >>>> Yes. It would be 10 MHz or 20 MHz, depending on coding. Or 5 >>>> MHz, so >> the >>>> transitions are at 10 MHz. I don't recall, or never knew. >>> RS422 does not imply any encoding as such so it would be 10 MHz but >>> naturally there is twice that many transitions, but it is the >>> frequency of the signal you are interested in for this case. >> >> I know that RS422 is not the encoding. I cheated, and talked to the >> relevant engineer. > >That is to cheat! :) > >> For digital signals (1PPS, various triggers), it's RS422 over 100 >> ohm twinax (fancy shielded twisted pair). >> >> The 10 MHz sinewave is sent over a pair of 50 ohm coax links, with >> the signals 180 degrees out of phase. This is acheived with a pair >> of hybrid > > transformers which convert from one-cable to two-cable and then > back to >> one-cable, where all cables are 50 ohm coax. > >OUCH! The trouble with that arrangement is that the coax cables MUST be >twisted or else H-fields will induce differential mode current. It will >induce current into both directions which through the 180 degree will >not cancel but add up. The 0/180 degree arrangement will save you from >common mode problems. You would prefer a twisted cable over a twisted >cable pair, as the later allows for installation procedure errors to >have huge impact and the twisting properties will not be as good either >and thus compromising the quality. A single ended coax is not as >sensitive to H fields to induce diffrential currents, but can have some >other problems. You are right about the twisting. The cables are close and parallel, and ground offsets are the big problem, versus magnetic fields. My worry was that the ground currents might be enough to saturate the tiny ferrite cores in the hybrid transformers. The engineer's reaction to this was on the following day to say that if this turns out to be a problem, he will add DC blocks. This would have to be the kind that blocks both center and shield paths. The problem is that the radar and the ship are not yet built, so we cannot yet make tests. > >>>> But you should never let the screen float in the far end, you should >>>>> terminate it with a 10M resistor and a sparkgap in parallel to the >>>>> local ground. >>>>> >>>>> The resistor takes care of static electricity and the sparkgap will >>>>> do lightnings. >>>> I've done such things, but with a 100 ohm resistor (and a safety >> ground to >>>> ensure that the voltage doesn't get too large. But this was >>> a lab lashup. >>> >>> The trouble with 100 ohm is that still can be a little low in relation > >> to ground loop impedances, it still allow some fair current to roll down > >> the cable. A capacitor in parallel would cut most of the transient >>> energy straight through and allow for a higher resistive path for the >>> low frequency energy. >> >> The ground grid impedance between any two points is well less than one >> ohm, so 100 ohms will pretty much abolish all ground loops. I've used 10 >> ohms in like labs, with success. I'll grant that this would not work with >> long wires outside. > >Should be sufficient then. But remember that capacitive coupling helps >you in the RF area and impulse protection. True. > > By the way, I also finally talked to one of our most experienced EMI/EMC >> engineers. He suggested using MIL-STD-461 test CS109, even though CS109 > > was developed for enclosures. It turns out he was involved in developing >> CS109 when he worked for the US Navy. > >Need to look it up. Never had to do any of the MIL-STD-461 stuff. It's available for free on the web. Joe _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From EWKehren at aol.com Sat Jan 10 18:32:39 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Sat, 10 Jan 2009 13:32:39 EST Subject: [time-nuts] Frequency Electronics FE-5602B Message-ID: Does any one have pin out and or specs on the Frequency Electronics FE-5062B Rubidium Standard. Any help would be greatly appreciated. Thanks Bert Kehren WB5MZJ **************New year...new news. Be the first to know what is making headlines. (http://www.aol.com/?ncid=emlcntaolcom00000026) From billj at ieee.org Sat Jan 10 18:45:08 2009 From: billj at ieee.org (Bill Janssen) Date: Sat, 10 Jan 2009 10:45:08 -0800 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <017001c972bf$27d99260$6401a8c0@WSOffice> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net><4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com><49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com><00a801c97295$715c7cb0$6401a8c0@WSOffice> <4967C05F.8030907@xtra.co.nz> <017001c972bf$27d99260$6401a8c0@WSOffice> Message-ID: <4968ECB4.8050802@ieee.org> WarrenS wrote: >> Bruce said: >> The critical requirement is that the 2 standards being compared are statistically independent. >> Comparing a pair of Thunderbolts GPSDOs with similar time constants and >> damping will give optimistic results for Tau comparable with or greater than the loop time constant. >> Its is even better is to use 3 or more similar standards simultaneously >> logging phase differences between the various pairs (0.5*N(N-1) pairs for N standards). >> It is then possible to obtain estimates for ADEV, MDEV etc for each standard. >> > > The optimistic results at and above the loop time constant, that results even when 3 or more units are used, > is because the noise is then mostly due to the GPS signal itself and NOT the local oscillators in the GPSDO. > In effect you are then using the same 1PPS signal into each unit, and any common noise on the > GPS 1PPS signal will cancel and not be seen. > So I think what Bruce is saying is that you can not (or is it should not?) use the GPS signal to > measure the GPS's noise. > But the point is, if you want to compare your GPSDO with different settings, or compare it to > another OCXO, It can be done this way, if you do not have a better ref to use. > You could then add the noise of the GPS nose above the control loop time to your > optimistic results if you want true results at high Tau values. > > Also note that having the GPS noise cancle is not necessary a bad thing, It can be a good thing > especially if the GPS noise is not what it is that you want to measure. > > >> Like all digital phase detectors its best to avoid, if possible, the nonlinearity inherent at the ends of the range. >> > > Using a phase detector near its end point (or at its crossover point if there is any deadband) > is something that needs to be avoided. > The two basic standard ways to insure that just the center of the phase detector's range is use: > 1) Divide the signals down just enough before sending them to the phase detector so that > the end points is not an issue. This works when both signals are from devices that are > locked to a common signal such as the GPS. > > 2) When one of signals is from a non locked source such as a OCXO whose phase can drift > any amount overtime, One of ways to limit phase detector issues, and use just the very accurate zero phase point, is to use the Phase detector's output to lock the OCXO in a fast control loop and then by knowing the gain of the EFC input, the filtered EFC voltage can be use as freq drift information to find the ADEV's. > > WarrenS > > *************: What I am doing to ovoid the "end of range" problem is; First I divide the signal by two to get a 50% duty cycle. Then when the phase difference gets to 10% or 90% of the full scale value I switch the phase detector (or counter) to respond to to the opposite zero crossing. I keep track of those switches in software. I use a computer to control things and to keep a log of the phase difference. Bill K7NOM From james.p.lux at jpl.nasa.gov Sat Jan 10 19:00:47 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Sat, 10 Jan 2009 11:00:47 -0800 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops Message-ID: Or 1553, for that matter -----Original Message----- From: "David C. Partridge" Get 'em to use twin-ax (twisted pair inside screen) like the IBM AS/400 terminals (5250?) send differential signal down the cable. Dave From bruce.griffiths at xtra.co.nz Sat Jan 10 21:27:18 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 11 Jan 2009 10:27:18 +1300 Subject: [time-nuts] GPSDO TC In-Reply-To: <49689D62.7000109@rubidium.dyndns.org> References: <49666E64.9030207@rubidium.dyndns.org> <49667362.2010202@xtra.co.nz> <49667E14.3070801@rubidium.dyndns.org> <496683F4.4000309@xtra.co.nz> <49687900.10709@rubidium.dyndns.org> <4968968C.3010107@xtra.co.nz> <49689D62.7000109@rubidium.dyndns.org> Message-ID: <496912B6.4080007@xtra.co.nz> Magnus Danielson wrote: > Hej Bruce, > > >>> As the PLL filters the noise of the OCXO and passes noise from the input >>> side and the noise have several different components to it from either >>> source. >>> >>> You can't really extrapolate direction the results of an asynchronous >>> reciever such as the M12+T to that of a synchronous receiver such as the >>> Thunderbolt. The time-solution of thunderbolt is used in replacement of >>> the time-interval counter fluff slapped onto a PPS based receiver such >>> as the M12+T. Also, the Thunderbolt enjoys a much quiter and stable >>> reference than the M12+T which allows for narrower filters in the >>> sat-tracking as the phasenoise is lower. Notice how the Thunderbolt can >>> be configured for different uses, they are direct hints to what the >>> tracking loops may do as it reduces the physical dynamics of position as >>> well as inflicted G effects on the OCXO. >>> >>> >>> >> I wasn't attempting to do so. >> However the phase noise of the GPS receiver will still dominate for >> short tau whilst that of the OCXO is dominant for longer tau. >> > > Agreed. I'm just trying to keep various error sources separate here. > > The truncation noise isn't white noise one should recall. > The GPS receiver's noise appears to be at least approximately white phase noise noise after sawtooth correction. > >>> With just two Thunderbolts and a reasonable TIC you can infact build a >>> three-cornered hat. You have three clocks: GPS, OCXO1 and OCXO2 and the >>> thunderbolts will measure GPS-OCXO1 and GPS-OCXO2 and the TIC will be >>> able to measure the OCXO1-OCXO2. An interesting aspect of this is that >>> when lockedup, the PPSes of the Thunderbolts will be confined into a >>> rather small area. This arrangement will, as any other, give not the >>> standalone OCXO noise when beeing steered, but it is not entierly lying >>> for those longer taus. >>> >>> >>> >> The 3 cornered hat technique only works well (even in the extended form >> where finite correlations between sources are included) when the noise >> of each of the 3 sources are comparable. >> That is this technique will only work well in the vicinity of the point >> where the GPS receiver and OCXO ADEVs crossover or equivalently near the >> drift corrected minimum of the ADEV as measured by the Thunderbolt when >> the OCXO is undisciplined. For shorter tau the GPS phase noise dominates. >> > > Yes. I think it would be usefull to provide confidence intervals etc. to > get a better "feel" of how good the measure is. > > As a reference measurement the thunderbolts could be driven into > holdover. I think the thunderbolts keep reporting timing errors. > > Yes, the Thunderbolt keeps measuring phase and frequency errors when the OCXO is unlocked. >>> True. However, I think there is still some more theoretical work to be >>> done to give us better tools. These does not remove the need for >>> measurements and I have never been foolish enougth to beleive so, but it >>> could guide us in the right direction for selecting and steering our >>> parameters. >>> >>> >>> >> It would be helpful if the ADEV (and MDEV) plots for several >> Thunderbolts were plotted using the Thunderbolt's internal phase error >> measures obtained when the OCXO is undisciplined. >> This can easily be setup using the Trimble Thunderbolt Monitor program. >> > > Indeed. We should recall that the PLL locking fades over from the OCXO > to the GPS (as received) noise at about the BW frequency/tau of the PLL. > > Finding the optimum crossover properties involves both balancing PLL > bandwidth and damping. > > I suspect that when more divergent processes than flicker phase noise dominate more damping is optimum. >>>> I had noted that your quoted damping factor was incorrect but I >>>> suspected that you would realise that. >>>> >>>> Actually according to Gardener critical damping factor is 1 ( minimum >>>> settling with no overshoot for a phase step). >>>> However a damping factor of 0.7071 is widely used. >>>> >>>> >>> It is interesting to clear up why this difference exists. Could be >>> "critical" is judged different for different applications. >>> >>> >>> >> The usual meaning of critical damping in a second order differential >> equation is for no overshoot to a step input. >> Thus critical probably isn't the appropriate term when optimising for >> other factors. >> Optimum damping for a particular criterion is perhaps better description. >> > > Precisely. Critical damping is just a handy reference along the line, > but should not be incorrectly interprented as optimum in some generic > sense, there is several forms of optimum for different tasks. > > I think best ADEV or best TDEV might be more relevant here. > > >>> My point was that regardless of implementation, second order type II >>> loops seems to be the reference mark, which not necessarilly is a good >>> one. Third order loops should be considered as it removes or reduces a >>> type of problem and allows a more freer setting of parameters with less >>> things to compromise between. When doing the loop in digital processing >>> it is not that more expensive. There are re-tunable architectures which >>> is being used in for instance GPS receivers which is not hard at all to >>> use for both PI and PID controllers. >>> >>> Cheers, >>> Magnus >>> >>> >>> >> In particular the ability of a third order loop to track linear frequency drift can be very useful. >> > > Indeed, this is why I prefer them for this application. > > >> The last time I let my Thunderbolt OCXO free run there was a very strong >> quasi parabolic component to the phase drift as measured by the >> Thunderbolt itself. >> However, this was soon after I first powered it up, its drift may have >> settled down somewhat by now. >> > > You would expect a strong drift at that time, owing to the OCXO heating > up. Actual drift in oscillators isn't a static value but a rather > different curve. > > It had had plenty of time to warm up (several days). I'll try repeating the exercise again but my antenna location is far from optimum so obtaining long runs without loss of SVs isnt possible. > Cheers, > Magnus > > > Bruce From joegwinn at comcast.net Sat Jan 10 21:27:50 2009 From: joegwinn at comcast.net (Joe Gwinn) Date: Sat, 10 Jan 2009 16:27:50 -0500 Subject: [time-nuts] Standards sought for immunity of shielded cable links to power-frequency ground loops Message-ID: Magnus, At 6:02 PM +0000 1/10/09, time-nuts-request at febo.com wrote: > >Message: 4 >Date: Sat, 10 Jan 2009 19:02:09 +0100 >From: Magnus Danielson >Subject: Re: [time-nuts] Standards sought for immunity of shielded > cable links to power-frequency ground loops >To: Discussion of precise time and frequency measurement > >Joe, > >>>> For digital signals (1PPS, various triggers), it's RS422 over 100 ohm >>>> twinax (fancy shielded twisted pair). >>>> >>>> The 10 MHz sinewave is sent over a pair of 50 ohm coax links, with the >>>> signals 180 degrees out of phase. This is acheived with a pair of hybrid >>> > transformers which convert from one-cable to two-cable and then back to >>>> one-cable, where all cables are 50 ohm coax. > >> >>> OUCH! The trouble with that arrangement is that the coax cables MUST be >>> twisted or else H-fields will induce differential mode current. It will >>> induce current into both directions which through the 180 degree will >>> not cancel but add up. The 0/180 degree arrangement will save you from >>> common mode problems. You would prefer a twisted cable over a twisted >>> cable pair, as the later allows for installation procedure errors to > >> have huge impact and the twisting properties will not be as good either >>> and thus compromising the quality. A single ended coax is not as >>> sensitive to H fields to induce diffrential currents, but can have some >>> other problems. >> >> You are right about the twisting. The cables are close and parallel, >> and ground offsets are the big problem, versus magnetic fields. > >I just want you to end up having that trouble instead. I think you >should consider a shielded twisted pair instead. Use the transformer to >go between 50 Ohm and 100-110 Ohm while also getting the common mode >isolation. A double-transformer approach can be used in which the >launch/receive-transformer has a center tap on the "inside" which is >wired to local ground (needs to be very low impedance). This improves >capacitive isolation for common mode currents. The inner transformers do >impedance matching. This is really an alternative to getting isolation >transformers, it might even be cheaper. Dual-shielded isolation >transformers is better thought, as capacitive coupling as spread out >over the coil is always terminated to each side own shield which reduces >common-mode to diffrential mode conversion. The engineer wanted to use catalog components, which means connectorized hybrid transformers, probably from Minicircuits or the like. He did use real twinax elsewhere, and the hum pickup issue has occurred to him. The connectors are Type N, and the cable will be some kind of robust double-shielded flexible type. He may already be twisting the two cables, which are about 30 meters long. > > My worry was that the ground currents might be enough to saturate the >> tiny ferrite cores in the hybrid transformers. The engineer's >> reaction to this was on the following day to say that if this turns >> out to be a problem, he will add DC blocks. This would have to be >> the kind that blocks both center and shield paths. > >I have a bit hard [time] to realize how the common mode ground current would >saturate the hybrid transformers unless the current is so high that the >asymmetry in the transformers helps. Some form of DC blocker or LF >current limiting may be wise thought. The 60 Hz limit in MIL-STD-461 CS109 is one amp (120 dB over one microamp). The EMI guy said that this limit was arrived at for submarines in the 1970s, and the currents were primarily due to charging currents from capacitor-input power supplies, and the like. What saves us with the hybrids is that while the cores are small, the windings might have five turns, so it will take a very substantial current to have any effect, and the winding will blow out first. > > The problem is that the radar and the ship are not yet built, so we > > cannot yet make tests. > >So much better. You have a chance to get things right before it is too >late and too expensive. Yes and no. The drawings are done long before, and change is painful. But necessary. >I am sure we can send a sub to sink it late if needed. I'm not sure that solves the problem, but it certainly eliminates the problem. > >>>> energy straight through and allow for a higher resistive path for the >>>>> low frequency energy. >>>> The ground grid impedance between any two points is well less than one >>>> ohm, so 100 ohms will pretty much abolish all ground loops. I've used 10 >>>> ohms in like labs, with success. I'll grant that this would >>>>not work with >>>> long wires outside. >>> Should be sufficient then. But remember that capacitive coupling helps >>> you in the RF area and impulse protection. >> >> True. > >The reason I keep mentioning it is since that it is easy to focus and >make a design "optimum" for one case and forgetting about other aspects. >Signal integrity, safety and EMC needs too be considered at the same time. Can't say that I much worry about such things in lab setups. As I said, the 100 ohm resistor works fine, but there are lots of places I would not do it that way. > >> > By the way, I also finally talked to one of our most >experienced EMI/EMC >>>> engineers. He suggested using MIL-STD-461 test CS109, even though CS109 >>> > was developed for enclosures. It turns out he was involved in >>>developing >>>> CS109 when he worked for the US Navy. >>> Need to look it up. Never had to do any of the MIL-STD-461 stuff. >> >> It's available for free on the web. > > > >Another site which can't keep their certs up-to-date. I got the same message, but the certificate was still current (just looked - expires in June 2009). I suspect that the real problem is that US DoD has its own certificate authority, and does not use Verisign et al, and the browser maker forgot to include DoD. >By looking at it, it seems reasonably to use that or some suitable >variant. Notice how the 10 MHz input/out wires is not included so some >adaptation would be required. Essentially one where the 10 MHz generator >is floating through isolation transformer and the current is induced on >the generator ground. Or just use a heavy filament transformer driven by a variac to pull up to ten amps through the shield. What then floats is the secondary of the transformer. If it's necessary to isolate the oscillator or distribution amplifier, use a DC block that breaks both center and shield with capacitors. Or use an RF isolation transformer. The oscillator output is already isolated from chassis ground, now that I think of it. But the distribution amplifier outputs are not isolated. Joe From bruce.griffiths at xtra.co.nz Sat Jan 10 21:35:34 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 11 Jan 2009 10:35:34 +1300 Subject: [time-nuts] ADEV test setup [was GPSDO TC & Damping] In-Reply-To: <4968ECB4.8050802@ieee.org> References: <206858EE-9D41-485B-8ED6-A6C39B90A285@hughes.net><4966EC51.5050300@xtra.co.nz><1231b6a80901090010w6e04aba6yf6cafd64d148c75b@mail.gmail.com><49672098.3000303@xtra.co.nz> <496725C6.4000307@xtra.co.nz> <1231b6a80901090318r278ab009s719d0e0b72fe8064@mail.gmail.com><00a801c97295$715c7cb0$6401a8c0@WSOffice> <4967C05F.8030907@xtra.co.nz> <017001c972bf$27d99260$6401a8c0@WSOffice> <4968ECB4.8050802@ieee.org> Message-ID: <496914A6.50702@xtra.co.nz> Bill Janssen wrote: > WarrenS wrote: > >>> Bruce said: >>> The critical requirement is that the 2 standards being compared are statistically independent. >>> Comparing a pair of Thunderbolts GPSDOs with similar time constants and >>> damping will give optimistic results for Tau comparable with or greater than the loop time constant. >>> Its is even better is to use 3 or more similar standards simultaneously >>> logging phase differences between the various pairs (0.5*N(N-1) pairs for N standards). >>> It is then possible to obtain estimates for ADEV, MDEV etc for each standard. >>> >>> >> The optimistic results at and above the loop time constant, that results even when 3 or more units are used, >> is because the noise is then mostly due to the GPS signal itself and NOT the local oscillators in the GPSDO. >> In effect you are then using the same 1PPS signal into each unit, and any common noise on the >> GPS 1PPS signal will cancel and not be seen. >> So I think what Bruce is saying is that you can not (or is it should not?) use the GPS signal to >> measure the GPS's noise. >> But the point is, if you want to compare your GPSDO with different settings, or compare it to >> another OCXO, It can be done this way, if you do not have a better ref to use. >> You could then add the noise of the GPS nose above the control loop time to your >> optimistic results if you want true results at high Tau values. >> >> Also note that having the GPS noise cancle is not necessary a bad thing, It can be a good thing >> especially if the GPS noise is not what it is that you want to measure. >> >> >> >>> Like all digital phase detectors its best to avoid, if possible, the nonlinearity inherent at the ends of the range. >>> >>> >> Using a phase detector near its end point (or at its crossover point if there is any deadband) >> is something that needs to be avoided. >> The two basic standard ways to insure that just the center of the phase detector's range is use: >> 1) Divide the signals down just enough before sending them to the phase detector so that >> the end points is not an issue. This works when both signals are from devices that are >> locked to a common signal such as the GPS. >> >> 2) When one of signals is from a non locked source such as a OCXO whose phase can drift >> any amount overtime, One of ways to limit phase detector issues, and use just the very accurate zero phase point, is to use the Phase detector's output to lock the OCXO in a fast control loop and then by knowing the gain of the EFC input, the filtered EFC voltage can be use as freq drift information to find the ADEV's. >> >> WarrenS >> >> *************: >> > What I am doing to ovoid the "end of range" problem is; > First I divide the signal by two to get a 50% duty cycle. Then when the > phase difference gets to > 10% or 90% of the full scale value I switch the phase detector (or > counter) to respond to > to the opposite zero crossing. I keep track of those switches in > software. I use a computer to control things and to keep a log of the > phase difference. > > Bill K7NOM > > > Bill At this level of precision the waveform duty cycles are never precisely 50% so some correction for this also needs to be made. Bruce From holrum at hotmail.com Sat Jan 10 23:25:25 2009 From: holrum at hotmail.com (Mark Sims) Date: Sat, 10 Jan 2009 23:25:25 +0000 Subject: [time-nuts] ADEV values of Thunderbolt PPS and OSC error estimates Message-ID: Here is two sets of ADEV/OADEV data generated from the PPS and OSC error estimates produced by the Thunderbolt. There is a set from a run where the oscillator was disciplined by GPS and a set where the oscillator was undisciplined. The PPS numbers are probably the best ones to use. Trimble's documentation on exactly what the OSC error values are is rather poor and I am just guessing what they mean and how to convert them into something that can be fed into the ADEV code.## PPS OADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 1.4140e-006 (n=21998)# 2 tau 1.2248e-006 (n=21996)# 5 tau 4.8993e-007 (n=21990)# 10 tau 2.4503e-007 (n=21980)# 20 tau 1.2258e-007 (n=21960)# 50 tau 4.9104e-008 (n=21900)# 100 tau 2.4600e-008 (n=21800)# 200 tau 1.2359e-008 (n=21600)# 500 tau 5.0137e-009 (n=21000)# 1000 tau 2.5688e-009 (n=20000)# 2000 tau 1.2359e-009 (n=18000)# 5000 tau 2.7077e-010 (n=12000)# 10000 tau 5.4669e-013 (n=2000)## PPS ADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 1.4140e-006 (n=21998)# 2 tau 1.2235e-006 (n=10998)# 5 tau 7.7367e-007 (n=4398)# 10 tau 5.4722e-007 (n=2198)# 20 tau 2.6497e-010 (n=1098)# 50 tau 9.8233e-011 (n=438)# 100 tau 5.6151e-011 (n=218)# 200 tau 3.9024e-011 (n=108)# 500 tau 1.4521e-011 (n=42)# 1000 tau 6.3933e-012 (n=20)# 2000 tau 4.1976e-012 (n=9)### OSC OADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 2.2969e-007 (n=21998)# 2 tau 1.6255e-007 (n=21996)# 5 tau 1.0351e-007 (n=21990)# 10 tau 7.4928e-008 (n=21980)# 20 tau 5.7408e-008 (n=21960)# 50 tau 4.6799e-008 (n=21900)# 100 tau 3.4445e-008 (n=21800)# 200 tau 1.7323e-008 (n=21600)# 500 tau 7.0268e-009 (n=21000)# 1000 tau 3.6004e-009 (n=20000)# 2000 tau 1.7322e-009 (n=18000)# 5000 tau 3.7961e-010 (n=12000)# 10000 tau 4.1514e-013 (n=2000)## OSC ADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 2.2969e-007 (n=21998)# 2 tau 1.6263e-007 (n=10998)# 5 tau 1.0336e-007 (n=4398)# 10 tau 7.4706e-008 (n=2198)# 20 tau 5.7006e-008 (n=1098)# 50 tau 4.5848e-008 (n=438)# 100 tau 3.9821e-008 (n=218)# 200 tau 2.8396e-008 (n=108)# 500 tau 1.0394e-010 (n=42)# 1000 tau 5.2360e-012 (n=20)# 2000 tau 2.4501e-012 (n=9)## PPS OADEV over 22000 points - sample period=1 secs - undisciplined # 1 tau 7.5658e-010 (n=21998)# 2 tau 5.0045e-010 (n=21996)# 5 tau 2.8665e-010 (n=21990)# 10 tau 1.8127e-010 (n=21980)# 20 tau 1.1774e-010 (n=21960)# 50 tau 6.8339e-011 (n=21900)# 100 tau 4.6184e-011 (n=21800)# 200 tau 4.1377e-011 (n=21600)# 500 tau 7.4192e-011 (n=21000)# 1000 tau 1.0220e-010 (n=20000)# 2000 tau 1.1842e-010 (n=18000)# 5000 tau 1.2073e-010 (n=12000)# 10000 tau 3.7124e-011 (n=2000)## PPS ADEV over 22000 points - sample period=1 secs - undisciplined# 1 tau 7.5658e-010 (n=21998)# 2 tau 5.1193e-010 (n=10998)# 5 tau 2.9314e-010 (n=4398)# 10 tau 1.8065e-010 (n=2198)# 20 tau 1.1872e-010 (n=1098)# 50 tau 7.2017e-011 (n=438)# 100 tau 4.6293e-011 (n=218)# 200 tau 3.9846e-011 (n=108)# 500 tau 7.2822e-011 (n=42)# 1000 tau 1.0120e-010 (n=20)# 2000 tau 1.1514e-010 (n=9)## OSC OADEV over 22000 points - sample period=1 secs - undisciplined # 1 tau 3.9644e-009 (n=21998)# 2 tau 1.9671e-009 (n=21996)# 5 tau 7.8264e-010 (n=21990)# 10 tau 3.9313e-010 (n=21980)# 20 tau 1.9801e-010 (n=21960)# 50 tau 7.9931e-011 (n=21900)# 100 tau 4.1369e-011 (n=21800)# 200 tau 2.5506e-011 (n=21600)# 500 tau 2.2498e-011 (n=21000)# 1000 tau 2.0910e-011 (n=20000)# 2000 tau 1.2765e-011 (n=18000)# 5000 tau 7.0420e-012 (n=12000)# 10000 tau 1.5081e-012 (n=2000)## OSC ADEV over 22000 points - sample period=1 secs - undisciplined # 1 tau 3.9644e-009 (n=21998)# 2 tau 1.9375e-009 (n=10998)# 5 tau 7.9203e-010 (n=4398)# 10 tau 3.8195e-010 (n=2198)# 20 tau 1.8606e-010 (n=1098)# 50 tau 7.7008e-011 (n=438)# 100 tau 3.5703e-011 (n=218)# 200 tau 2.0731e-011 (n=108)# 500 tau 2.1042e-011 (n=42)# 1000 tau 1.9238e-011 (n=20)# 2000 tau 1.4089e-011 (n=9) _________________________________________________________________ Windows Live? Hotmail?: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 From holrum at hotmail.com Sat Jan 10 23:29:30 2009 From: holrum at hotmail.com (Mark Sims) Date: Sat, 10 Jan 2009 23:29:30 +0000 Subject: [time-nuts] ADEV values of Thunderbolt PPS and OSC error estimates In-Reply-To: References: Message-ID: Another try to see if I can get some stinkin' CR/LF spacing out of hotmail this week..... > > Here is two sets of ADEV/OADEV data generated from the PPS and OSC error estimates produced by the Thunderbolt. There is a set from a run where the oscillator was disciplined by GPS and a set where the oscillator was undisciplined. The PPS numbers are probably the best ones to use. Trimble's documentation on exactly what the OSC error values are is rather poor and I am just guessing what they mean and how to convert them into something that can be fed into the ADEV code. > > > # > # PPS OADEV over 22000 points - sample period=1 secs - disciplined > # 1 tau 1.4140e-006 (n=21998) > # 2 tau 1.2248e-006 (n=21996) > # 5 tau 4.8993e-007 (n=21990) > # 10 tau 2.4503e-007 (n=21980) > # 20 tau 1.2258e-007 (n=21960) > # 50 tau 4.9104e-008 (n=21900) > # 100 tau 2.4600e-008 (n=21800) > # 200 tau 1.2359e-008 (n=21600) > # 500 tau 5.0137e-009 (n=21000) > # 1000 tau 2.5688e-009 (n=20000) > # 2000 tau 1.2359e-009 (n=18000) > # 5000 tau 2.7077e-010 (n=12000) > # 10000 tau 5.4669e-013 (n=2000) > # > # PPS ADEV over 22000 points - sample period=1 secs - disciplined > # 1 tau 1.4140e-006 (n=21998) > # 2 tau 1.2235e-006 (n=10998) > # 5 tau 7.7367e-007 (n=4398) > # 10 tau 5.4722e-007 (n=2198) > # 20 tau 2.6497e-010 (n=1098) > # 50 tau 9.8233e-011 (n=438) > # 100 tau 5.6151e-011 (n=218) > # 200 tau 3.9024e-011 (n=108) > # 500 tau 1.4521e-011 (n=42) > # 1000 tau 6.3933e-012 (n=20) > # 2000 tau 4.1976e-012 (n=9) > # > > > > # > # OSC OADEV over 22000 points - sample period=1 secs - disciplined > # 1 tau 2.2969e-007 (n=21998) > # 2 tau 1.6255e-007 (n=21996) > # 5 tau 1.0351e-007 (n=21990) > # 10 tau 7.4928e-008 (n=21980) > # 20 tau 5.7408e-008 (n=21960) > # 50 tau 4.6799e-008 (n=21900) > # 100 tau 3.4445e-008 (n=21800) > # 200 tau 1.7323e-008 (n=21600) > # 500 tau 7.0268e-009 (n=21000) > # 1000 tau 3.6004e-009 (n=20000) > # 2000 tau 1.7322e-009 (n=18000) > # 5000 tau 3.7961e-010 (n=12000) > # 10000 tau 4.1514e-013 (n=2000) > # > # OSC ADEV over 22000 points - sample period=1 secs - disciplined > # 1 tau 2.2969e-007 (n=21998) > # 2 tau 1.6263e-007 (n=10998) > # 5 tau 1.0336e-007 (n=4398) > # 10 tau 7.4706e-008 (n=2198) > # 20 tau 5.7006e-008 (n=1098) > # 50 tau 4.5848e-008 (n=438) > # 100 tau 3.9821e-008 (n=218) > # 200 tau 2.8396e-008 (n=108) > # 500 tau 1.0394e-010 (n=42) > # 1000 tau 5.2360e-012 (n=20) > # 2000 tau 2.4501e-012 (n=9) > > > # > # PPS OADEV over 22000 points - sample period=1 secs - undisciplined > # 1 tau 7.5658e-010 (n=21998) > # 2 tau 5.0045e-010 (n=21996) > # 5 tau 2.8665e-010 (n=21990) > # 10 tau 1.8127e-010 (n=21980) > # 20 tau 1.1774e-010 (n=21960) > # 50 tau 6.8339e-011 (n=21900) > # 100 tau 4.6184e-011 (n=21800) > # 200 tau 4.1377e-011 (n=21600) > # 500 tau 7.4192e-011 (n=21000) > # 1000 tau 1.0220e-010 (n=20000) > # 2000 tau 1.1842e-010 (n=18000) > # 5000 tau 1.2073e-010 (n=12000) > # 10000 tau 3.7124e-011 (n=2000) > # > # PPS ADEV over 22000 points - sample period=1 secs - undisciplined > # 1 tau 7.5658e-010 (n=21998) > # 2 tau 5.1193e-010 (n=10998) > # 5 tau 2.9314e-010 (n=4398) > # 10 tau 1.8065e-010 (n=2198) > # 20 tau 1.1872e-010 (n=1098) > # 50 tau 7.2017e-011 (n=438) > # 100 tau 4.6293e-011 (n=218) > # 200 tau 3.9846e-011 (n=108) > # 500 tau 7.2822e-011 (n=42) > # 1000 tau 1.0120e-010 (n=20) > # 2000 tau 1.1514e-010 (n=9) > # > > > > # OSC OADEV over 22000 points - sample period=1 secs - undisciplined > # 1 tau 3.9644e-009 (n=21998) > # 2 tau 1.9671e-009 (n=21996) > # 5 tau 7.8264e-010 (n=21990) > # 10 tau 3.9313e-010 (n=21980) > # 20 tau 1.9801e-010 (n=21960) > # 50 tau 7.9931e-011 (n=21900) > # 100 tau 4.1369e-011 (n=21800) > # 200 tau 2.5506e-011 (n=21600) > # 500 tau 2.2498e-011 (n=21000) > # 1000 tau 2.0910e-011 (n=20000) > # 2000 tau 1.2765e-011 (n=18000) > # 5000 tau 7.0420e-012 (n=12000) > # 10000 tau 1.5081e-012 (n=2000) > # > # OSC ADEV over 22000 points - sample period=1 secs - undisciplined > # 1 tau 3.9644e-009 (n=21998) > # 2 tau 1.9375e-009 (n=10998) > # 5 tau 7.9203e-010 (n=4398) > # 10 tau 3.8195e-010 (n=2198) > # 20 tau 1.8606e-010 (n=1098) > # 50 tau 7.7008e-011 (n=438) > # 100 tau 3.5703e-011 (n=218) > # 200 tau 2.0731e-011 (n=108) > # 500 tau 2.1042e-011 (n=42) > # 1000 tau 1.9238e-011 (n=20) > # 2000 tau 1.4089e-011 (n=9) > > _________________________________________________________________ > Windows Live? Hotmail?: Chat. Store. Share. Do more with mail. > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From holrum at hotmail.com Sun Jan 11 03:02:14 2009 From: holrum at hotmail.com (Mark Sims) Date: Sun, 11 Jan 2009 03:02:14 +0000 Subject: [time-nuts] ADEV values of Thunderbolt PPS and OSC error estimates In-Reply-To: References: Message-ID: I just noticed that the ADEV values that I posted for the disciplined oscillator were for a unit fresh off the boat from China. It had not been used for several years. It had just completed the self survey right before the run/log was started. Note the rather bad short term ADEVS that just started to get real at the 10000 second area. The undisciplined values were from this same unit after a couple weeks of continuous operation. I am doing another disciplined run on this unit and will post the results. _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From n3toy at yahoo.com Sun Jan 11 16:23:43 2009 From: n3toy at yahoo.com (James R. Gorr) Date: Sun, 11 Jan 2009 08:23:43 -0800 (PST) Subject: [time-nuts] perl and GPS time In-Reply-To: Message-ID: <109657.52830.qm@web54109.mail.re2.yahoo.com> It is not Slashdot, but leapsecond.com got a mention on perlmonks.com: http://perlmonks.com/?node_id=735502 Jamie From holrum at hotmail.com Sun Jan 11 18:40:46 2009 From: holrum at hotmail.com (Mark Sims) Date: Sun, 11 Jan 2009 18:40:46 +0000 Subject: [time-nuts] ADEV values of Thunderbolt PPS and OSC error estimates In-Reply-To: References: Message-ID: Here is the updated Thunderbolt disciplined ADEV data from the same oscillator after it had a couple of weeks to stabilize (the undisciplined data is the same as previously posted). The previously reported disciplined data was from a unit fresh out of two years of storage. Again, these numbers were generated from the Thunderbolt's own reported PPS and OSC errors and not from data recorded by an external counter/reference. The Thunderbolt's reported data does seem to compare quite well to data collected from an external counter/cesium reference (particularly the PPS data). # # PPS OADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 4.7501e-010 (n=21998) # 2 tau 3.3692e-010 (n=21996) # 5 tau 2.2547e-010 (n=21990) # 10 tau 1.8164e-010 (n=21980) # 20 tau 1.3945e-010 (n=21960) # 50 tau 8.7328e-011 (n=21900) # 100 tau 4.9754e-011 (n=21800) # 200 tau 2.6789e-011 (n=21600) # 500 tau 1.0024e-011 (n=21000) # 1000 tau 5.2111e-012 (n=20000) # 2000 tau 2.5297e-012 (n=18000) # 5000 tau 1.0739e-012 (n=12000) # 10000 tau 5.5327e-013 (n=2000) # # PPS ADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 4.7501e-010 (n=21998) # 2 tau 3.3687e-010 (n=10998) # 5 tau 2.2648e-010 (n=4398) # 10 tau 1.8564e-010 (n=2198) # 20 tau 1.3779e-010 (n=1098) # 50 tau 9.0472e-011 (n=438) # 100 tau 4.9060e-011 (n=218) # 200 tau 2.7924e-011 (n=108) # 500 tau 1.1878e-011 (n=42) # 1000 tau 6.1683e-012 (n=20) # 2000 tau 2.0124e-012 (n=9) # # OSC OADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 3.5312e-009 (n=21998) # 2 tau 1.7710e-009 (n=21996) # 5 tau 7.2871e-010 (n=21990) # 10 tau 3.7145e-010 (n=21980) # 20 tau 2.0222e-010 (n=21960) # 50 tau 9.3183e-011 (n=21900) # 100 tau 4.9708e-011 (n=21800) # 200 tau 2.5971e-011 (n=21600) # 500 tau 9.9754e-012 (n=21000) # 1000 tau 5.1255e-012 (n=20000) # 2000 tau 2.4660e-012 (n=18000) # 5000 tau 1.0015e-012 (n=12000) # 10000 tau 5.4528e-013 (n=2000) # # OSC ADEV over 22000 points - sample period=1 secs - disciplined # 1 tau 3.5312e-009 (n=21998) # 2 tau 1.8273e-009 (n=10998) # 5 tau 7.1742e-010 (n=4398) # 10 tau 3.8528e-010 (n=2198) # 20 tau 1.9948e-010 (n=1098) # 50 tau 9.8947e-011 (n=438) # 100 tau 5.1349e-011 (n=218) # 200 tau 2.6844e-011 (n=108) # 500 tau 1.2198e-011 (n=42) # 1000 tau 6.1199e-012 (n=20) # 2000 tau 1.9290e-012 (n=9) # # PPS OADEV over 22000 points - sample period=1 secs - undisciplined # 1 tau 7.5658e-010 (n=21998) # 2 tau 5.0045e-010 (n=21996) # 5 tau 2.8665e-010 (n=21990) # 10 tau 1.8127e-010 (n=21980) # 20 tau 1.1774e-010 (n=21960) # 50 tau 6.8339e-011 (n=21900) # 100 tau 4.6184e-011 (n=21800) # 200 tau 4.1377e-011 (n=21600) # 500 tau 7.4192e-011 (n=21000) # 1000 tau 1.0220e-010 (n=20000) # 2000 tau 1.1842e-010 (n=18000) # 5000 tau 1.2073e-010 (n=12000) # 10000 tau 3.7124e-011 (n=2000) # # PPS ADEV over 22000 points - sample period=1 secs - undisciplined # 1 tau 7.5658e-010 (n=21998) # 2 tau 5.1193e-010 (n=10998) # 5 tau 2.9314e-010 (n=4398) # 10 tau 1.8065e-010 (n=2198) # 20 tau 1.1872e-010 (n=1098) # 50 tau 7.2017e-011 (n=438) # 100 tau 4.6293e-011 (n=218) # 200 tau 3.9846e-011 (n=108) # 500 tau 7.2822e-011 (n=42) # 1000 tau 1.0120e-010 (n=20) # 2000 tau 1.1514e-010 (n=9) # # OSC OADEV over 22000 points - sample period=1 secs - undisciplined # 1 tau 3.9644e-009 (n=21998) # 2 tau 1.9671e-009 (n=21996) # 5 tau 7.8264e-010 (n=21990) # 10 tau 3.9313e-010 (n=21980) # 20 tau 1.9801e-010 (n=21960) # 50 tau 7.9931e-011 (n=21900) # 100 tau 4.1369e-011 (n=21800) # 200 tau 2.5506e-011 (n=21600) # 500 tau 2.2498e-011 (n=21000) # 1000 tau 2.0910e-011 (n=20000) # 2000 tau 1.2765e-011 (n=18000) # 5000 tau 7.0420e-012 (n=12000) # 10000 tau 1.5081e-012 (n=2000) # # OSC ADEV over 22000 points - sample period=1 secs - undisciplined # 1 tau 3.9644e-009 (n=21998) # 2 tau 1.9375e-009 (n=10998) # 5 tau 7.9203e-010 (n=4398) # 10 tau 3.8195e-010 (n=2198) # 20 tau 1.8606e-010 (n=1098) # 50 tau 7.7008e-011 (n=438) # 100 tau 3.5703e-011 (n=218) # 200 tau 2.0731e-011 (n=108) # 500 tau 2.1042e-011 (n=42) # 1000 tau 1.9238e-011 (n=20) # 2000 tau 1.4089e-011 (n=9) _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From shields at msrl.com Sun Jan 11 19:23:48 2009 From: shields at msrl.com (Michael Shields) Date: Sun, 11 Jan 2009 11:23:48 -0800 Subject: [time-nuts] good book on the history of calendars? In-Reply-To: <01e701c96ee1$43f77e80$cbe67b80$@com> References: <01e701c96ee1$43f77e80$cbe67b80$@com> Message-ID: <9091c6490901111123n3ef00171l82cbd58cab0cdabd@mail.gmail.com> On Sun, Jan 4, 2009 at 6:56 PM, christopher hoover wrote: > > Can anyone recommend a good book on the development of calendars, ideally > from Caesar on? Duncan Steel's "Marking Time" is good for this, although it only covers the Western calendar. From stephan at rrsg.ee.uct.ac.za Sun Jan 11 21:12:20 2009 From: stephan at rrsg.ee.uct.ac.za (Stephan Sandenbergh) Date: Sun, 11 Jan 2009 23:12:20 +0200 Subject: [time-nuts] Typical local oscillator specs for an analogue TV tuner Message-ID: Hi, Has any one got an idea what the typical phase noise specs are for the LO inside an ordinary analogue TV tuner is? Regards, Stephan. From die at dieconsulting.com Sun Jan 11 22:28:34 2009 From: die at dieconsulting.com (David I. Emery) Date: Sun, 11 Jan 2009 17:28:34 -0500 Subject: [time-nuts] Typical local oscillator specs for an analogue TV tuner In-Reply-To: References: Message-ID: <20090111222834.GA19903@pig.dieconsulting.com> On Sun, Jan 11, 2009 at 11:12:20PM +0200, Stephan Sandenbergh wrote: > Hi, > > Has any one got an idea what the typical phase noise specs are for the LO > inside an ordinary analogue TV tuner is? Many many generations here... most all current ones are PLL synthesized but obviously many variants of free running and varactor tuned exist in older TVs. Current QAM-256 cable ready tuners in sets with digital ATSC/QAM capability have to have respectable phase noise - I beleive there is a spec on what is recommended/expected but it is distinctly better than NTSC analog ever required. DOCSIS cable specs cover this... Synthesized tuners for analog NTSC TV didn't have to be very good and many obviously weren't... as low cost was paramount... -- Dave Emery N1PRE/AE, die at dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." From brooke at pacific.net Mon Jan 12 00:57:27 2009 From: brooke at pacific.net (Brooke Clarke) Date: Sun, 11 Jan 2009 16:57:27 -0800 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> Message-ID: <496A9577.6050807@pacific.net> Hi: I've received the 60 kHz version of the C-max CMMR-6P LF time code receiver module. Digi-Key ( 561-1014-ND) has these improperly listed in their catalog and the CMMR-6P data sheet has a typo that may have mislead Digi-Key. The CMMR-6P-ff is an evaluation board for the CME6005 and has the parts needed to make it work. In addition the kit includes a 60 x 10 mm loop stick that has a resonating cap attached at the antenna. Photo and more info at: http://www.prc68.com/I/Loop.shtml#CMMR6P60 Have Fun, Brooke Clarke http://www.prc68.com From glennmaillist at bellsouth.net Mon Jan 12 04:13:19 2009 From: glennmaillist at bellsouth.net (Glenn Little WB4UIV) Date: Sun, 11 Jan 2009 23:13:19 -0500 Subject: [time-nuts] LPRO-101 Message-ID: <6.2.3.4.2.20090111230717.05f3aeb0@mail.bellsouth.net> I have a LPRO-101. Before I power it up, I have been advised to use a heatsink. How large of a heatsink do I need? I found an extruded heatsink in the junk box. This heatsink has fins about 0.50 inches high. The width is 2.375 inches wide. It is 8.125 inches long. I plan to cut this heatsink in half giving me two 4.0 inch pieced. I plan to bolt each piece to the bottom of the LPRO-101, using the six mounting holes, three per heatsink. Would this be sufficient heatsink? Thanks in advance. 73 Glenn WB4UIV From bruce.griffiths at xtra.co.nz Mon Jan 12 04:50:53 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 12 Jan 2009 17:50:53 +1300 Subject: [time-nuts] LPRO-101 In-Reply-To: <6.2.3.4.2.20090111230717.05f3aeb0@mail.bellsouth.net> References: <6.2.3.4.2.20090111230717.05f3aeb0@mail.bellsouth.net> Message-ID: <496ACC2D.5000403@xtra.co.nz> Glenn Little WB4UIV wrote: > I have a LPRO-101. Before I power it up, I have been advised to use a heatsink. > How large of a heatsink do I need? > I found an extruded heatsink in the junk box. > This heatsink has fins about 0.50 inches high. > The width is 2.375 inches wide. > It is 8.125 inches long. > I plan to cut this heatsink in half giving me two 4.0 inch pieced. > I plan to bolt each piece to the bottom of the LPRO-101, using the > six mounting holes, three per heatsink. > Would this be sufficient heatsink? > > Thanks in advance. > 73 > Glenn > WB4UIV > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Glenn The manual recommends a heat sink with a thermal resistance of 2C/watt or less for ambient temperatures up to 50C. Your proposed heatsink may be a little small unless you bow it. Fin orientation is very important for an non blown heatsink. If you just attach the heatsink to the base with the fins pointing down the thermal resistance will be increased significantly over the normal orientation with convection cooling. Bruce From jltran at worldnet.att.net Mon Jan 12 04:57:35 2009 From: jltran at worldnet.att.net (J. L. Trantham) Date: Sun, 11 Jan 2009 22:57:35 -0600 Subject: [time-nuts] LPRO-101 In-Reply-To: <6.2.3.4.2.20090111230717.05f3aeb0@mail.bellsouth.net> Message-ID: <6ECAF7D6C8834194B4917348F3E07D65@S0028384766> I have several of the units and made up a cable to attach 24V power, a voltmeter, and the 10 MHz output. I watched the 10 MHz on a scope against a Thunderbolt as an X-Y display. I did this without using a heat sink and it took about 5 minutes or less for the BITE to indicate lock (going from +5V to 0, as I recall) and the lissajous figure to approximate a circle. I am sure you do not want to use the unit in service without a heat sink but I have been told that it is ok to do a quick power up and test without a heat sink and I have done it several times. The specs for the heat sink requirements are in the LPRO manual. Joe -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Glenn Little WB4UIV Sent: Sunday, January 11, 2009 10:13 PM To: Time-Nuts list Subject: [time-nuts] LPRO-101 I have a LPRO-101. Before I power it up, I have been advised to use a heatsink. How large of a heatsink do I need? I found an extruded heatsink in the junk box. This heatsink has fins about 0.50 inches high. The width is 2.375 inches wide. It is 8.125 inches long. I plan to cut this heatsink in half giving me two 4.0 inch pieced. I plan to bolt each piece to the bottom of the LPRO-101, using the six mounting holes, three per heatsink. Would this be sufficient heatsink? Thanks in advance. 73 Glenn WB4UIV _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From glennmaillist at bellsouth.net Mon Jan 12 05:10:03 2009 From: glennmaillist at bellsouth.net (Glenn Little WB4UIV) Date: Mon, 12 Jan 2009 00:10:03 -0500 Subject: [time-nuts] LPRO-101 In-Reply-To: <496ACC2D.5000403@xtra.co.nz> References: <6.2.3.4.2.20090111230717.05f3aeb0@mail.bellsouth.net> <496ACC2D.5000403@xtra.co.nz> Message-ID: <6.2.3.4.2.20090112000650.05eccd80@mail.bellsouth.net> My heatsink appears to have a thermal resistance of about 3 degrees C per watt. It is similar to Thermalloy 60975. I will dig deeper into the junk box and see if I can find a heatsink with larger fins. Thanks for the guidance. 73 Glenn WB4UIV At 11:50 PM 1/11/2009, you wrote: >Glenn Little WB4UIV wrote: > > I have a LPRO-101. Before I power it up, I have been advised to > use a heatsink. > > How large of a heatsink do I need? > > I found an extruded heatsink in the junk box. > > This heatsink has fins about 0.50 inches high. > > The width is 2.375 inches wide. > > It is 8.125 inches long. > > I plan to cut this heatsink in half giving me two 4.0 inch pieced. > > I plan to bolt each piece to the bottom of the LPRO-101, using the > > six mounting holes, three per heatsink. > > Would this be sufficient heatsink? > > > > Thanks in advance. > > 73 > > Glenn > > WB4UIV > > > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > > >Glenn > >The manual recommends a heat sink with a thermal resistance of 2C/watt >or less for ambient temperatures up to 50C. >Your proposed heatsink may be a little small unless you bow it. > >Fin orientation is very important for an non blown heatsink. >If you just attach the heatsink to the base with the fins pointing down >the thermal resistance will be increased significantly over the normal >orientation with convection cooling. > >Bruce > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From smace at intt.net Mon Jan 12 05:31:27 2009 From: smace at intt.net (Scott Mace) Date: Sun, 11 Jan 2009 23:31:27 -0600 Subject: [time-nuts] LPRO-101 In-Reply-To: <6.2.3.4.2.20090111230717.05f3aeb0@mail.bellsouth.net> References: <6.2.3.4.2.20090111230717.05f3aeb0@mail.bellsouth.net> Message-ID: <496AD5AF.7030008@intt.net> I've seen Datum clocks of various sorts with these just mounted to the chassis, no special heatsink, especially the 1RU units. Scott On 01/11/2009 10:13 PM, Glenn Little WB4UIV wrote: > I have a LPRO-101. Before I power it up, I have been advised to use a heatsink. > How large of a heatsink do I need? > I found an extruded heatsink in the junk box. > This heatsink has fins about 0.50 inches high. > The width is 2.375 inches wide. > It is 8.125 inches long. > I plan to cut this heatsink in half giving me two 4.0 inch pieced. > I plan to bolt each piece to the bottom of the LPRO-101, using the > six mounting holes, three per heatsink. > Would this be sufficient heatsink? > > Thanks in advance. > 73 > Glenn > WB4UIV > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From hmurray at megapathdsl.net Mon Jan 12 05:39:24 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Sun, 11 Jan 2009 21:39:24 -0800 Subject: [time-nuts] LPRO-101 In-Reply-To: Message from Glenn Little WB4UIV of "Mon, 12 Jan 2009 00:10:03 EST." <6.2.3.4.2.20090112000650.05eccd80@mail.bellsouth.net> Message-ID: <20090112053926.18B16BCD8@ip-64-139-1-69.sjc.megapath.net> > My heatsink appears to have a thermal resistance of about 3 degrees C > per watt. It is similar to Thermalloy 60975. I'll bet it's good enough, at least to get started. Mine is just barely warm. I have a large heat sink, but it doesn't have much in the way of fins. If you have a large chunk of 1/8 in aluminum, that might be worth a try. Say 3x the area of the bottom. >The manual recommends a heat sink with a thermal resistance of 2C/watt >or less for ambient temperatures up to 50C. What's your ambient? You can get slightly better cooling if you turn it on its side/end, or lift the fins off the surface with a couple of spacers so the air can get in there better. -- These are my opinions, not necessarily my employer's. I hate spam. From sar10538 at gmail.com Mon Jan 12 06:00:20 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Mon, 12 Jan 2009 19:00:20 +1300 Subject: [time-nuts] LPRO-101 In-Reply-To: <20090112053926.18B16BCD8@ip-64-139-1-69.sjc.megapath.net> References: <6.2.3.4.2.20090112000650.05eccd80@mail.bellsouth.net> <20090112053926.18B16BCD8@ip-64-139-1-69.sjc.megapath.net> Message-ID: <1231b6a80901112200r340dc200t25653966e56f3fc6@mail.gmail.com> 2009/1/12 Hal Murray : > You can get slightly better cooling if you turn it on its side/end, or lift > the fins off the surface with a couple of spacers so the air can get in there > better. Lifting the "fins" (heatsink) off the device will completely defeat the purpose of them as the heat needs to conduct from the base of the unit and onto the the heatsink for it to be of any worth. Use of thermal paste will help and lapping both surfaces to a flat mirror surface can help immensely. Make sure when mounting the device that the fins are arranged so that air can move vertically over them, IE. put it on it's side with the fins running vertically. 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From wb6bnq at cox.net Mon Jan 12 06:11:51 2009 From: wb6bnq at cox.net (WB6BNQ) Date: Sun, 11 Jan 2009 22:11:51 -0800 Subject: [time-nuts] LPRO-101 References: <6.2.3.4.2.20090112000650.05eccd80@mail.bellsouth.net> <20090112053926.18B16BCD8@ip-64-139-1-69.sjc.megapath.net> <1231b6a80901112200r340dc200t25653966e56f3fc6@mail.gmail.com> Message-ID: <496ADF27.F0BF9C5C@cox.net> Steve, I am pretty sure he meant lifting off of the surface that the unit would be sitting on; i.e., the bench. Bill....WB6BNQ Steve Rooke wrote: > 2009/1/12 Hal Murray : > > > You can get slightly better cooling if you turn it on its side/end, or lift > > the fins off the surface with a couple of spacers so the air can get in there > > better. > > Lifting the "fins" (heatsink) off the device will completely defeat > the purpose of them as the heat needs to conduct from the base of the > unit and onto the the heatsink for it to be of any worth. Use of > thermal paste will help and lapping both surfaces to a flat mirror > surface can help immensely. Make sure when mounting the device that > the fins are arranged so that air can move vertically over them, IE. > put it on it's side with the fins running vertically. > > 73, Steve > -- > Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW > Omnium finis imminet > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From sar10538 at gmail.com Mon Jan 12 06:17:10 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Mon, 12 Jan 2009 19:17:10 +1300 Subject: [time-nuts] LPRO-101 In-Reply-To: <496ADF27.F0BF9C5C@cox.net> References: <6.2.3.4.2.20090112000650.05eccd80@mail.bellsouth.net> <20090112053926.18B16BCD8@ip-64-139-1-69.sjc.megapath.net> <1231b6a80901112200r340dc200t25653966e56f3fc6@mail.gmail.com> <496ADF27.F0BF9C5C@cox.net> Message-ID: <1231b6a80901112217m5cca26d7tc2ba0c34228d0324@mail.gmail.com> 2009/1/12 WB6BNQ : > Steve, > > I am pretty sure he meant lifting off of the surface that the unit would be sitting > on; i.e., the bench. Sorry, my bad. > Steve Rooke wrote: > >> 2009/1/12 Hal Murray : >> >> > You can get slightly better cooling if you turn it on its side/end, or lift >> > the fins off the surface with a couple of spacers so the air can get in there >> > better. >> >> Lifting the "fins" (heatsink) off the device will completely defeat >> the purpose of them as the heat needs to conduct from the base of the >> unit and onto the the heatsink for it to be of any worth. Use of >> thermal paste will help and lapping both surfaces to a flat mirror >> surface can help immensely. Make sure when mounting the device that >> the fins are arranged so that air can move vertically over them, IE. >> put it on it's side with the fins running vertically. >> >> 73, Steve >> -- >> Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW >> Omnium finis imminet >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From mpb45 at clanbaker.org Mon Jan 12 07:07:49 2009 From: mpb45 at clanbaker.org (Michael Baker) Date: Mon, 12 Jan 2009 02:07:49 -0500 Subject: [time-nuts] LPRO-101 Heatsinking Message-ID: <496AEC45.1020402@clanbaker.org> Hello, Timenutters-- I only have experience with four different LPRO-101 units, but with respect to heatsinking, all 4 behaved identically during my testing of them. It appears that the LPRO-101 units do not require much heatsinking. I experimented with a variety of heatsinks and discovered that just bolting them down to a 1/8" thick flat sheet of aluminum roughly 8" x 10" (no fins, just a flat sheet) kept the case of the unit and the aluminum sheet below 105 deg F. That is relatively quite cool as far as electronic circuitry is concerned-- only slightly warm to the touch. The 4 units I tested were powered by a regulated 24VDC supply and the aluminum sheet was kept vertical and had good air flow around it. I also experimented with a heat sink that is very nearly the same size as the base plate of the LPRO units but only has ten 1/2" tall fins that are quite wide spaced on it. With that particular very minimal heatsink the highest temp reached after 4 hours was only 97 deg F. I put a teeny 12 volt CPU fan about 2" from the fins and ran it on 6 volts DC to keep the blade speed waaaaaaay down (and essentially silent). After two hours had elapsed, the heat sink and case were still only ever so slightly above room temperature. Bottom line seems to be that the LPRO units must have at least some minimal heatsinking but they do not require much. The four units I tested came to me with their base plates covered with a very thin layer of some sort of a pale green heat transfer material so I did not need to apply any of the typical messy white "moose-poop" zinc-oxide and silicone grease heat transfer paste. Mike Baker WA4HFR Gainesville (Micanopy) Florida --------------------------------------- From namichie at gmail.com Mon Jan 12 08:20:45 2009 From: namichie at gmail.com (Neville Michie) Date: Mon, 12 Jan 2009 19:20:45 +1100 Subject: [time-nuts] LPRO-101 Heatsinking In-Reply-To: <496AEC45.1020402@clanbaker.org> References: <496AEC45.1020402@clanbaker.org> Message-ID: <737D54D8-271D-4D6D-B643-905E6820D2E7@gmail.com> Hi, The LPRO is shown to run down to 18 volt supply which reduces the power dissipation, see the graph in the manual. Like Mike I put one on to a heatsink and used a tiny under-run 12V fan to cool it. I placed a thermistor on the heat sink and controlled the fan to keep the heat sink to about 37C. I insulated the assembly so it can handle low temperatures. It hold this within +or- 0.05 degree, which is a tremendous assist to the non-ovened XO. It also reduces the power demand to about 7 or 8 watts. There is a small burden on the MTBF specs, but in my book quite acceptable. When I finish building some more gear I will get the improved performance data, cheers, Neville Michie On 12/01/2009, at 6:07 PM, Michael Baker wrote: > Hello, Timenutters-- > > I only have experience with four different LPRO-101 > units, but with respect to heatsinking, all 4 behaved > identically during my testing of them. > > It appears that the LPRO-101 units do not require > much heatsinking. I experimented with a variety > of heatsinks and discovered that just bolting them > down to a 1/8" thick flat sheet of aluminum roughly > 8" x 10" (no fins, just a flat sheet) kept the > case of the unit and the aluminum sheet below > 105 deg F. That is relatively quite cool as far > as electronic circuitry is concerned-- only > slightly warm to the touch. > > The 4 units I tested were powered by a regulated > 24VDC supply and the aluminum sheet was kept vertical > and had good air flow around it. > > I also experimented with a heat sink that is very > nearly the same size as the base plate of the LPRO > units but only has ten 1/2" tall fins that are > quite wide spaced on it. With that particular > very minimal heatsink the highest temp reached after > 4 hours was only 97 deg F. > > I put a teeny 12 volt CPU fan about 2" from the fins and > ran it on 6 volts DC to keep the blade speed waaaaaaay > down (and essentially silent). After two hours had > elapsed, the heat sink and case were still only > ever so slightly above room temperature. > > Bottom line seems to be that the LPRO units must have > at least some minimal heatsinking but they do not > require much. The four units I tested came to me > with their base plates covered with a very thin layer > of some sort of a pale green heat transfer material > so I did not need to apply any of the typical > messy white "moose-poop" zinc-oxide and silicone grease > heat transfer paste. > > Mike Baker > WA4HFR > Gainesville (Micanopy) Florida > --------------------------------------- > > > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ > time-nuts > and follow the instructions there. From didier at cox.net Tue Jan 13 01:03:05 2009 From: didier at cox.net (Didier) Date: Mon, 12 Jan 2009 19:03:05 -0600 Subject: [time-nuts] LPRO-101 Heatsinking In-Reply-To: <737D54D8-271D-4D6D-B643-905E6820D2E7@gmail.com> References: <496AEC45.1020402@clanbaker.org> <737D54D8-271D-4D6D-B643-905E6820D2E7@gmail.com> Message-ID: I run mine with a 20V laptop power brick and it runs quite cool, just warm to the touch with a heatsink, resting flat on a table with no forced air flow. Even after a couple of hours, the LPRO was just warm. I have not checked spurs (I expect the switcher to produce some, even though it is FCC approved), but it would be easy to make a power supply filter, and as soon as I get around to it, that will be next on my ToDo list. The thermistor/fan controller is a good idea, it can't hurt the long term stability to regulate the temperature. I sense another project coming up, as soon as I have finished integrating the Thunderbolt with a distribution amplifier and my GPS Monitor: http://www.ko4bb.com/Timing/Distribution_Amp/ Didier > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Neville Michie > Sent: Monday, January 12, 2009 2:21 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] LPRO-101 Heatsinking > > Hi, > The LPRO is shown to run down to 18 volt supply which reduces > the power dissipation, see the graph in the manual. > Like Mike I put one on to a heatsink and used a tiny > under-run 12V fan to cool it. > I placed a thermistor on the heat sink and controlled the fan > to keep the heat sink to about 37C. > I insulated the assembly so it can handle low temperatures. > It hold this within +or- 0.05 degree, which is a tremendous > assist to the non-ovened XO. > It also reduces the power demand to about 7 or 8 watts. > There is a small burden on the MTBF specs, but in my book > quite acceptable. > When I finish building some more gear I will get the improved > performance data, cheers, Neville Michie > From ch at murgatroid.com Tue Jan 13 03:57:13 2009 From: ch at murgatroid.com (christopher hoover) Date: Mon, 12 Jan 2009 19:57:13 -0800 Subject: [time-nuts] Sound cards In-Reply-To: References: Message-ID: <000001c97533$04abce40$0e036ac0$@com> John Ackermann wrote: > One very interesting possibility is the HPSDR (High Performance > Software Defined Radio) boards called Ozy and Janus. > I'm not aware of anyone using this system for T&F work, but it has some interesting possibilities. I bought mine for t&f work, but sadly I have not gotten to it: I just can't seem to get my 2.5 yo boy interested enough in the subject yet, although he is very adept at removing all the dust caps from my gear. :-) -ch From jdb at lartmaker.nl Tue Jan 13 09:24:07 2009 From: jdb at lartmaker.nl (J.D. Bakker) Date: Tue, 13 Jan 2009 10:24:07 +0100 Subject: [time-nuts] Sound cards In-Reply-To: <496736FF.90402@sonic.net> References: <496736FF.90402@sonic.net> Message-ID: >Maybe I lost track and missed something, but I don't think I ever saw >more on the subject of specific high-end sound cards that might be >useful for nutty measurements. From an earlier list message: >[F]or best noise/jitter-performance an external ADC should be used, >connected through a digital link to a PC sound card. One could do a >lot worse than the TI PCM4222 eval board >(http://focus.ti.com/docs/prod/folders/print/pcm4222.html), which >accepts an external clock if so desired. At $149 (plus a tenner or >two for the sound card) this will likely be much cheaper than an >equivalent FireWire-device. The digital link in question is S/PDIF; with the current popularity of Home Theater systems cheap cards with digital I/O have become quite prevalent. As an added bonus, S/PDIF can be run over both coaxial and optical media, the latter being attractive in further isolating PC noise from any measurement setup. And of course, a manufacturer's evaluation board is much better documented and more suited to measurement-specific mods than a random sound card. JDB. [using a custom board with a similar setup in a narrowband VNA] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lartmaker.nl/ From magnus at rubidium.dyndns.org Tue Jan 13 20:21:04 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Tue, 13 Jan 2009 21:21:04 +0100 Subject: [time-nuts] Sound cards In-Reply-To: References: <496736FF.90402@sonic.net> Message-ID: <496CF7B0.9080500@rubidium.dyndns.org> J.D. Bakker skrev: >> Maybe I lost track and missed something, but I don't think I ever saw >> more on the subject of specific high-end sound cards that might be >> useful for nutty measurements. > > From an earlier list message: > >> [F]or best noise/jitter-performance an external ADC should be used, >> connected through a digital link to a PC sound card. One could do a >> lot worse than the TI PCM4222 eval board >> (http://focus.ti.com/docs/prod/folders/print/pcm4222.html), which >> accepts an external clock if so desired. At $149 (plus a tenner or >> two for the sound card) this will likely be much cheaper than an >> equivalent FireWire-device. > > The digital link in question is S/PDIF; with the current popularity > of Home Theater systems cheap cards with digital I/O have become > quite prevalent. As an added bonus, S/PDIF can be run over both > coaxial and optical media, the latter being attractive in further > isolating PC noise from any measurement setup. And of course, a > manufacturer's evaluation board is much better documented and more > suited to measurement-specific mods than a random sound card. The optical link commonly being used for S/P-DIF is TosLink and it seems like it can be the cause of many problems. It seems like some care in doing the optical link setup is needed. I have never digged into why the optical links have that problem. I can only guess, but bad optical coupling seems reasonable. The multimode "fiber" seems to be leaving one or two things to ask for. Cheers, Magnus From bruce.griffiths at xtra.co.nz Tue Jan 13 21:30:16 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 14 Jan 2009 10:30:16 +1300 Subject: [time-nuts] Sound cards In-Reply-To: <496CF7B0.9080500@rubidium.dyndns.org> References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> Message-ID: <496D07E8.1000901@xtra.co.nz> Magnus Danielson wrote: > J.D. Bakker skrev: > >>> Maybe I lost track and missed something, but I don't think I ever saw >>> more on the subject of specific high-end sound cards that might be >>> useful for nutty measurements. >>> >> From an earlier list message: >> >> >>> [F]or best noise/jitter-performance an external ADC should be used, >>> connected through a digital link to a PC sound card. One could do a >>> lot worse than the TI PCM4222 eval board >>> (http://focus.ti.com/docs/prod/folders/print/pcm4222.html), which >>> accepts an external clock if so desired. At $149 (plus a tenner or >>> two for the sound card) this will likely be much cheaper than an >>> equivalent FireWire-device. >>> >> The digital link in question is S/PDIF; with the current popularity >> of Home Theater systems cheap cards with digital I/O have become >> quite prevalent. As an added bonus, S/PDIF can be run over both >> coaxial and optical media, the latter being attractive in further >> isolating PC noise from any measurement setup. And of course, a >> manufacturer's evaluation board is much better documented and more >> suited to measurement-specific mods than a random sound card. >> > > The optical link commonly being used for S/P-DIF is TosLink and it seems > like it can be the cause of many problems. It seems like some care in > doing the optical link setup is needed. I have never digged into why the > optical links have that problem. I can only guess, but bad optical > coupling seems reasonable. The multimode "fiber" seems to be leaving one > or two things to ask for. > > Cheers, > Magnus > > Hej Magnus Relatively high jitter being one problem. Limited sampling rate being another. If one has a cheap 16 bit sound card what will it do with 24 bit data from an external ADC? Bruce From james.p.lux at jpl.nasa.gov Tue Jan 13 21:46:27 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Tue, 13 Jan 2009 13:46:27 -0800 Subject: [time-nuts] Sound cards In-Reply-To: <496CF7B0.9080500@rubidium.dyndns.org> References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> Message-ID: > > optical media, the latter being attractive in further isolating PC > > noise from any measurement setup. And of course, a manufacturer's > > evaluation board is much better documented and more suited to > > measurement-specific mods than a random sound card. > > The optical link commonly being used for S/P-DIF is TosLink > and it seems like it can be the cause of many problems. It > seems like some care in doing the optical link setup is > needed. I have never digged into why the optical links have > that problem. I can only guess, but bad optical coupling > seems reasonable. The multimode "fiber" seems to be leaving > one or two things to ask for. > Consumer audio optical links (TOSlink) are 1000 micron (yes, it sounds better than 1mm) plastic fiber, which is fairly high loss (1000 dB/km), which is fine for 1-2 m cables. TOSlink is actually a trademark of Toshiba http://www.toshiba.com/taec/components/ProdLineGuide/toslink.pdf describes all. TOSlink has worked fine for me, except in one case, where the cable was flexed a lot, and it eventually developed cracks and the loss shot up. It should be relatively trouble free. The connector is a positive mate and keyed, and as long as you don't get debris in the hole in the chassis side, it should work fine. It's not a bad interface, although, I think not well suited to many mate/demate cycles (I don't know for sure, but the trusty 1/4" phone plug is a pretty rugged design). One data sheet I have says 500 mate/demate cycles. I was amused when the guy at the stereo store tried to sell me on RF shielded TOSlink cables, claiming it would provide more clarity and definition in the sound. Uh-huh.. Sort of like the green marking pen for the edges of your CDs to reduce internal reflections, etc. (I, of course, would only use the finest brush made from selected hairs of Tibetan mountain goats to apply a dye made from chlorophyll molecules selected using an electron microscope by trained technicians, etc.. A "marking pen"? My $14000 speaker cables supported on carefully oriented pure fused silica supports would wither in shame.) From jra at febo.com Tue Jan 13 21:51:01 2009 From: jra at febo.com (John Ackermann N8UR) Date: Tue, 13 Jan 2009 16:51:01 -0500 Subject: [time-nuts] Sound cards In-Reply-To: References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> Message-ID: <496D0CC5.4020502@febo.com> Lux, James P wrote: > I was amused when the guy at the stereo store tried to sell me on RF shielded TOSlink cables, claiming it would provide more clarity and definition in the sound. Uh-huh.. Sort of like the green marking pen for the edges of your CDs to reduce internal reflections, etc. (I, of course, would only use the finest brush made from selected hairs of Tibetan mountain goats to apply a dye made from chlorophyll molecules selected using an electron microscope by trained technicians, etc.. A "marking pen"? My $14000 speaker cables supported on carefully oriented pure fused silica supports would wither in shame.) We have a rule here -- no discussion of audiophile insanity! You'll thank me in the end if we avoid a few hundred anecdotes about speaker cable and $500 knobs. :-) John From james.p.lux at jpl.nasa.gov Tue Jan 13 21:57:04 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Tue, 13 Jan 2009 13:57:04 -0800 Subject: [time-nuts] Sound cards In-Reply-To: <496D07E8.1000901@xtra.co.nz> References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> <496D07E8.1000901@xtra.co.nz> Message-ID: > > The optical link commonly being used for S/P-DIF is TosLink and it > > seems like it can be the cause of many problems. It seems like some > > care in doing the optical link setup is needed. I have never digged > > into why the optical links have that problem. I can only guess, but > > bad optical coupling seems reasonable. The multimode > "fiber" seems to > > be leaving one or two things to ask for. > > > > Cheers, > > Magnus > > > > > Hej Magnus > > Relatively high jitter being one problem. > Limited sampling rate being another. > > If one has a cheap 16 bit sound card what will it do with 24 > bit data from an external ADC? > > I would imagine that the sound card is just being used as a digital bus interface, and the A/D won't feature into it. Kind of depends on whether the device driver for the sound card accepts anything on the S/PDIF or whether it assumes 16 bits. I think S/PDIF is 20bits/sample, but there's probably a 24 bit flavor. From jdb at lartmaker.nl Tue Jan 13 22:08:58 2009 From: jdb at lartmaker.nl (J.D. Bakker) Date: Tue, 13 Jan 2009 23:08:58 +0100 Subject: [time-nuts] Sound cards In-Reply-To: <496D07E8.1000901@xtra.co.nz> References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> <496D07E8.1000901@xtra.co.nz> Message-ID: At 10:30 +1300 14-01-2009, Bruce Griffiths wrote: >Magnus Danielson wrote: > > J.D. Bakker skrev: > >>> [F]or best noise/jitter-performance an external ADC should be used, > >>> connected through a digital link to a PC sound card.[...] > >>> >>> The digital link in question is S/PDIF; with the current popularity >>> of Home Theater systems cheap cards with digital I/O have become >>> quite prevalent. As an added bonus, S/PDIF can be run over both >>> coaxial and optical media, the latter being attractive in further > >> isolating PC noise from any measurement setup.[...] > > > > The optical link commonly being used for S/P-DIF is TosLink and it seems > > like it can be the cause of many problems.[...] > >Relatively high jitter being one problem. >Limited sampling rate being another. Both true; IME practical limits are ~7m for 24bit/96ksps/stereo and ~3m for 24bit/192ksps/stereo, depending on TX and RX. My best experiences are with Toshiba TX/RX and pre-made cable listed as 'ADAT Lightpipe' rather than 'TOSLINK'. Both are the same on a mechanical level; the former is a pro audio de facto standard used to transfer multichannel audio around in studios, and its customers tend to be a bit more picky wrt out-of-spec cables. Jitter is not a problem as long as (a) the converter is the timing master and (b) the PC end doesn't try to do resampling or other 'clever' tricks (I know of no current mainstream chipsets that do). >If one has a cheap 16 bit sound card what will it do with 24 bit data >from an external ADC? It truncates it to its 16 MSBs. Note that you'll have a very hard time buying a new internal 16 bit sound card these days, never mind one with S/PDIF. The only 16 bit S/PDIF interfaces you could get are USB ones designed around TI's PCM29xx USB codecs (and not much else). As these top out at 48ksps, they are of limited use anyway. Many of the cheapest Home Theater PCI Sound Cards are built around the CMI8738 chip or one of its derivatives. This chip offers no-frills S/PDIF I/O up to 96ksps for a very low price, and as pretty much all boards that I have seen are a clone of the manufacturer's evaluation board, the S/PDIF signal is almost always easily available on a .1in pitch pin header (which may or may not be populated). I use it for quite a few test setups, but I do have a more expensive card (RME 9652) if I need more channels or a higher sampling rate. JDB. [disclaimer: the drivers are also an issue, naturally. I do most of my signal processing under Linux, which has good drivers for the CMI8738. On Windows and/or OSX YMMV, but I would be surprised if it did not work at all] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lartmaker.nl/ From rexa at sonic.net Tue Jan 13 22:12:52 2009 From: rexa at sonic.net (Rex) Date: Tue, 13 Jan 2009 14:12:52 -0800 Subject: [time-nuts] Sound cards In-Reply-To: <496D0CC5.4020502@febo.com> References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> <496D0CC5.4020502@febo.com> Message-ID: <496D11E4.6070804@sonic.net> John Ackermann N8UR wrote: > Lux, James P wrote: > > >> I was amused when the guy at the stereo store tried to sell me on RF shielded TOSlink cables, claiming it would provide more clarity and definition in the sound. Uh-huh.. Sort of like the green marking pen for the edges of your CDs to reduce internal reflections, etc. (I, of course, would only use the finest brush made from selected hairs of Tibetan mountain goats to apply a dye made from chlorophyll molecules selected using an electron microscope by trained technicians, etc.. A "marking pen"? My $14000 speaker cables supported on carefully oriented pure fused silica supports would wither in shame.) >> > > We have a rule here -- no discussion of audiophile insanity! You'll > thank me in the end if we avoid a few hundred anecdotes about speaker > cable and $500 knobs. :-) > > John > > Good, John. I was just about to suggest the same voluntary prohibition. -Rex From magnus at rubidium.dyndns.org Tue Jan 13 23:01:13 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 14 Jan 2009 00:01:13 +0100 Subject: [time-nuts] Sound cards In-Reply-To: References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> Message-ID: <496D1D39.6040808@rubidium.dyndns.org> Lux, James P skrev: >>> optical media, the latter being attractive in further isolating PC >>> noise from any measurement setup. And of course, a manufacturer's >>> evaluation board is much better documented and more suited to >>> measurement-specific mods than a random sound card. >> The optical link commonly being used for S/P-DIF is TosLink >> and it seems like it can be the cause of many problems. It >> seems like some care in doing the optical link setup is >> needed. I have never digged into why the optical links have >> that problem. I can only guess, but bad optical coupling >> seems reasonable. The multimode "fiber" seems to be leaving >> one or two things to ask for. >> > > Consumer audio optical links (TOSlink) are 1000 micron (yes, it sounds better than 1mm) plastic fiber, which is fairly high loss (1000 dB/km), which is fine for 1-2 m cables. TOSlink is actually a trademark of Toshiba > http://www.toshiba.com/taec/components/ProdLineGuide/toslink.pdf describes all. > > TOSlink has worked fine for me, except in one case, where the cable was flexed a lot, and it eventually developed cracks and the loss shot up. Trouble is, many want some 10 m runs. The unbalanced one into a good cable should be able to do much longer runs. The Phono (aka RCA) connector isn't really suited to the task, but there is pretty good limits on the slopes, so it should be fine. Propper BNC with good cable handles 90m of HD-SDI signal so I don't think I am stretching my knowledge beyond unreasnoble limits here... :) Using 4,5 GHz BW cable for AES/EBU testing is kind of interesting... :) > It should be relatively trouble free. The connector is a positive mate and keyed, and as long as you don't get debris in the hole in the chassis side, it should work fine. > > It's not a bad interface, although, I think not well suited to many mate/demate cycles (I don't know for sure, but the trusty 1/4" phone plug is a pretty rugged design). One data sheet I have says 500 mate/demate cycles. > > > I was amused when the guy at the stereo store tried to sell me on RF shielded TOSlink cables, claiming it would provide more clarity and definition in the sound. Uh-huh.. Sort of like the green marking pen for the edges of your CDs to reduce internal reflections, etc. (I, of course, would only use the finest brush made from selected hairs of Tibetan mountain goats to apply a dye made from chlorophyll molecules selected using an electron microscope by trained technicians, etc.. A "marking pen"? My $14000 speaker cables supported on carefully oriented pure fused silica supports would wither in shame.) You must have gold-plated connectros for your TOSlink, you KNOW that. :) (Yes, those cables exists!) Cheers, Magnus From james.p.lux at jpl.nasa.gov Tue Jan 13 23:12:05 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Tue, 13 Jan 2009 15:12:05 -0800 Subject: [time-nuts] Sound cards In-Reply-To: <496D1D39.6040808@rubidium.dyndns.org> References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> <496D1D39.6040808@rubidium.dyndns.org> Message-ID: Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Magnus Danielson > Sent: Tuesday, January 13, 2009 3:01 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Sound cards > > L > > > > Consumer audio optical links (TOSlink) are 1000 micron > (yes, it sounds > > better than 1mm) plastic fiber, which is fairly high loss > (1000 dB/km), which is fine for 1-2 m cables. TOSlink is > actually a trademark of Toshiba > http://www.toshiba.com/taec/components/ProdLineGuide/toslink.p > df describes all. > > > > TOSlink has worked fine for me, except in one case, where > the cable was flexed a lot, and it eventually developed > cracks and the loss shot up. > > Trouble is, many want some 10 m runs. Exactly.. I was just down in the lab, and looked at the cables we have strung all over the place, and for us, a 2m cable is positively short. An awful lot of 5m and 10m cables just patching one thing to another (consider going from a connector on a piece of equipment in one 2m high rack to a connector in another 2m rack. There's 3-4 m just in going up and down, not to mention the meter or so across, if the racks happen to be side by side. There ARE fancier cables and connectors in the same family that have more range, but are still pretty cheap components. The galvanic isolation and EMI immunity IS attractive. But, a piece of RG-58 sized coax and BNC connectors is awfully common and convenient. From hmurray at megapathdsl.net Tue Jan 13 23:24:29 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 13 Jan 2009 15:24:29 -0800 Subject: [time-nuts] Sound cards In-Reply-To: Message from Magnus Danielson of "Tue, 13 Jan 2009 21:21:04 +0100." <496CF7B0.9080500@rubidium.dyndns.org> Message-ID: <20090113232430.6C65FBCD8@ip-64-139-1-69.sjc.megapath.net> > The optical link commonly being used for S/P-DIF is TosLink and it > seems like it can be the cause of many problems. It seems like some > care in doing the optical link setup is needed. I have never digged > into why the optical links have that problem. I can only guess, but > bad optical coupling seems reasonable. The multimode "fiber" seems to > be leaving one or two things to ask for. It's been a while since I did any serious work with fibers. There are 2 limitations. One is signal to noise. You have to get enough light in the transmit end so that after attenuation there will be enough coming out for the receiver to be able to find the bits. Attenuatiion is linear with length with a constant for getting in and out of the fiber. Add some more for splices/connectors. The other is dispersion. If you have a multi-mode fiber, some of the photons bounce around more than others which results in a longer path and increased transit time. Simple geometry is a good approximation. The net result is that the photons get smeared in time. If your pulses are too narrow (bitrate too high), the smearing will cause adjacent bits to overlap and you can't easily sort things out at the receiver. Single mode fibers don't have modal dispersion. But they do have chromatic dispersion. Long distance telco links use very narrow bandwidth lasers. One characteristic of dispersion is that there is a trade-off between distance and bandwidth. Fibers have ratings in megabit-miles. Typical multi-mode fibers were 300-500 megabit-miles. Single mode fibers are roughly 7-9 microns dia for the active region. Multi-mode fibers were 50 or 62.5 microns. Roughly 10 years ago, there was a sweet spot at 155 megabits (OC-3) and 2 km using LEDs for the transmitter and multi-mode fibers. Since then, they are using low cost lasers (from CDs) so things have changed. If you wanted faster or farther, you used a laser and single mode fibers. The engineering/specsmanship on the overall link was super conservative. It was essentially impossible to measure the error rate. The trick is to insert enough attenuation so you get enough errors to measure, then compute what you would get without the attenuation. I haven't worked with plastic fibers. I'd expect the engineering to be conservative so it should just work. If it doesn't the obvious problems are dirt/mud at the connectors or cracked/broken fibers. (I'm assuming a sane length.) One disadvantage of conservative engineering is that a system that's broken might actually work well enough to act like a flaky system. I'm thinking of something like a broken fiber that is sometimes held in place close-enough by the jacket. -- These are my opinions, not necessarily my employer's. I hate spam. From daun at yeagley.net Tue Jan 13 23:37:09 2009 From: daun at yeagley.net (Daun Yeagley) Date: Tue, 13 Jan 2009 18:37:09 -0500 Subject: [time-nuts] Sound cards In-Reply-To: <496D0CC5.4020502@febo.com> References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> <496D0CC5.4020502@febo.com> Message-ID: Spoil sport! Daun -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of John Ackermann N8UR Sent: Tuesday, January 13, 2009 4:51 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Sound cards Lux, James P wrote: > I was amused when the guy at the stereo store tried to sell me on RF shielded TOSlink cables, claiming it would provide more clarity and definition in the sound. Uh-huh.. Sort of like the green marking pen for the edges of your CDs to reduce internal reflections, etc. (I, of course, would only use the finest brush made from selected hairs of Tibetan mountain goats to apply a dye made from chlorophyll molecules selected using an electron microscope by trained technicians, etc.. A "marking pen"? My $14000 speaker cables supported on carefully oriented pure fused silica supports would wither in shame.) We have a rule here -- no discussion of audiophile insanity! You'll thank me in the end if we avoid a few hundred anecdotes about speaker cable and $500 knobs. :-) John _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From magnus at rubidium.dyndns.org Tue Jan 13 23:48:18 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 14 Jan 2009 00:48:18 +0100 Subject: [time-nuts] Sound cards In-Reply-To: References: <496736FF.90402@sonic.net> <496CF7B0.9080500@rubidium.dyndns.org> <496D1D39.6040808@rubidium.dyndns.org> Message-ID: <496D2842.7090807@rubidium.dyndns.org> Lux, James P skrev: > Message----- >> From: time-nuts-bounces at febo.com >> [mailto:time-nuts-bounces at febo.com] On Behalf Of Magnus Danielson >> Sent: Tuesday, January 13, 2009 3:01 PM >> To: Discussion of precise time and frequency measurement >> Subject: Re: [time-nuts] Sound cards >> >> L >>> Consumer audio optical links (TOSlink) are 1000 micron >> (yes, it sounds >>> better than 1mm) plastic fiber, which is fairly high loss >> (1000 dB/km), which is fine for 1-2 m cables. TOSlink is >> actually a trademark of Toshiba >> http://www.toshiba.com/taec/components/ProdLineGuide/toslink.p >> df describes all. >>> TOSlink has worked fine for me, except in one case, where >> the cable was flexed a lot, and it eventually developed >> cracks and the loss shot up. >> >> Trouble is, many want some 10 m runs. > > Exactly.. I was just down in the lab, and looked at the cables we have strung all over the place, and for us, a 2m cable is positively short. An awful lot of 5m and 10m cables just patching one thing to another (consider going from a connector on a piece of equipment in one 2m high rack to a connector in another 2m rack. There's 3-4 m just in going up and down, not to mention the meter or so across, if the racks happen to be side by side. > > There ARE fancier cables and connectors in the same family that have more range, but are still pretty cheap components. > > The galvanic isolation and EMI immunity IS attractive. But, a piece of RG-58 sized coax and BNC connectors is awfully common and convenient. On the other hand, I am used to stretch out for a 25 km or 50 km roll of fiber. Works very well for 2,5 Gb/s or 10 Gb/s links. The price for decent enought multimode should be more or less dirt cheap by now, and we are talking real glas. Cheers, Magnus From demianm at attglobal.net Wed Jan 14 00:05:45 2009 From: demianm at attglobal.net (Demian Martin) Date: Tue, 13 Jan 2009 16:05:45 -0800 Subject: [time-nuts] Sound Cards In-Reply-To: References: Message-ID: Magnus Danielson wrote: > > The digital link in question is S/PDIF; with the current popularity > > of Home Theater systems cheap cards with digital I/O have become > > quite prevalent. As an added bonus, S/PDIF can be run over both > > coaxial and optical media, the latter being attractive in further > > isolating PC noise from any measurement setup. And of course, a > > manufacturer's evaluation board is much better documented and more > > suited to measurement-specific mods than a random sound card. > > The optical link commonly being used for S/P-DIF is TosLink and it seems > like it can be the cause of many problems. It seems like some care in > doing the optical link setup is needed. I have never digged into why the > optical links have that problem. I can only guess, but bad optical > coupling seems reasonable. The multimode "fiber" seems to be leaving one > or two things to ask for. > > Cheers, > Magnus Without getting too "audiophile" there are several considerations. Toslink is bandwidth limited- the LED's are not really fast enough for 96K and really not for 192K sampling. The effect is high jitter on the link or a lost connection. The high jitter may not matter if the sampling is done with the external capture system (most of which are much more expensive). SPDIF or AES/EBU don't have the bandwidth limitation but can have other issues. The cheap ones don't have transformer isolation, however the transformers can increase the jitter on the link. You can use external USB capture, I'm playing with an EMU Tracker pre gadget that seems to do 192K at 24 bits pretty well and for $125. But I get better results from the ESI Juli@ pci card for around the same price, very low distortion and noise, and good Alsa support in Linux. It may be all that's needed. -Demian From james.p.lux at jpl.nasa.gov Wed Jan 14 00:09:26 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Tue, 13 Jan 2009 16:09:26 -0800 Subject: [time-nuts] Sound cards In-Reply-To: <20090113232430.6C65FBCD8@ip-64-139-1-69.sjc.megapath.net> References: Message from Magnus Danielson of "Tue, 13 Jan 2009 21:21:04 +0100." <496CF7B0.9080500@rubidium.dyndns.org> <20090113232430.6C65FBCD8@ip-64-139-1-69.sjc.megapath.net> Message-ID: > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Hal Murray > Sent: Tuesday, January 13, 2009 3:24 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Sound cards > > > > I haven't worked with plastic fibers. I'd expect the > engineering to be conservative so it should just work. If it > doesn't the obvious problems are dirt/mud at the connectors > or cracked/broken fibers. (I'm assuming a sane > length.) > > One disadvantage of conservative engineering is that a system > that's broken might actually work well enough to act like a > flaky system. I'm thinking of something like a broken fiber > that is sometimes held in place close-enough by the jacket. > > And, in a situation where the plastic fiber is just getting the databits from A/D into computer, as long as the BER is reasonably low, it works. You're not worried about actually using the fiber for accurate timing, just as a data transport. BTW, the scenario of broken fiber held by the jacket is very close to the one failure I've had with plastic fiber. From steveheidmann at yahoo.com Wed Jan 14 01:17:22 2009 From: steveheidmann at yahoo.com (steve heidmann) Date: Tue, 13 Jan 2009 17:17:22 -0800 (PST) Subject: [time-nuts] Sound Cards In-Reply-To: Message-ID: <140523.69316.qm@web36805.mail.mud.yahoo.com> Firecomm.com has some nice parts to look at --- On Tue, 1/13/09, Demian Martin wrote: From: Demian Martin Subject: Re: [time-nuts] Sound Cards To: time-nuts at febo.com Date: Tuesday, January 13, 2009, 4:05 PM Magnus Danielson wrote: > > The digital link in question is S/PDIF; with the current popularity > > of Home Theater systems cheap cards with digital I/O have become > > quite prevalent. As an added bonus, S/PDIF can be run over both > > coaxial and optical media, the latter being attractive in further > > isolating PC noise from any measurement setup. And of course, a > > manufacturer's evaluation board is much better documented and more > > suited to measurement-specific mods than a random sound card. > > The optical link commonly being used for S/P-DIF is TosLink and it seems > like it can be the cause of many problems. It seems like some care in > doing the optical link setup is needed. I have never digged into why the > optical links have that problem. I can only guess, but bad optical > coupling seems reasonable. The multimode "fiber" seems to be leaving one > or two things to ask for. > > Cheers, > Magnus Without getting too "audiophile" there are several considerations. Toslink is bandwidth limited- the LED's are not really fast enough for 96K and really not for 192K sampling. The effect is high jitter on the link or a lost connection. The high jitter may not matter if the sampling is done with the external capture system (most of which are much more expensive). SPDIF or AES/EBU don't have the bandwidth limitation but can have other issues. The cheap ones don't have transformer isolation, however the transformers can increase the jitter on the link. You can use external USB capture, I'm playing with an EMU Tracker pre gadget that seems to do 192K at 24 bits pretty well and for $125. But I get better results from the ESI Juli@ pci card for around the same price, very low distortion and noise, and good Alsa support in Linux. It may be all that's needed. -Demian _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From newell at cei.net Wed Jan 14 02:40:35 2009 From: newell at cei.net (Scott Newell) Date: Tue, 13 Jan 2009 20:40:35 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <496A9577.6050807@pacific.net> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> <496A9577.6050807@pacific.net> Message-ID: <200901140240.n0E2ef7R028180@host22.the-web-host.com> At 06:57 PM 1/11/2009, Brooke Clarke wrote: >Hi: > >I've received the 60 kHz version of the C-max CMMR-6P LF time code receiver >module. Digi-Key ( 561-1014-ND) has these improperly listed in their catalog >and the CMMR-6P data sheet has a typo that may have mislead Digi-Key. Ah-hah! There were 4 in stock when I asked a week ago, and now they are on backorder. I guess I know who got 'em... Thanks for the pic. It answers my question. -- newell N5TNL From bruce.griffiths at xtra.co.nz Wed Jan 14 03:27:41 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 14 Jan 2009 16:27:41 +1300 Subject: [time-nuts] Sound Cards In-Reply-To: <140523.69316.qm@web36805.mail.mud.yahoo.com> References: <140523.69316.qm@web36805.mail.mud.yahoo.com> Message-ID: <496D5BAD.3040103@xtra.co.nz> Steve Do you mean?: http://www.firecom.com/ Bruce steve heidmann wrote: > Firecomm.com has some nice parts to look at > > --- On Tue, 1/13/09, Demian Martin wrote: > > From: Demian Martin > Subject: Re: [time-nuts] Sound Cards > To: time-nuts at febo.com > Date: Tuesday, January 13, 2009, 4:05 PM > > > Magnus Danielson wrote: > > >>> The digital link in question is S/PDIF; with the current popularity >>> of Home Theater systems cheap cards with digital I/O have become >>> quite prevalent. As an added bonus, S/PDIF can be run over both >>> coaxial and optical media, the latter being attractive in further >>> isolating PC noise from any measurement setup. And of course, a >>> manufacturer's evaluation board is much better documented and >>> > more > >>> suited to measurement-specific mods than a random sound card. >>> >> The optical link commonly being used for S/P-DIF is TosLink and it seems >> like it can be the cause of many problems. It seems like some care in >> doing the optical link setup is needed. I have never digged into why the >> optical links have that problem. I can only guess, but bad optical >> coupling seems reasonable. The multimode "fiber" seems to be >> > leaving one > >> or two things to ask for. >> >> Cheers, >> Magnus >> > > Without getting too "audiophile" there are several considerations. > Toslink > is bandwidth limited- the LED's are not really fast enough for 96K and > really not for 192K sampling. The effect is high jitter on the link or a > lost connection. The high jitter may not matter if the sampling is done with > the external capture system (most of which are much more expensive). SPDIF > or AES/EBU don't have the bandwidth limitation but can have other issues. > The cheap ones don't have transformer isolation, however the transformers > can increase the jitter on the link. You can use external USB capture, I'm > playing with an EMU Tracker pre gadget that seems to do 192K at 24 bits > pretty well and for $125. But I get better results from the ESI Juli@ pci > card for around the same price, very low distortion and noise, and good Alsa > support in Linux. It may be all that's needed. > -Demian > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From brooke at pacific.net Wed Jan 14 03:30:09 2009 From: brooke at pacific.net (Brooke Clarke) Date: Tue, 13 Jan 2009 19:30:09 -0800 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <200901140240.n0E2ef7R028180@host22.the-web-host.com> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> <496A9577.6050807@pacific.net> <200901140240.n0E2ef7R028180@host22.the-web-host.com> Message-ID: <496D5C41.9090503@pacific.net> Hi Scott: Press F5 at: http://www.prc68.com/I/Loop.shtml#CMMR6P60 and scroll down to see a scope image. Not sure if the dots are caused by the sampling scope or by noise? Have Fun, Brooke Clarke http://www.prc68.com Scott Newell wrote: > At 06:57 PM 1/11/2009, Brooke Clarke wrote: >> Hi: >> >> I've received the 60 kHz version of the C-max CMMR-6P LF time code receiver >> module. Digi-Key ( 561-1014-ND) has these improperly listed in their catalog >> and the CMMR-6P data sheet has a typo that may have mislead Digi-Key. > > Ah-hah! There were 4 in stock when I asked a week ago, and now they > are on backorder. I guess I know who got 'em... > > Thanks for the pic. It answers my question. > > From chris.kuethe at gmail.com Wed Jan 14 03:42:04 2009 From: chris.kuethe at gmail.com (Chris Kuethe) Date: Tue, 13 Jan 2009 19:42:04 -0800 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <496D5C41.9090503@pacific.net> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> <496A9577.6050807@pacific.net> <200901140240.n0E2ef7R028180@host22.the-web-host.com> <496D5C41.9090503@pacific.net> Message-ID: <91981b3e0901131942x68117af5wbf96191c4f766f00@mail.gmail.com> On Tue, Jan 13, 2009 at 7:30 PM, Brooke Clarke wrote: > Hi Scott: > > Press F5 at: > http://www.prc68.com/I/Loop.shtml#CMMR6P60 > and scroll down to see a scope image. Not sure if the dots are caused by the > sampling scope or by noise? I'm going to guess your reception sucks. I hooked up an LED to the output to of mine... during the day, I get a lot of short blinks. Later in the evening or at night the 200, 500 and 800ms pulses are solid and clearly identifiable. They look that way on a scope, too. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? From newell at cei.net Wed Jan 14 04:31:28 2009 From: newell at cei.net (Scott Newell) Date: Tue, 13 Jan 2009 22:31:28 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <496D5C41.9090503@pacific.net> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> <496A9577.6050807@pacific.net> <200901140240.n0E2ef7R028180@host22.the-web-host.com> <496D5C41.9090503@pacific.net> Message-ID: <200901140431.n0E4VYlP018266@host22.the-web-host.com> At 09:30 PM 1/13/2009, Brooke Clarke wrote: >Hi Scott: > >Press F5 at: >http://www.prc68.com/I/Loop.shtml#CMMR6P60 >and scroll down to see a scope image. Not sure if the dots are caused by the >sampling scope or by noise? Bad reception. My old rat shack 'atomic clock' signal looks like that sometimes too. -- newell N5TNL From newell at cei.net Wed Jan 14 04:44:20 2009 From: newell at cei.net (Scott Newell) Date: Tue, 13 Jan 2009 22:44:20 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <496D5C41.9090503@pacific.net> References: <332872.66371.qm@web54103.mail.re2.yahoo.com> <4964C1A7.4080902@wwrinc.com> <91981b3e0901070855m613fd2d2w3425e095a16f5ea4@mail.gmail.com> <496A9577.6050807@pacific.net> <200901140240.n0E2ef7R028180@host22.the-web-host.com> <496D5C41.9090503@pacific.net> Message-ID: <200901140444.n0E4iZJP021814@host22.the-web-host.com> At 09:30 PM 1/13/2009, Brooke Clarke wrote: >Hi Scott: > >Press F5 at: >http://www.prc68.com/I/Loop.shtml#CMMR6P60 >and scroll down to see a scope image. Not sure if the dots are caused by the >sampling scope or by noise? Here's my current signal: http://www.digital-pickle.dyndns.org/images/wwvb/wwvb.jpg -- newell N5TNL From magnus at rubidium.dyndns.org Wed Jan 14 08:12:11 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 14 Jan 2009 09:12:11 +0100 Subject: [time-nuts] Sound Cards In-Reply-To: References: Message-ID: <496D9E5B.3090603@rubidium.dyndns.org> Demian Martin skrev: > > Magnus Danielson wrote: > >>> The digital link in question is S/PDIF; with the current popularity >>> of Home Theater systems cheap cards with digital I/O have become >>> quite prevalent. As an added bonus, S/PDIF can be run over both >>> coaxial and optical media, the latter being attractive in further >>> isolating PC noise from any measurement setup. And of course, a >>> manufacturer's evaluation board is much better documented and more >>> suited to measurement-specific mods than a random sound card. >> The optical link commonly being used for S/P-DIF is TosLink and it seems >> like it can be the cause of many problems. It seems like some care in >> doing the optical link setup is needed. I have never digged into why the >> optical links have that problem. I can only guess, but bad optical >> coupling seems reasonable. The multimode "fiber" seems to be leaving one >> or two things to ask for. >> >> Cheers, >> Magnus > > Without getting too "audiophile" there are several considerations. Toslink > is bandwidth limited- the LED's are not really fast enough for 96K and > really not for 192K sampling. The effect is high jitter on the link or a > lost connection. The high jitter may not matter if the sampling is done with > the external capture system (most of which are much more expensive). SPDIF > or AES/EBU don't have the bandwidth limitation but can have other issues. I think you meant to say the electrical S/P-DIF and AES/EBU. > The cheap ones don't have transformer isolation, however the transformers > can increase the jitter on the link. Depends on the transformer. The AES-3 electical form of AES/EBU (balanced on XLR) has a drawback in that it may be hooked up over lines, patchfields and cross-connects not intended for AES/EBU signals. This can cause some grief. Installation standards has changed as a result as a consequence. For smaller systems may the transformer not be as much of an issue as in larger installations. The unbalanced form of AES/EBU, AES-3-id, is becomming popular. It should not be confused with S/P-DIF since it is distinct in several forms, except for the obvious difference in subcode content. > You can use external USB capture, I'm > playing with an EMU Tracker pre gadget that seems to do 192K at 24 bits > pretty well and for $125. But I get better results from the ESI Juli@ pci > card for around the same price, very low distortion and noise, and good Alsa > support in Linux. It may be all that's needed. It is. Wordclock input? Cheers, Magnus From phk at phk.freebsd.dk Wed Jan 14 09:45:02 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 14 Jan 2009 09:45:02 +0000 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: Your message of "Tue, 13 Jan 2009 19:42:04 PST." <91981b3e0901131942x68117af5wbf96191c4f766f00@mail.gmail.com> Message-ID: <36145.1231926302@critter.freebsd.dk> In message <91981b3e0901131942x68117af5wbf96191c4f766f00 at mail.gmail.com>, Chris Kuethe writes: >On Tue, Jan 13, 2009 at 7:30 PM, Brooke Clarke wrote: >> Hi Scott: >> >> Press F5 at: >> http://www.prc68.com/I/Loop.shtml#CMMR6P60 >> and scroll down to see a scope image. Not sure if the dots are caused by the >> sampling scope or by noise? > >I'm going to guess your reception sucks. I hooked up an LED to the >output to of mine... during the day, I get a lot of short blinks. >Later in the evening or at night the 200, 500 and 800ms pulses are >solid and clearly identifiable. They look that way on a scope, too. Some advice on decoding these signals: There are two dominant forms of noise: Missing pulses. Stray pulses, mostly very narrow. Even when blanketet by stray pulses, there is a strong correlation with pulses starting at the time where the "real" pulses should be. Therefore, once you have established the second epoch, only pulses that start close to it should be considered, anything more than about 10-20 msec off the epoch can be ignored. Here is a relevant comment from NTPns' DCF77 code: /* * This is slightly complicated, but there is a good reason: In order to * minimize the effects of noise which mostly take the form of spurious extra * pulses, we want to poll the PPS-API as soon as possible after the likely * end of the pulse. * * Once we have a pulse of valid length, we poll again 1.135 second after * the start time of that pulse, to look for a following short pulse. * * If we find a valid pulse at that time, we start over from above, if no * valid pulse is found, we look for a long pulse .1 second later. * * If we find a valid pulse at that time, we start over from above, if none * is found we look for a short pulse .9 second later. * * A slight complication here is that our pulses are timestamped on * CLOCK_REALTIME, but eventlib may run on CLOCK_MONOTONIC and the fact * that we can only fiddle the interval setting on recurring timers. * * All the magic numbers are tweakable. * * * A B C D E a b c d e * v v v v v v v v v v * * ---- ----- ------------------------------------ ----- ------- * | | | | | | * | | | | | | * ----- ----- ----- ----- * * */ The other thing is, once you have elminated noise pulses, how do you interpret the timecode when some pulses are missing ? The robust way is to try out each of the possible 60 locations for the start of the minute, and see if the data content proves it wrong: /* * This receiver use the reverse principle of all other DCF77 receivers I have * seen implemented, instead of relying on the S/N to be good enough for the * correct minute-synchronization to trivially stand out (ie: by the absense * of the 59th second pulse), I instead start out with 60 possible hypothesis * for where the minute starts, and disprove them as I collect bits. * * There are many features of the DCF77 timegram which can be checked even * though we do not know what time/date it actually is. For instance a minute * reading of 71 would obviously be wrong, as would illegal BCD digits, wrong * parity or the two timezone bits being identical. * * It is possible to also check that the first 14 bits follow a particular * pattern, they have been zero every single time I have looked but the * PTB reserves the right to play with them. * * The principle behind this is based on the observation that noise almost * always consist of missing pulses, and that '0' and '1' bit pulses very * rarely gets confused. * * This method allows us to tighten the frontend filters much more than * other receivers because we can tolerate a high ratio of missing pulses. * * It is interesting to note that this method does not even require a full * minute worth of pulses before the top of the minute is uniquely determined: * even though we only have one or two bits actually supporting it, all other * possibilities have two or more bits rejecting them as possibilities. * */ NTPns can be downloaded from here: http://phk.freebsd.dk/NTPns/phkrel/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From Hrosenberg at catena.nl Wed Jan 14 12:07:45 2009 From: Hrosenberg at catena.nl (Hans Rosenberg) Date: Wed, 14 Jan 2009 13:07:45 +0100 Subject: [time-nuts] Ultra low noise Pierce oscillator??? Message-ID: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> Hi Time-nuts people, I'm new to this forum and really enjoyed reading all the design strategies on oscillators. I'm currently designing a low noise oscillator and I wonder if you can help me with some questions. I've attached a picture of the oscillator core I'm using. I decided to go for a Pierce design some time ago after looking at a few topologies. I took a number of measures to give the design a low 1/f noise. 1. Low DC gain. There is a transformer in the drain line. 2. Ultra low noise supply (not on the schematic) using an ad586 buried zener reference with a -3dB lowpass at 0.1Hz. This 5V reference is then increased to 12V using a low noise discrete buffer. 3. The phase shift across T1 is only a few degrees (<5degrees), low phaseshift in the amplifier reduces 1/f noise. 4. I chose a fet in order to minimize the load at the 'output' of the crystal, the only load I have now is the bias resistor of 100k. This resistor does cause low frequency noise (at higher frequencies C1 shorts it). This may be the problem in this circuit, Cgd is modulated by this noise and a low frequency voltage is applied at the gate, which is however not amplified because of the currentsource in the source line which should cause nearly infinite feedback for low frequencies making the DC gain even lower. 5. The current source produces low frequency noise. I have to have a current source though (I could use a resistor but I calculated that produces more noise). I could increase the voltage across R5 and make R5 bigger to reduce the noise, however, this will reduce Vgd which means modulation of Cgd becomes worse. I think I'm ok here by dividing the voltage across the currentsource and the active oscillator element in half. Cgd of a J309 is around 2.5pF at Vds=10V (it is a little higher in my case since Vgd is lower) 6. L2 can be mounted to accommodate overtone crystals. ( I still have to calculate a value for L2 and C2 to get the correct impedance at resonance) 7. F1 and F2 are ferrite beads with a low impedance at DC (far less then an ohm) and rising impedance at higher frequencies to prevent oscillation of the RF transistors. 8. I've found a really good overtonecrystal from Citizen. CM309S. I measured the unloaded Q to be 313000, the loaded Q (using simple estimation) should be around 280000 in the circuit. (C0=2.5pF, R=20Ohm, C1=0.75fF, L=29.444mH, can be aquired at digikey). The spec for Rs was <130Ohms, I guess reality is much better :-) 9. The transformeroutputs are going to an isolationchain using 3 cascodes and then a discrete limiter not shown on the schematic. 10. This whole oscillator core will be placed in an RF shielding can. The isolationchain will have a can of it's own to so pulling should be nearly eliminated. Now my questions are: 1. I don't see a pierce design in any of the low noise oscillator circuits in the discussion threads about low noise oscillator design. Is there something fundamentally wrong about this topology? 2. I read a few times that ferrites in inductors (and I assume transformers as well) can be a real problem for 1/f noise. I'm using a transformer (TC1-1t from minicircuits) which is made with a ferrite bead. Do you know of any transformers or inductors that have low 1/f noise ferrite material. 3. Have I missed something fundamental in the design. The goal is to build a very good oscillator. I would like to achieve something like -110dBc/Hz at 10Hz distance at 33.8688MHz. Thanks in advance for having a look and best regards, Hans Rosenberg -------------- next part -------------- A non-text attachment was scrubbed... Name: temp.pdf Type: application/pdf Size: 15126 bytes Desc: temp.pdf Url : http://www.febo.com/pipermail/time-nuts/attachments/20090114/ce66a6e8/attachment.pdf From jpawlan at pawlan.com Wed Jan 14 15:58:47 2009 From: jpawlan at pawlan.com (Jeffrey Pawlan) Date: Wed, 14 Jan 2009 07:58:47 -0800 (PST) Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> Message-ID: My best crystal oscillator designs are modified Pierce. But I definitely recommend using a low noise BJT else you will have 1/f noise. Jeffrey Pawlan WA6KBL Pawlan Communications From brooke at pacific.net Wed Jan 14 16:56:58 2009 From: brooke at pacific.net (Brooke Clarke) Date: Wed, 14 Jan 2009 08:56:58 -0800 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <36145.1231926302@critter.freebsd.dk> References: <36145.1231926302@critter.freebsd.dk> Message-ID: <496E195A.1050107@pacific.net> Hi Poul: Thanks for that info. It's sort of what was done in the PST1020 WWV-WWVH receiver, although an improvement, see patent 4768178 High precision radio signal controlled continuously updated digital clock August 30, 1988 http://www.prc68.com/I/PST1020.shtml http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4768178 This Google patent search on 4768178 has many hits for improvements on that idea: http://www.google.com/patents?q=4768178&btnG=Search+Patents My first problem is to hook the front end up to a couple of batteries and a LED to find a good place for the antenna. Have Fun, Brooke Clarke http://www.prc68.com Poul-Henning Kamp wrote: > In message <91981b3e0901131942x68117af5wbf96191c4f766f00 at mail.gmail.com>, Chris > Kuethe writes: >> On Tue, Jan 13, 2009 at 7:30 PM, Brooke Clarke wrote: >>> Hi Scott: >>> >>> Press F5 at: >>> http://www.prc68.com/I/Loop.shtml#CMMR6P60 >>> and scroll down to see a scope image. Not sure if the dots are caused by the >>> sampling scope or by noise? >> I'm going to guess your reception sucks. I hooked up an LED to the >> output to of mine... during the day, I get a lot of short blinks. >> Later in the evening or at night the 200, 500 and 800ms pulses are >> solid and clearly identifiable. They look that way on a scope, too. > > Some advice on decoding these signals: > > There are two dominant forms of noise: > > Missing pulses. > > Stray pulses, mostly very narrow. > > Even when blanketet by stray pulses, there is a strong correlation with > pulses starting at the time where the "real" pulses should be. > > Therefore, once you have established the second epoch, only pulses > that start close to it should be considered, anything more than > about 10-20 msec off the epoch can be ignored. > > Here is a relevant comment from NTPns' DCF77 code: > > /* > * This is slightly complicated, but there is a good reason: In order to > * minimize the effects of noise which mostly take the form of spurious extra > * pulses, we want to poll the PPS-API as soon as possible after the likely > * end of the pulse. > * > * Once we have a pulse of valid length, we poll again 1.135 second after > * the start time of that pulse, to look for a following short pulse. > * > * If we find a valid pulse at that time, we start over from above, if no > * valid pulse is found, we look for a long pulse .1 second later. > * > * If we find a valid pulse at that time, we start over from above, if none > * is found we look for a short pulse .9 second later. > * > * A slight complication here is that our pulses are timestamped on > * CLOCK_REALTIME, but eventlib may run on CLOCK_MONOTONIC and the fact > * that we can only fiddle the interval setting on recurring timers. > * > * All the magic numbers are tweakable. > * > * > * A B C D E a b c d e > * v v v v v v v v v v > * > * ---- ----- ------------------------------------ ----- ------- > * | | | | | | > * | | | | | | > * ----- ----- ----- ----- > * > * > */ > > The other thing is, once you have elminated noise pulses, how do you > interpret the timecode when some pulses are missing ? > > The robust way is to try out each of the possible 60 locations for the > start of the minute, and see if the data content proves it wrong: > > /* > * This receiver use the reverse principle of all other DCF77 receivers I have > * seen implemented, instead of relying on the S/N to be good enough for the > * correct minute-synchronization to trivially stand out (ie: by the absense > * of the 59th second pulse), I instead start out with 60 possible hypothesis > * for where the minute starts, and disprove them as I collect bits. > * > * There are many features of the DCF77 timegram which can be checked even > * though we do not know what time/date it actually is. For instance a minute > * reading of 71 would obviously be wrong, as would illegal BCD digits, wrong > * parity or the two timezone bits being identical. > * > * It is possible to also check that the first 14 bits follow a particular > * pattern, they have been zero every single time I have looked but the > * PTB reserves the right to play with them. > * > * The principle behind this is based on the observation that noise almost > * always consist of missing pulses, and that '0' and '1' bit pulses very > * rarely gets confused. > * > * This method allows us to tighten the frontend filters much more than > * other receivers because we can tolerate a high ratio of missing pulses. > * > * It is interesting to note that this method does not even require a full > * minute worth of pulses before the top of the minute is uniquely determined: > * even though we only have one or two bits actually supporting it, all other > * possibilities have two or more bits rejecting them as possibilities. > * > */ > > > NTPns can be downloaded from here: > http://phk.freebsd.dk/NTPns/phkrel/ > From phk at phk.freebsd.dk Wed Jan 14 18:24:09 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 14 Jan 2009 18:24:09 +0000 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: Your message of "Wed, 14 Jan 2009 08:56:58 PST." <496E195A.1050107@pacific.net> Message-ID: <47792.1231957449@critter.freebsd.dk> In message <496E195A.1050107 at pacific.net>, Brooke Clarke writes: >My first problem is to hook the front end up to a couple of batteries >and a LED to find a good place for the antenna. Be aware that the AGC has a very long timeconstant, you should leave it powered up in one place for at least a couple of minute before passing judgement. If you have an "I" steel beam in your house, try putting the receiver on that, it boosts the ferrite antenna pickup by a lot. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From newell at cei.net Wed Jan 14 18:39:59 2009 From: newell at cei.net (Scott Newell) Date: Wed, 14 Jan 2009 12:39:59 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <47792.1231957449@critter.freebsd.dk> References: Message-ID: <200901141840.n0EIe1B8027108@mail960c35.nsolutionszone.com> At 12:24 PM 1/14/2009 , Poul-Henning Kamp wrote: >In message <496E195A.1050107 at pacific.net>, Brooke Clarke writes: > >>My first problem is to hook the front end up to a couple of batteries >>and a LED to find a good place for the antenna. > >Be aware that the AGC has a very long timeconstant, you should leave >it powered up in one place for at least a couple of minute before >passing judgement. Yep. I've noticed that mine can take several minutes from power up to pulses, even when the antenna is located in a known good spot. Kind of a shame they didn't use the unused bits in the WWVB stream for some kind of checksum or error correcting code. -- newell N5TNL From david at endor.com Wed Jan 14 19:52:32 2009 From: david at endor.com (David McGaw) Date: Wed, 14 Jan 2009 14:52:32 -0500 Subject: [time-nuts] GPS antenna gain Message-ID: <200901141952.n0EJqU3t024125@mailhub1.dartmouth.edu> Hello Gents (and Ladies), I am in a bit of a quandary. I have been using a Synergy Timing 3000 GPS antenna in a test set-up for some time and recently got a VIC-100 antenna, thinking that its greater spec-sheet gain (38dBi vs 25dB(i?) typical) would allow for a longer down-lead in the field if needed. Upon testing, the VIC-100 appears to have around 10dB LESS gain than the Timing 3000 and I would say is barely adequate on 25 ft of LMR-195! I used a switched attenuator pad with 2 DC blocks for the test and set each antenna to comparable SNR levels as indicated using TAC32 with an M12M-T. I have tried a second VIC-100 with the same results. Would anyone have an explanation for this? Thanks, David McGaw N1HAC From wittend at wwrinc.com Wed Jan 14 20:10:03 2009 From: wittend at wwrinc.com (David M. Witten II) Date: Wed, 14 Jan 2009 14:10:03 -0600 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: <200901141840.n0EIe1B8027108@mail960c35.nsolutionszone.com> References: <200901141840.n0EIe1B8027108@mail960c35.nsolutionszone.com> Message-ID: <496E469B.8010706@wwrinc.com> I'm glad to know that what I have been seeing is reasonable. I have had difficulty syncing to WWVB with embedded receivers before, so perhaps I will get a better signal from the top floor of my house. Here on ground level I never see it lock. Dave Witten Scott Newell wrote: > At 12:24 PM 1/14/2009 , Poul-Henning Kamp wrote: >> In message <496E195A.1050107 at pacific.net>, Brooke Clarke writes: >> >>> My first problem is to hook the front end up to a couple of batteries >>> and a LED to find a good place for the antenna. >> Be aware that the AGC has a very long timeconstant, you should leave >> it powered up in one place for at least a couple of minute before >> passing judgement. > > Yep. I've noticed that mine can take several minutes from power up to > pulses, even when the antenna is located in a known good spot. > > Kind of a shame they didn't use the unused bits in the WWVB stream for some > kind of checksum or error correcting code. > From tvb at LeapSecond.com Wed Jan 14 20:58:14 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 14 Jan 2009 12:58:14 -0800 Subject: [time-nuts] WWV / WWVH / WWVB References: <200901141840.n0EIe1B8027108@mail960c35.nsolutionszone.com> Message-ID: > Kind of a shame they didn't use the unused bits in the WWVB stream for some > kind of checksum or error correcting code. Not really. At just 1 baud and with questionable reception in many parts of the country, checksum bits aren't the answer. The usual WWVB trick is to collect as many minutes of data as you want in order to increase confidence in your decoded result. It allows you to pull a very weak signal out of the noise. This might be as little as 1 or 2 minutes; or depending on time and location, it might be 5 or 10 or more minutes. With this level of patient oversampling there are a number of software tricks one can employ to pull out an error-free timecode from incredibly weak or noisy signals. /tvb From james.p.lux at jpl.nasa.gov Wed Jan 14 21:05:20 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Wed, 14 Jan 2009 13:05:20 -0800 Subject: [time-nuts] WWV / WWVH / WWVB In-Reply-To: References: <200901141840.n0EIe1B8027108@mail960c35.nsolutionszone.com> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Tom Van Baak > Sent: Wednesday, January 14, 2009 12:58 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] WWV / WWVH / WWVB > > > Kind of a shame they didn't use the unused bits in the WWVB > stream for > > some kind of checksum or error correcting code. > > Not really. At just 1 baud and with questionable reception in > many parts of the country, checksum bits aren't the answer. > > The usual WWVB trick is to collect as many minutes of data as > you want in order to increase confidence in your decoded > result. It allows you to pull a very weak signal out of the noise. > > This might be as little as 1 or 2 minutes; or depending on > time and location, it might be 5 or 10 or more minutes. With > this level of patient oversampling there are a number of > software tricks one can employ to pull out an error-free > timecode from incredibly weak or noisy signals. It *is* effectively coded with forward error correction. Integrate for 10 minutes and you have a rate 1/10th code (considering a whole frame as one symbol) with a very simple coder (code symbol(i+1) = code symbol(i) + 1). (well, the code's a bit more complex, because it's BCD, etc.) From bruce.griffiths at xtra.co.nz Wed Jan 14 21:09:16 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 10:09:16 +1300 Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> Message-ID: <496E547C.2050408@xtra.co.nz> Hans Hans Rosenberg wrote: > Hi Time-nuts people, > > I'm new to this forum and really enjoyed reading all the design strategies on oscillators. > > I'm currently designing a low noise oscillator and I wonder if you can help me with some questions. I've attached a picture of the oscillator core I'm using. I decided to go for a Pierce design some time ago after looking at a few topologies. I took a number of measures to give the design a low 1/f noise. > > > 1. Low DC gain. There is a transformer in the drain line. > 2. Ultra low noise supply (not on the schematic) using an ad586 buried zener reference with a -3dB lowpass at 0.1Hz. This 5V reference is then increased to 12V using a low noise discrete buffer. > 3. The phase shift across T1 is only a few degrees (<5degrees), low phaseshift in the amplifier reduces 1/f noise. > 4. I chose a fet in order to minimize the load at the 'output' of the crystal, the only load I have now is the bias resistor of 100k. This resistor does cause low frequency noise (at higher frequencies C1 shorts it). This may be the problem in this circuit, Cgd is modulated by this noise and a low frequency voltage is applied at the gate, which is however not amplified because of the currentsource in the source line which should cause nearly infinite feedback for low frequencies making the DC gain even lower. > 5. The current source produces low frequency noise. I have to have a current source though (I could use a resistor but I calculated that produces more noise). I could increase the voltage across R5 and make R5 bigger to reduce the noise, however, this will reduce Vgd which means modulation of Cgd becomes worse. I think I'm ok here by dividing the voltage across the currentsource and the active oscillator element in half. Cgd of a J309 is around 2.5pF at Vds=10V (it is a little higher in my case since Vgd is lower) > 6. L2 can be mounted to accommodate overtone crystals. ( I still have to calculate a value for L2 and C2 to get the correct impedance at resonance) > 7. F1 and F2 are ferrite beads with a low impedance at DC (far less then an ohm) and rising impedance at higher frequencies to prevent oscillation of the RF transistors. > 8. I've found a really good overtonecrystal from Citizen. CM309S. I measured the unloaded Q to be 313000, the loaded Q (using simple estimation) should be around 280000 in the circuit. (C0=2.5pF, R=20Ohm, C1=0.75fF, L=29.444mH, can be aquired at digikey). The spec for Rs was <130Ohms, I guess reality is much better :-) > 9. The transformeroutputs are going to an isolationchain using 3 cascodes and then a discrete limiter not shown on the schematic. > 10. This whole oscillator core will be placed in an RF shielding can. The isolationchain will have a can of it's own to so pulling should be nearly eliminated. > > Now my questions are: > > > 1. I don't see a pierce design in any of the low noise oscillator circuits in the discussion threads about low noise oscillator design. Is there something fundamentally wrong about this topology? > 2. I read a few times that ferrites in inductors (and I assume transformers as well) can be a real problem for 1/f noise. I'm using a transformer (TC1-1t from minicircuits) which is made with a ferrite bead. Do you know of any transformers or inductors that have low 1/f noise ferrite material. > 3. Have I missed something fundamental in the design. The goal is to build a very good oscillator. I would like to achieve something like -110dBc/Hz at 10Hz distance at 33.8688MHz. > > Thanks in advance for having a look and best regards, > > Hans Rosenberg > > 1) A LED plus a BJT and resistor makes a much lower noise current source than a zener based reference plus a BJT and resistor. Some shielding of the LED from ambient light may be required as LEDs (as all PN junctions) are photosensitive. A resistor in series with an RF choke can be used to replace the current source. 2) A BJT with a correctly proportioned coupling network will not significantly load the crystal. 3) There is little isolation between the oscillator and the load, a slight change in topology will improve this. 4) Modified Pierce overtone crystal oscillators using JFETs were popular in the 1960's and 1970's. 5) The amplitude limiting mechanism in the oscillator is important as it affects the phase noise. 6) A lower noise audio BJT will make a much lower (flicker) noise current source than a 9GHz transistor. 7) Its usually better to use the crystal to filter the output signal. 8) One of the Driscoll BJT oscillators or a variant thereof is a good stating point. AGC via a varactor based attenuator can be used. The output signal can be extracted from the second transistor collector using a transformer with little interaction with the collector tank tuning. Bruce From bruce.griffiths at xtra.co.nz Wed Jan 14 21:13:34 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 10:13:34 +1300 Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <496E547C.2050408@xtra.co.nz> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> <496E547C.2050408@xtra.co.nz> Message-ID: <496E557E.2040604@xtra.co.nz> Bruce Griffiths wrote: > Hans > > Hans Rosenberg wrote: > >> Hi Time-nuts people, >> >> I'm new to this forum and really enjoyed reading all the design strategies on oscillators. >> >> I'm currently designing a low noise oscillator and I wonder if you can help me with some questions. I've attached a picture of the oscillator core I'm using. I decided to go for a Pierce design some time ago after looking at a few topologies. I took a number of measures to give the design a low 1/f noise. >> >> >> 1. Low DC gain. There is a transformer in the drain line. >> 2. Ultra low noise supply (not on the schematic) using an ad586 buried zener reference with a -3dB lowpass at 0.1Hz. This 5V reference is then increased to 12V using a low noise discrete buffer. >> 3. The phase shift across T1 is only a few degrees (<5degrees), low phaseshift in the amplifier reduces 1/f noise. >> 4. I chose a fet in order to minimize the load at the 'output' of the crystal, the only load I have now is the bias resistor of 100k. This resistor does cause low frequency noise (at higher frequencies C1 shorts it). This may be the problem in this circuit, Cgd is modulated by this noise and a low frequency voltage is applied at the gate, which is however not amplified because of the currentsource in the source line which should cause nearly infinite feedback for low frequencies making the DC gain even lower. >> 5. The current source produces low frequency noise. I have to have a current source though (I could use a resistor but I calculated that produces more noise). I could increase the voltage across R5 and make R5 bigger to reduce the noise, however, this will reduce Vgd which means modulation of Cgd becomes worse. I think I'm ok here by dividing the voltage across the currentsource and the active oscillator element in half. Cgd of a J309 is around 2.5pF at Vds=10V (it is a little higher in my case since Vgd is lower) >> 6. L2 can be mounted to accommodate overtone crystals. ( I still have to calculate a value for L2 and C2 to get the correct impedance at resonance) >> 7. F1 and F2 are ferrite beads with a low impedance at DC (far less then an ohm) and rising impedance at higher frequencies to prevent oscillation of the RF transistors. >> 8. I've found a really good overtonecrystal from Citizen. CM309S. I measured the unloaded Q to be 313000, the loaded Q (using simple estimation) should be around 280000 in the circuit. (C0=2.5pF, R=20Ohm, C1=0.75fF, L=29.444mH, can be aquired at digikey). The spec for Rs was <130Ohms, I guess reality is much better :-) >> 9. The transformeroutputs are going to an isolationchain using 3 cascodes and then a discrete limiter not shown on the schematic. >> 10. This whole oscillator core will be placed in an RF shielding can. The isolationchain will have a can of it's own to so pulling should be nearly eliminated. >> >> Now my questions are: >> >> >> 1. I don't see a pierce design in any of the low noise oscillator circuits in the discussion threads about low noise oscillator design. Is there something fundamentally wrong about this topology? >> 2. I read a few times that ferrites in inductors (and I assume transformers as well) can be a real problem for 1/f noise. I'm using a transformer (TC1-1t from minicircuits) which is made with a ferrite bead. Do you know of any transformers or inductors that have low 1/f noise ferrite material. >> 3. Have I missed something fundamental in the design. The goal is to build a very good oscillator. I would like to achieve something like -110dBc/Hz at 10Hz distance at 33.8688MHz. >> >> Thanks in advance for having a look and best regards, >> >> Hans Rosenberg >> >> >> > 1) A LED plus a BJT and resistor makes a much lower noise current source > than a zener based reference plus a BJT and resistor. > Some shielding of the LED from ambient light may be required as LEDs (as > all PN junctions) are photosensitive. > A resistor in series with an RF choke can be used to replace the current > source. > > 2) A BJT with a correctly proportioned coupling network will not > significantly load the crystal. > > 3) There is little isolation between the oscillator and the load, a > slight change in topology will improve this. > > 4) Modified Pierce overtone crystal oscillators using JFETs were popular > in the 1960's and 1970's. > > 5) The amplitude limiting mechanism in the oscillator is important as it > affects the phase noise. > > 6) A lower noise audio BJT will make a much lower (flicker) noise > current source than a 9GHz transistor. > > 7) Its usually better to use the crystal to filter the output signal. > > 8) One of the Driscoll BJT oscillators or a variant thereof is a good > stating point. > AGC via a varactor based attenuator can be used. > The output signal can be extracted from the second transistor collector > using a transformer with little interaction with the collector tank tuning. > > > Bruce > > Addendum 9) Having a dc voltage across the crystal isnt a good idea as it can lead to unwanted phase modulation. 10) The current source transistor collector base voltage seems a little low. Bruce From tvb at LeapSecond.com Wed Jan 14 21:36:18 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 14 Jan 2009 13:36:18 -0800 Subject: [time-nuts] Noise types and Allan Deviation Message-ID: A number of you have asked about Allan deviation recently so I thought I'd share this handy one-page chart that shows both ADEV and MDEV for the following noise types: - white phase - flicker phase - white frequency - flicker frequency - random walk frequency http://www.leapsecond.com/notes/Exploring_Allan_Deviation.pdf It's in high resolution PDF format so if it looks blurry on your screen either zoom by 2x or just print it on a laser printer. /tvb From bruce.griffiths at xtra.co.nz Wed Jan 14 21:41:07 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 10:41:07 +1300 Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <496E557E.2040604@xtra.co.nz> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> <496E547C.2050408@xtra.co.nz> <496E557E.2040604@xtra.co.nz> Message-ID: <496E5BF3.4000500@xtra.co.nz> Bruce Griffiths wrote: > Bruce Griffiths wrote: > >> Hans >> >> Hans Rosenberg wrote: >> >> >>> Hi Time-nuts people, >>> >>> I'm new to this forum and really enjoyed reading all the design strategies on oscillators. >>> >>> I'm currently designing a low noise oscillator and I wonder if you can help me with some questions. I've attached a picture of the oscillator core I'm using. I decided to go for a Pierce design some time ago after looking at a few topologies. I took a number of measures to give the design a low 1/f noise. >>> >>> >>> 1. Low DC gain. There is a transformer in the drain line. >>> 2. Ultra low noise supply (not on the schematic) using an ad586 buried zener reference with a -3dB lowpass at 0.1Hz. This 5V reference is then increased to 12V using a low noise discrete buffer. >>> 3. The phase shift across T1 is only a few degrees (<5degrees), low phaseshift in the amplifier reduces 1/f noise. >>> 4. I chose a fet in order to minimize the load at the 'output' of the crystal, the only load I have now is the bias resistor of 100k. This resistor does cause low frequency noise (at higher frequencies C1 shorts it). This may be the problem in this circuit, Cgd is modulated by this noise and a low frequency voltage is applied at the gate, which is however not amplified because of the currentsource in the source line which should cause nearly infinite feedback for low frequencies making the DC gain even lower. >>> 5. The current source produces low frequency noise. I have to have a current source though (I could use a resistor but I calculated that produces more noise). I could increase the voltage across R5 and make R5 bigger to reduce the noise, however, this will reduce Vgd which means modulation of Cgd becomes worse. I think I'm ok here by dividing the voltage across the currentsource and the active oscillator element in half. Cgd of a J309 is around 2.5pF at Vds=10V (it is a little higher in my case since Vgd is lower) >>> 6. L2 can be mounted to accommodate overtone crystals. ( I still have to calculate a value for L2 and C2 to get the correct impedance at resonance) >>> 7. F1 and F2 are ferrite beads with a low impedance at DC (far less then an ohm) and rising impedance at higher frequencies to prevent oscillation of the RF transistors. >>> 8. I've found a really good overtonecrystal from Citizen. CM309S. I measured the unloaded Q to be 313000, the loaded Q (using simple estimation) should be around 280000 in the circuit. (C0=2.5pF, R=20Ohm, C1=0.75fF, L=29.444mH, can be aquired at digikey). The spec for Rs was <130Ohms, I guess reality is much better :-) >>> 9. The transformeroutputs are going to an isolationchain using 3 cascodes and then a discrete limiter not shown on the schematic. >>> 10. This whole oscillator core will be placed in an RF shielding can. The isolationchain will have a can of it's own to so pulling should be nearly eliminated. >>> >>> Now my questions are: >>> >>> >>> 1. I don't see a pierce design in any of the low noise oscillator circuits in the discussion threads about low noise oscillator design. Is there something fundamentally wrong about this topology? >>> 2. I read a few times that ferrites in inductors (and I assume transformers as well) can be a real problem for 1/f noise. I'm using a transformer (TC1-1t from minicircuits) which is made with a ferrite bead. Do you know of any transformers or inductors that have low 1/f noise ferrite material. >>> 3. Have I missed something fundamental in the design. The goal is to build a very good oscillator. I would like to achieve something like -110dBc/Hz at 10Hz distance at 33.8688MHz. >>> >>> Thanks in advance for having a look and best regards, >>> >>> Hans Rosenberg >>> >>> >>> >>> >> 1) A LED plus a BJT and resistor makes a much lower noise current source >> than a zener based reference plus a BJT and resistor. >> Some shielding of the LED from ambient light may be required as LEDs (as >> all PN junctions) are photosensitive. >> A resistor in series with an RF choke can be used to replace the current >> source. >> >> 2) A BJT with a correctly proportioned coupling network will not >> significantly load the crystal. >> >> 3) There is little isolation between the oscillator and the load, a >> slight change in topology will improve this. >> >> 4) Modified Pierce overtone crystal oscillators using JFETs were popular >> in the 1960's and 1970's. >> >> 5) The amplitude limiting mechanism in the oscillator is important as it >> affects the phase noise. >> >> 6) A lower noise audio BJT will make a much lower (flicker) noise >> current source than a 9GHz transistor. >> >> 7) Its usually better to use the crystal to filter the output signal. >> >> 8) One of the Driscoll BJT oscillators or a variant thereof is a good >> stating point. >> AGC via a varactor based attenuator can be used. >> The output signal can be extracted from the second transistor collector >> using a transformer with little interaction with the collector tank tuning. >> >> >> Bruce >> >> >> > Addendum > > 9) Having a dc voltage across the crystal isnt a good idea as it can > lead to unwanted phase modulation. > > > 10) The current source transistor collector base voltage seems a little low. > > Bruce > > Addendum II 11) A common base cascade will have much lower noise than a cascode chain, however the CB cascade needs a current input. This can be derived in your modified Pierce circuit by connecting C1 to the emitter of the input CB transistor rather than to ground. The transformer is then not required. A lower impedance input at the CB stage emitter can be achieved by replacing the Cb transistor by a CECB feedback pair. Whats the limiter circuit? Is it at the cascode buffer chain output? Bruce From bruce.griffiths at xtra.co.nz Wed Jan 14 21:49:03 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 10:49:03 +1300 Subject: [time-nuts] Noise types and Allan Deviation In-Reply-To: References: Message-ID: <496E5DCF.1030803@xtra.co.nz> Tom Van Baak wrote: > A number of you have asked about Allan deviation recently so > I thought I'd share this handy one-page chart that shows both > ADEV and MDEV for the following noise types: > > - white phase > - flicker phase > - white frequency > - flicker frequency > - random walk frequency > > http://www.leapsecond.com/notes/Exploring_Allan_Deviation.pdf > > It's in high resolution PDF format so if it looks blurry on your > screen either zoom by 2x or just print it on a laser printer. > > /tvb > > > > Tom A table indicating the dependence of the ADEV of these phase noise types on the measurement system bandwidth would also be helpful. There seems to be some general confusion about this. In general, the measured ADEV, MDEV, etc., depends both on the phase noise characteristics of the 2 oscillators being compared and on the measurement system characteristics. Thus without correction for the effect of the measurement system noise bandwidth, 2 different measurement systems measuring the same oscillator pair will produce different results even though both measurement systems are working correctly. Bruce From magnus at rubidium.dyndns.org Wed Jan 14 21:53:19 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 14 Jan 2009 22:53:19 +0100 Subject: [time-nuts] Noise types and Allan Deviation In-Reply-To: References: Message-ID: <496E5ECF.8040205@rubidium.dyndns.org> Tom Van Baak skrev: > A number of you have asked about Allan deviation recently so > I thought I'd share this handy one-page chart that shows both > ADEV and MDEV for the following noise types: > > - white phase > - flicker phase > - white frequency > - flicker frequency > - random walk frequency > > http://www.leapsecond.com/notes/Exploring_Allan_Deviation.pdf > > It's in high resolution PDF format so if it looks blurry on your > screen either zoom by 2x or just print it on a laser printer. You should notice that the phase data looks more or less the same as the frequency data two steps down. This is not a coincident, this is because there is a derivation/integration (depending on which direction you go) relationship between them. Also notice that the Allan Deviation and Modified Allan deviation is shown as Frequency Stability plots, where as if there would have been a phase stability plot it would use the Time Deviation (TDEV) meaure. There is no TDEV equalent based on ADEV as there is with MDEV, but it should be pretty straightforward to convert it in an analogous fashion. Educational and helpfull. Good work Tom! Cheers, Magnus From magnus at rubidium.dyndns.org Wed Jan 14 22:09:12 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 14 Jan 2009 23:09:12 +0100 Subject: [time-nuts] Noise types and Allan Deviation In-Reply-To: <496E5DCF.1030803@xtra.co.nz> References: <496E5DCF.1030803@xtra.co.nz> Message-ID: <496E6288.8070908@rubidium.dyndns.org> Bruce, Bruce Griffiths skrev: > Tom Van Baak wrote: >> A number of you have asked about Allan deviation recently so >> I thought I'd share this handy one-page chart that shows both >> ADEV and MDEV for the following noise types: >> >> - white phase >> - flicker phase >> - white frequency >> - flicker frequency >> - random walk frequency >> >> http://www.leapsecond.com/notes/Exploring_Allan_Deviation.pdf >> >> It's in high resolution PDF format so if it looks blurry on your >> screen either zoom by 2x or just print it on a laser printer. >> >> /tvb >> >> >> >> > Tom > > A table indicating the dependence of the ADEV of these phase noise types > on the measurement system bandwidth would also be helpful. > > There seems to be some general confusion about this. > In general, the measured ADEV, MDEV, etc., depends both on the phase > noise characteristics of the 2 oscillators being compared and on the > measurement system characteristics. > > Thus without correction for the effect of the measurement system noise > bandwidth, 2 different measurement systems measuring the same oscillator > pair will produce different results even though both measurement systems > are working correctly. There is yeat more effects which may compromise the measurement. Length of measurement is certainly an issue. Stefano Bregni have made alot of analysis on this as apparent in his book and in his articles. ITU-T specifies that the measurement windown needs to be at least 12 times longer than the highest tau being measured. Similarly, there is a requirement on lower end of the tau scale. The number of samples used in the gliding window will affect the values computed compared to expected value. The use of drift rate compensation is yeat another issue. So the lack of annotated bandwidth is just one of several omissions that will tweak data of the chart. There is more issues to be included for real measures. I would point out some other peculiarities in the data. Cheers, Magnus From cdelect at juno.com Wed Jan 14 22:30:24 2009 From: cdelect at juno.com (Corby Dawson) Date: Wed, 14 Jan 2009 14:30:24 -0800 Subject: [time-nuts] FTS Datum 1000A-100 Message-ID: <20090114.143024.1356.1.cdelect@juno.com> Hi, I have an FTS 1000A-100 oscillator that takes +24VDC on one pin and +15VDC on another to operate. Does anyone have a data sheet that gives the power supply ranges? I like to know if they overlap so I can supply both pins from the same supply. Thanks, Corby Dawson ____________________________________________________________ Click for information on obtaining a VA loan. http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2QL2rPCB5lmLTwasvgHBSosrnEzRWJYlQIBoppIBkfh1oGF/ From bruce.griffiths at xtra.co.nz Wed Jan 14 22:46:07 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 11:46:07 +1300 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <20090114.143024.1356.1.cdelect@juno.com> References: <20090114.143024.1356.1.cdelect@juno.com> Message-ID: <496E6B2F.7030401@xtra.co.nz> Corby Dawson wrote: > Hi, > > I have an FTS 1000A-100 oscillator that takes +24VDC on one pin and > +15VDC on another to operate. > > Does anyone have a data sheet that gives the power supply ranges? > > I like to know if they overlap so I can supply both pins from the same > supply. > > Thanks, > > Corby Dawson > Corby Whilst the data sheet I have doesn't include the dual supply variation of the OCXO, it does indicate that the range of the nominal 24V supply is 22 to 30V. The 15V supply is probably for the oscillator (and maybe the buffer amplifiers) and is unlikely to have a maximum input rating of 22V so you will need to use a low noise regulator to drop the 24V supply to 15V. Bruce From John.Reid at team.telstra.com Wed Jan 14 23:20:57 2009 From: John.Reid at team.telstra.com (Reid, John H) Date: Thu, 15 Jan 2009 10:20:57 +1100 Subject: [time-nuts] GPS antenna gain In-Reply-To: References: Message-ID: Message: 3 Date: Wed, 14 Jan 2009 14:52:32 -0500 Hello Gents (and Ladies), I am in a bit of a quandary. I have been using a Synergy Timing 3000 GPS antenna in a test set-up for some time and recently got a VIC-100 antenna, thinking that its greater spec-sheet gain (38dBi vs 25dB(i?) typical) would allow for a longer down-lead in the field if needed. Upon testing, the VIC-100 appears to have around 10dB LESS gain than the Timing 3000 and I would say is barely adequate on 25 ft of LMR-195! I used a switched attenuator pad with 2 DC blocks for the test and set each antenna to comparable SNR levels as indicated using TAC32 with an M12M-T. I have tried a second VIC-100 with the same results. Would anyone have an explanation for this? David, the VIC-100 is an amplified antenna, and needs DC continuity on the antenna cable. The Navtech description is "VIC-100 Active Antenna", 'active' in this case being the giveaway. Regards, John. From bruce.griffiths at xtra.co.nz Wed Jan 14 23:28:29 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 12:28:29 +1300 Subject: [time-nuts] GPS antenna gain In-Reply-To: References: Message-ID: <496E751D.9010807@xtra.co.nz> Reid, John H wrote: > Message: 3 > Date: Wed, 14 Jan 2009 14:52:32 -0500 > > Hello Gents (and Ladies), > > I am in a bit of a quandary. I have been using a Synergy Timing 3000 > GPS antenna in a test set-up for some time and recently got a VIC-100 > antenna, thinking that its greater spec-sheet gain (38dBi vs 25dB(i?) > typical) would allow for a longer down-lead in the field if > needed. Upon testing, the VIC-100 appears to have around 10dB LESS > gain than the Timing 3000 and I would say is barely adequate on 25 ft > of LMR-195! I used a switched attenuator pad with 2 DC blocks for > the test and set each antenna to comparable SNR levels as indicated > using TAC32 with an M12M-T. I have tried a second VIC-100 with the > same results. Would anyone have an explanation for this? > > David, > > the VIC-100 is an amplified antenna, and needs DC continuity on the antenna cable. > The Navtech description is "VIC-100 Active Antenna", 'active' in this case being the giveaway. > > Regards, > John. > > > John They are both (VIC100 (20mA typical) and Synergy timing 3000 (26mA typical)) active antennas requiring a +5V dc supply on the inner coax conductor. Bruce From swithrow at idcomm.com Wed Jan 14 23:58:09 2009 From: swithrow at idcomm.com (Skip Withrow) Date: Wed, 14 Jan 2009 16:58:09 -0700 Subject: [time-nuts] FEI FE-5680B pinout? Message-ID: <20090114235809.46B2A6EFBC3C@mailhost.idcomm.com> Looks like I have uncoverd another version for the FE-5680. This unit is marked FE-5680B, and has a high-density DB-15 connector (like computer video). Manufacture date looks like 2004, FEI p/n is 261600-51604. Anyone have a clue as to pinout? Thanks in advance. BTW, Google search of FE-5680B produces abosutely zero results (as does looking at the FEI website). Skip Withrow From bruce.griffiths at xtra.co.nz Thu Jan 15 00:04:46 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 13:04:46 +1300 Subject: [time-nuts] Noise types and Allan Deviation In-Reply-To: <496E6288.8070908@rubidium.dyndns.org> References: <496E5DCF.1030803@xtra.co.nz> <496E6288.8070908@rubidium.dyndns.org> Message-ID: <496E7D9E.8000608@xtra.co.nz> Magnus Danielson wrote: > Bruce, > > Bruce Griffiths skrev: > >> Tom Van Baak wrote: >> >>> A number of you have asked about Allan deviation recently so >>> I thought I'd share this handy one-page chart that shows both >>> ADEV and MDEV for the following noise types: >>> >>> - white phase >>> - flicker phase >>> - white frequency >>> - flicker frequency >>> - random walk frequency >>> >>> http://www.leapsecond.com/notes/Exploring_Allan_Deviation.pdf >>> >>> It's in high resolution PDF format so if it looks blurry on your >>> screen either zoom by 2x or just print it on a laser printer. >>> >>> /tvb >>> >>> >>> >>> >>> >> Tom >> >> A table indicating the dependence of the ADEV of these phase noise types >> on the measurement system bandwidth would also be helpful. >> >> There seems to be some general confusion about this. >> In general, the measured ADEV, MDEV, etc., depends both on the phase >> noise characteristics of the 2 oscillators being compared and on the >> measurement system characteristics. >> >> Thus without correction for the effect of the measurement system noise >> bandwidth, 2 different measurement systems measuring the same oscillator >> pair will produce different results even though both measurement systems >> are working correctly. >> > > There is yeat more effects which may compromise the measurement. Length > of measurement is certainly an issue. Stefano Bregni have made alot of > analysis on this as apparent in his book and in his articles. ITU-T > specifies that the measurement windown needs to be at least 12 times > longer than the highest tau being measured. Similarly, there is a > requirement on lower end of the tau scale. The number of samples used in > the gliding window will affect the values computed compared to expected > value. The use of drift rate compensation is yeat another issue. > > So the lack of annotated bandwidth is just one of several omissions that > will tweak data of the chart. There is more issues to be included for > real measures. I would point out some other peculiarities in the data. > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Hej Magnus For the range of tau where phase noise processes such as flicker phase noise, random walk phase noise, etc., dominate the measured values of ADEV, MDEV etc, then the results are largely independent of the measurement system bandwidth characteristics. Thus results obtained by different measurement systems should agree in this region (provided that the measurement system noise floor is sufficiently small). Bruce From tvb at LeapSecond.com Thu Jan 15 01:27:16 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 14 Jan 2009 17:27:16 -0800 Subject: [time-nuts] Noise types and Allan Deviation References: <496E5DCF.1030803@xtra.co.nz> Message-ID: <13A73872892F4A44B70A42F002CEC96B@pc52> > A table indicating the dependence of the ADEV of these phase noise types > on the measurement system bandwidth would also be helpful. Bruce, I've never bothered with the details of measurement system bandwidth as you describe. A couple of reasons. 1) Almost none of the thousand ADEV plots I've ever seen in commercial and academic literature ever mentions it. That's my first clue it might be a "Bruce thing" ;-) 2) It looks like it's a pain to compute, and if it doesn't end up making any difference then it's not worth the bother. 3) If you take NEQ BW into account you can see when it makes a difference and, as important, when it doesn't. Here's a nice example from last week: http://www.leapsecond.com/pages/tbolt-tc/tbolt-tbolt-neq-1.gif It's the ADEV of two non-optimized TBolt's against each other on a TSC 5120A (which allows you a selection of NEQ BW) The good news for you is that there are data points where the measurement bandwidth makes a difference. See tau 0.01 and 0.02 for example. The better news is that for the rest of the plot, all the way from tau 0.1 to 100 000 seconds, it makes no difference at all, not even one pixel. /tvb From kirbybq at bellsouth.net Thu Jan 15 01:45:40 2009 From: kirbybq at bellsouth.net (Brian Kirby) Date: Wed, 14 Jan 2009 19:45:40 -0600 Subject: [time-nuts] GPS antenna gain In-Reply-To: <200901141952.n0EJqU3t024125@mailhub1.dartmouth.edu> References: <200901141952.n0EJqU3t024125@mailhub1.dartmouth.edu> Message-ID: <496E9544.2040603@bellsouth.net> Can we clarify, you were using the DC blocks or were they power inserters ? Brian David McGaw wrote: > Hello Gents (and Ladies), > > I am in a bit of a quandary. I have been using a Synergy Timing 3000 > GPS antenna in a test set-up for some time and recently got a VIC-100 > antenna, thinking that its greater spec-sheet gain (38dBi vs 25dB(i?) > typical) would allow for a longer down-lead in the field if > needed. Upon testing, the VIC-100 appears to have around 10dB LESS > gain than the Timing 3000 and I would say is barely adequate on 25 ft > of LMR-195! I used a switched attenuator pad with 2 DC blocks for > the test and set each antenna to comparable SNR levels as indicated > using TAC32 with an M12M-T. I have tried a second VIC-100 with the > same results. Would anyone have an explanation for this? > > Thanks, > > David McGaw N1HAC > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From kirbybq at bellsouth.net Thu Jan 15 01:50:18 2009 From: kirbybq at bellsouth.net (Brian Kirby) Date: Wed, 14 Jan 2009 19:50:18 -0600 Subject: [time-nuts] GPS antenna gain In-Reply-To: <496E9544.2040603@bellsouth.net> References: <200901141952.n0EJqU3t024125@mailhub1.dartmouth.edu> <496E9544.2040603@bellsouth.net> Message-ID: <496E965A.2090105@bellsouth.net> And I did not make myself clear. If you were using power inserters, I expect one was used coming from your GPS receiver and you shunted the DC voltage around the attenuator and re-inserted DC voltage back to the antenna. Brian Kirby wrote: > Can we clarify, you were using the DC blocks or were they power inserters ? > > Brian > > David McGaw wrote: >> Hello Gents (and Ladies), >> >> I am in a bit of a quandary. I have been using a Synergy Timing 3000 >> GPS antenna in a test set-up for some time and recently got a VIC-100 >> antenna, thinking that its greater spec-sheet gain (38dBi vs 25dB(i?) >> typical) would allow for a longer down-lead in the field if >> needed. Upon testing, the VIC-100 appears to have around 10dB LESS >> gain than the Timing 3000 and I would say is barely adequate on 25 ft >> of LMR-195! I used a switched attenuator pad with 2 DC blocks for >> the test and set each antenna to comparable SNR levels as indicated >> using TAC32 with an M12M-T. I have tried a second VIC-100 with the >> same results. Would anyone have an explanation for this? >> >> Thanks, >> >> David McGaw N1HAC >> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From KFIam640 at aol.com Thu Jan 15 03:07:33 2009 From: KFIam640 at aol.com (KFIam640 at aol.com) Date: Wed, 14 Jan 2009 22:07:33 EST Subject: [time-nuts] WWV / WWVH / WWVB Message-ID: Here in Southern California I find my WWVB loopstick antenna works best when placed on the ground, the cement floor in my garage. Marvin Collins, W6OQI In a message dated 1/14/2009 12:10:56 P.M. Pacific Standard Time, wittend at wwrinc.com writes: I'm glad to know that what I have been seeing is reasonable. I have had difficulty syncing to WWVB with embedded receivers before, so perhaps I will get a better signal from the top floor of my house. Here on ground level I never see it lock. Dave Witten **************A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100000075x1215855013x1201028747/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=De cemailfooterNO62) From david at endor.com Thu Jan 15 03:23:57 2009 From: david at endor.com (David McGaw) Date: Wed, 14 Jan 2009 22:23:57 -0500 Subject: [time-nuts] GPS antenna gain In-Reply-To: <496E965A.2090105@bellsouth.net> References: <200901141952.n0EJqU3t024125@mailhub1.dartmouth.edu> <496E9544.2040603@bellsouth.net> <496E965A.2090105@bellsouth.net> Message-ID: <200901150323.n0F3NtUe007660@mailhub24.dartmouth.edu> Yes, more correctly I used 2 power inserters, one each way, to shunt the antenna power around the attenuator so that the antenna is powered and the GPS receiver sees the antenna as connected. David At 08:50 PM 1/14/2009, you wrote: >And I did not make myself clear. > >If you were using power inserters, I expect one was used coming from >your GPS receiver and you shunted the DC voltage around the attenuator >and re-inserted DC voltage back to the antenna. > > > >Brian Kirby wrote: > > Can we clarify, you were using the DC blocks or were they power inserters ? > > > > Brian > > > > David McGaw wrote: > >> Hello Gents (and Ladies), > >> > >> I am in a bit of a quandary. I have been using a Synergy Timing 3000 > >> GPS antenna in a test set-up for some time and recently got a VIC-100 > >> antenna, thinking that its greater spec-sheet gain (38dBi vs 25dB(i?) > >> typical) would allow for a longer down-lead in the field if > >> needed. Upon testing, the VIC-100 appears to have around 10dB LESS > >> gain than the Timing 3000 and I would say is barely adequate on 25 ft > >> of LMR-195! I used a switched attenuator pad with 2 DC blocks for > >> the test and set each antenna to comparable SNR levels as indicated > >> using TAC32 with an M12M-T. I have tried a second VIC-100 with the > >> same results. Would anyone have an explanation for this? > >> > >> Thanks, > >> > >> David McGaw N1HAC > >> > >> > >> > >> _______________________________________________ > >> time-nuts mailing list -- time-nuts at febo.com > >> To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >> and follow the instructions there. > >> > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From bruce.griffiths at xtra.co.nz Thu Jan 15 03:59:35 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 16:59:35 +1300 Subject: [time-nuts] Noise types and Allan Deviation In-Reply-To: <13A73872892F4A44B70A42F002CEC96B@pc52> References: <496E5DCF.1030803@xtra.co.nz> <13A73872892F4A44B70A42F002CEC96B@pc52> Message-ID: <496EB4A7.2050201@xtra.co.nz> Tom Van Baak wrote: >> A table indicating the dependence of the ADEV of these phase noise types >> on the measurement system bandwidth would also be helpful. >> > > Bruce, > > I've never bothered with the details of measurement system > bandwidth as you describe. A couple of reasons. > > 1) Almost none of the thousand ADEV plots I've ever seen in > commercial and academic literature ever mentions it. That's > my first clue it might be a "Bruce thing" ;-) > > 2) It looks like it's a pain to compute, and if it doesn't end up > making any difference then it's not worth the bother. > > 3) If you take NEQ BW into account you can see when it > makes a difference and, as important, when it doesn't. > > Here's a nice example from last week: > > http://www.leapsecond.com/pages/tbolt-tc/tbolt-tbolt-neq-1.gif > > It's the ADEV of two non-optimized TBolt's against each other > on a TSC 5120A (which allows you a selection of NEQ BW) > > The good news for you is that there are data points where the > measurement bandwidth makes a difference. See tau 0.01 > and 0.02 for example. > > The better news is that for the rest of the plot, all the way from > tau 0.1 to 100 000 seconds, it makes no difference at all, not > even one pixel. > > /tvb > > > Tom The tau range for which the measured ADEV etc are relatively independent of measurement system bandwidth will depend on when the phase noise processes for which ADEV etc are bandwidth independent become dominant. It should be true for larger tau when flicker phase and more divergent phase noise mechanisms dominate, but the lower limit will vary depending on the characteristics of the sources involved. One can either measure the phase noise at very low offsets and calculate MDEV etc to identify when the various noise processes dominate and thus infer the minimum vale of tau for which ADEV, MDEV etc are independent of the measurement system bandwidth, or vary the measurement system bandwidth to see if the measurements change. The tau range for which ADEV etc are sensibly independent of measurement system bandwidth should differ significantly when comparing a pair of hydrogen masers or a pair of low noise OCXOs (OSA8607, FTS1200 etc). The lower limit for an 8607 or a good FTS1200 is probably in the 1 to 10s range. That is around the value of tau for which ADEV vs tau first approximates a horizontal straight line or reaches a minimum. Bruce From bruce.griffiths at xtra.co.nz Thu Jan 15 04:22:29 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 17:22:29 +1300 Subject: [time-nuts] Noise types and Allan Deviation In-Reply-To: <13A73872892F4A44B70A42F002CEC96B@pc52> References: <496E5DCF.1030803@xtra.co.nz> <13A73872892F4A44B70A42F002CEC96B@pc52> Message-ID: <496EBA05.1010704@xtra.co.nz> Tom Van Baak wrote: >> A table indicating the dependence of the ADEV of these phase noise types >> on the measurement system bandwidth would also be helpful. >> > > Bruce, > > I've never bothered with the details of measurement system > bandwidth as you describe. A couple of reasons. > > 1) Almost none of the thousand ADEV plots I've ever seen in > commercial and academic literature ever mentions it. That's > my first clue it might be a "Bruce thing" ;-) > > 2) It looks like it's a pain to compute, and if it doesn't end up > making any difference then it's not worth the bother. > The TSC5120A calculates it for you. It can be difficult to do when using a time interval counter in some systems. However the noise bandwidth of a classical dual mixer system is well defined and easy to calculate. > 3) If you take NEQ BW into account you can see when it > makes a difference and, as important, when it doesn't. > > Here's a nice example from last week: > > http://www.leapsecond.com/pages/tbolt-tc/tbolt-tbolt-neq-1.gif > > It's the ADEV of two non-optimized TBolt's against each other > on a TSC 5120A (which allows you a selection of NEQ BW) > > The good news for you is that there are data points where the > measurement bandwidth makes a difference. See tau 0.01 > and 0.02 for example. > > The better news is that for the rest of the plot, all the way from > tau 0.1 to 100 000 seconds, it makes no difference at all, not > even one pixel. > > /tvb > > > > Tom When white phase modulation and flicker phase modulation are not the dominant phase noise processes and white FM, flicker FM or random walk FM dominate then the measured ADEV, MDEV will be independent of the measurement system bandwidth. This has implications for constructing an ADEV standard. If a white phase noise source is used the resultant ADEV etc measurements will depend on the measurement system noise bandwidth. However if white FM phase noise is added the resultant ADEV etc measurements will be independent of the measurement system bandwidth, however this is somewhat more difficult to implement. Bruce From david at endor.com Thu Jan 15 05:08:39 2009 From: david at endor.com (David McGaw) Date: Thu, 15 Jan 2009 00:08:39 -0500 Subject: [time-nuts] GPS antenna gain In-Reply-To: <200901150323.n0F3NtUe007660@mailhub24.dartmouth.edu> References: <200901141952.n0EJqU3t024125@mailhub1.dartmouth.edu> <496E9544.2040603@bellsouth.net> <496E965A.2090105@bellsouth.net> <200901150323.n0F3NtUe007660@mailhub24.dartmouth.edu> Message-ID: <200901150508.n0F58Z2a025734@mailhub1.dartmouth.edu> OK, lesson learned: check all conditions. The test system was feeding 3V rather than 5V to the antenna. Once the correct voltage is used, the characteristics make more sense. In fact, with a 25 ft. LMR-195 lead-in the VIC-100 gives almost unchanged SNR with 25dB attenuation added, -3dB with 30dB attenuation. The Timing 3000 shows -3dB change in SNR with 10 dB attenuation - quite a difference. David At 10:23 PM 1/14/2009, you wrote: >Yes, more correctly I used 2 power inserters, one each way, to shunt >the antenna power around the attenuator so that the antenna is >powered and the GPS receiver sees the antenna as connected. > >David > >At 08:50 PM 1/14/2009, you wrote: > >And I did not make myself clear. > > > >If you were using power inserters, I expect one was used coming from > >your GPS receiver and you shunted the DC voltage around the attenuator > >and re-inserted DC voltage back to the antenna. > > > > > > > >Brian Kirby wrote: > > > Can we clarify, you were using the DC blocks or were they power > inserters ? > > > > > > Brian > > > > > > David McGaw wrote: > > >> Hello Gents (and Ladies), > > >> > > >> I am in a bit of a quandary. I have been using a Synergy Timing 3000 > > >> GPS antenna in a test set-up for some time and recently got a VIC-100 > > >> antenna, thinking that its greater spec-sheet gain (38dBi vs 25dB(i?) > > >> typical) would allow for a longer down-lead in the field if > > >> needed. Upon testing, the VIC-100 appears to have around 10dB LESS > > >> gain than the Timing 3000 and I would say is barely adequate on 25 ft > > >> of LMR-195! I used a switched attenuator pad with 2 DC blocks for > > >> the test and set each antenna to comparable SNR levels as indicated > > >> using TAC32 with an M12M-T. I have tried a second VIC-100 with the > > >> same results. Would anyone have an explanation for this? > > >> > > >> Thanks, > > >> > > >> David McGaw N1HAC > > >> > > >> > > >> > > >> _______________________________________________ > > >> time-nuts mailing list -- time-nuts at febo.com > > >> To unsubscribe, go to > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > >> and follow the instructions there. > > >> > > > > > > _______________________________________________ > > > time-nuts mailing list -- time-nuts at febo.com > > > To unsubscribe, go to > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > > and follow the instructions there. > > > > > > >_______________________________________________ > >time-nuts mailing list -- time-nuts at febo.com > >To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >and follow the instructions there. > > > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From tvb at LeapSecond.com Thu Jan 15 05:29:57 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Wed, 14 Jan 2009 21:29:57 -0800 Subject: [time-nuts] Noise types and Allan Deviation References: <496E5DCF.1030803@xtra.co.nz> <13A73872892F4A44B70A42F002CEC96B@pc52> <496EB4A7.2050201@xtra.co.nz> Message-ID: > The tau range for which ADEV etc are sensibly independent of measurement > system bandwidth should differ significantly when comparing a pair of > hydrogen masers or a pair of low noise OCXOs (OSA8607, FTS1200 etc). I'm not sure what "significantly" is, but as you suggested, I do see more of a difference at low tau with two ultra low noise references than with two normal OCXO. The effect is zero to a couple of dB. See plots below. > The lower limit for an 8607 or a good FTS1200 is probably in the 1 to > 10s range. > That is around the value of tau for which ADEV vs tau first approximates > a horizontal straight line or reaches a minimum. > > Bruce Right you are. It's 2 seconds for the pair of 8607's and near 10 seconds for a 8607 vs. active H-maser. Compare these: http://www.leapsecond.com/pages/adev-bw/tbolt-tbolt-bw.gif http://www.leapsecond.com/pages/adev-bw/8607-8607-bw.gif http://www.leapsecond.com/pages/adev-bw/8607-hm75-bw.gif I'll add a maser-maser plot if I have it. /tvb From bruce.griffiths at xtra.co.nz Thu Jan 15 06:02:47 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 15 Jan 2009 19:02:47 +1300 Subject: [time-nuts] Noise types and Allan Deviation In-Reply-To: References: <496E5DCF.1030803@xtra.co.nz> <13A73872892F4A44B70A42F002CEC96B@pc52> <496EB4A7.2050201@xtra.co.nz> Message-ID: <496ED187.7040005@xtra.co.nz> Tom Van Baak wrote: >> The tau range for which ADEV etc are sensibly independent of measurement >> system bandwidth should differ significantly when comparing a pair of >> hydrogen masers or a pair of low noise OCXOs (OSA8607, FTS1200 etc). >> > > I'm not sure what "significantly" is, but as you suggested, > I do see more of a difference at low tau with two ultra low > noise references than with two normal OCXO. The effect > is zero to a couple of dB. See plots below. > > >> The lower limit for an 8607 or a good FTS1200 is probably in the 1 to >> 10s range. >> That is around the value of tau for which ADEV vs tau first approximates >> a horizontal straight line or reaches a minimum. >> >> Bruce >> > > Right you are. It's 2 seconds for the pair of 8607's and near 10 > seconds for a 8607 vs. active H-maser. Compare these: > http://www.leapsecond.com/pages/adev-bw/tbolt-tbolt-bw.gif > http://www.leapsecond.com/pages/adev-bw/8607-8607-bw.gif > http://www.leapsecond.com/pages/adev-bw/8607-hm75-bw.gif > > I'll add a maser-maser plot if I have it. > > /tvb > > > Tom Nice to see that my guesses weren't too far off. The really interesting part is that the source of the phase noise components whose contribution to ADEV, MDEV, etc is dependent on the measurement system noise bandwidth is actually the buffer amplifier chain and not the oscillator itself. Thus in a poorly designed oscillator the minimum value of tau for which ADEV, MDEV etc are independent of the measurement system noise bandwidth could vary significantly from the results found with the sources you have tested. Bruce From martinrh45 at googlemail.com Thu Jan 15 09:02:28 2009 From: martinrh45 at googlemail.com (Martin Richmond-Hardy) Date: Thu, 15 Jan 2009 09:02:28 +0000 Subject: [time-nuts] Fwd: Trimble NTPX26AB-06 Software? In-Reply-To: References: <8D448620-C2FE-4BA2-BB7B-1AD7EBC50FFC@googlemail.com> Message-ID: <623EF7E7-3DD8-4A4A-8BC9-4FEB30B32D71@googlemail.com> John, got the Trimble working by a RS422-RS232 fudge. Connections on the DB25 connector are the same as the HP Z3801A (see manual). First make a DB25(M) ? DB9(F) converter Use TxD (A) (-) DB25(M) pin 2 connect to DP9(F) pin 2 RxD (A) (-) DB25(M) pin 3 connect to DP9(F) pin 3 RxD (B) (+) DB25(M) pin 16 connect to DB25(M) pin 7 (Sig Gnd) and DP9(F) pin 5 This is OK for a short (few metres) connection otherwise I guess RS422 all the way with a converter on the end is the "proper" solution. Connect a DB9 lead to your PC serial port. Make sure GPS antenna has a good view of the sky - indoors by a window only picked up 1 satellite Run Tboltmon.exe Set your location (from another GPS) as "accurate". Give it 15-30mins to lock. Then set location as "approximate" and let it find its own location. 73 de Martin Richmond-Hardy G8BHC QTH: JO02pa Skype: callto://martinrh45 On 30 Dec 2008, at 06:37, John Allen wrote: > Thanks Martin. Please let me know how things come out and I will do > the > same when my unit arrives. > > 73 to all, and to all a Happy New Year, John K1AE > > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] > On > Behalf Of Martin Richmond-Hardy > Sent: Monday, December 29, 2008 1:46 PM > To: time-nuts at febo.com > Subject: [time-nuts] Fwd: Trimble NTPX26AB-06 Software? > > [forgot to cc original to the group] > > Begin forwarded message: > >> From: Martin Richmond-Hardy >> Date: 29 December 2008 15:47:06 GMT >> To: john at pcsupportsolutions.com >> Subject: [time-nuts] Trimble NTPX26AB-06 Software? >> >> John, >> I bought one of these on eBay a few weeks ago, supplied with a >> minidisk which I've only just managed to read (had to fire up an old >> blue iMac). I was advised that they appear to be using the >> thunderbolt monitor software at 9600 8 n 1 (which I downloaded from >> the net at > http://www.trimble.com/support_trl.asp?pt=Thunderbolt%C2%AEGPSDisciplinedClo > ck&Nav=Collection-2357 >> This runs on Windows xP. Interface is RS442 so needs a mod if your >> PC only has RS232. >> >> Haven't managed to test it yet. Need to fire up another ancient >> Windows machine as the VMWare Fusion emulator on my iMac won't drive >> the serial ports (or rather, I haven't figured it out yet) >> >> Best of luck! >> >> >> >> 73 de >> Martin Richmond-Hardy G8BHC >> QTH: JO02pa >> >> >> >> >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From swithrow at idcomm.com Thu Jan 15 15:04:09 2009 From: swithrow at idcomm.com (Skip Withrow) Date: Thu, 15 Jan 2009 08:04:09 -0700 Subject: [time-nuts] Need FE-5650A help Message-ID: <20090115150421.3D8EB6F92D9E@mailhost.idcomm.com> Hello fellow time-nuts, I have recently acquired an FEI FE-5650A rubidium oscillator from a piece of telecom equipment that does not seem to match some of the readily available information, and am looking for a bit of help. This unit has no indication of the options or variation. However, it does not match the standard units. The output frequency is 15MHz. The DB-9 connector pinout is as follows: 1 - +15V 2 - +15 RTN 3 - Lock Ind. (BIT) 4 - +5V 5 - +5 RTN 6 - VCO voltage? (or perhaps EFC control ?) 7 - GND 8 - Serial In (TTL) 9 - Serial Out (TTL) The serial port is 9600, 8, N, 1. However, the command set does not seem to be any of the ASCII commands that I have seen for other FE-5650/5680 units. Also, the synthesizer board seems to be a newer version than the two-button units that have been well documented. A picture is attached. Does anyone know what the command set might be? I would like to get the unit to 10MHz. Also, any clue as to the true function of PIN 6? Thanks in advance for your help. Skip Withrow -------------- next part -------------- A non-text attachment was scrubbed... Name: fe5650a.jpg Type: image/jpeg Size: 88840 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090115/d5f2f711/attachment-0001.jpg From cdelect at juno.com Thu Jan 15 17:10:23 2009 From: cdelect at juno.com (Corby Dawson) Date: Thu, 15 Jan 2009 09:10:23 -0800 Subject: [time-nuts] FTS Datum 1000A-100 Message-ID: <20090115.091024.3456.0.cdelect@juno.com> Thanks Bruce. Actually the +15VDC is the oven supply and the +24VDC is the electronics supply, kindof surprised me! Corby Dawson ____________________________________________________________ Want to put your personal touch on your home? Click for home improvement ideas and tips. http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2eRIrFfP8B02nSyn5ZXqDF71oOtUiAh3KI1jmmP8lMuSFxf/ From bruce.griffiths at xtra.co.nz Thu Jan 15 19:35:26 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 16 Jan 2009 08:35:26 +1300 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <20090115.091024.3456.0.cdelect@juno.com> References: <20090115.091024.3456.0.cdelect@juno.com> Message-ID: <496F8FFE.30101@xtra.co.nz> Corby Dawson wrote: > Thanks Bruce. > > Actually the +15VDC is the oven supply and the +24VDC is the electronics > supply, kindof surprised me! > > Corby Dawson > Corby The only way to find out more is to open up the package and trace the circuitry as Magnus has done for an FTS1200A. However if you do this you may well need to replace the foam plastic (urethane?) insulation used in addition to the vaccum insulated flask. Bruce From sar10538 at gmail.com Thu Jan 15 19:43:30 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Fri, 16 Jan 2009 08:43:30 +1300 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <496F8FFE.30101@xtra.co.nz> References: <20090115.091024.3456.0.cdelect@juno.com> <496F8FFE.30101@xtra.co.nz> Message-ID: <1231b6a80901151143i54e5c688t1cb22cd529a35abb@mail.gmail.com> 2009/1/16 Bruce Griffiths : > Corby Dawson wrote: >> Thanks Bruce. >> >> Actually the +15VDC is the oven supply and the +24VDC is the electronics >> supply, kindof surprised me! >> >> Corby Dawson >> > Corby > > The only way to find out more is to open up the package and trace the > circuitry as Magnus has done for an FTS1200A. > However if you do this you may well need to replace the foam plastic > (urethane?) insulation used in addition to the vaccum insulated flask. Or you could just connect the 24V supply and see if you get the clock out, and vice versa. This is certainly a lot easier and less destructive than taking the thing apart to find out which supply is which surely. > Bruce > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From bruce.griffiths at xtra.co.nz Thu Jan 15 20:22:30 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 16 Jan 2009 09:22:30 +1300 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <1231b6a80901151143i54e5c688t1cb22cd529a35abb@mail.gmail.com> References: <20090115.091024.3456.0.cdelect@juno.com> <496F8FFE.30101@xtra.co.nz> <1231b6a80901151143i54e5c688t1cb22cd529a35abb@mail.gmail.com> Message-ID: <496F9B06.4090608@xtra.co.nz> Steve Rooke wrote: > 2009/1/16 Bruce Griffiths : > >> Corby Dawson wrote: >> >>> Thanks Bruce. >>> >>> Actually the +15VDC is the oven supply and the +24VDC is the electronics >>> supply, kindof surprised me! >>> >>> Corby Dawson >>> >>> >> Corby >> >> The only way to find out more is to open up the package and trace the >> circuitry as Magnus has done for an FTS1200A. >> However if you do this you may well need to replace the foam plastic >> (urethane?) insulation used in addition to the vaccum insulated flask. >> > > Or you could just connect the 24V supply and see if you get the clock > out, and vice versa. This is certainly a lot easier and less > destructive than taking the thing apart to find out which supply is > which surely. > > >> Bruce >> >> Steve The oven and oscillator buffer supplies are already known. In the absence of specifications, some details of the circuitry are required to get some idea of the power supply limits. Bruce From sar10538 at gmail.com Thu Jan 15 20:30:03 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Fri, 16 Jan 2009 09:30:03 +1300 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <496F9B06.4090608@xtra.co.nz> References: <20090115.091024.3456.0.cdelect@juno.com> <496F8FFE.30101@xtra.co.nz> <1231b6a80901151143i54e5c688t1cb22cd529a35abb@mail.gmail.com> <496F9B06.4090608@xtra.co.nz> Message-ID: <1231b6a80901151230u84d0057sc851ebbb445eef4f@mail.gmail.com> 2009/1/16 Bruce Griffiths : > Steve Rooke wrote: >> 2009/1/16 Bruce Griffiths : >> >>> Corby Dawson wrote: >>> >>>> Thanks Bruce. >>>> >>>> Actually the +15VDC is the oven supply and the +24VDC is the electronics >>>> supply, kindof surprised me! >>>> >>>> Corby Dawson >>>> >>>> >>> Corby >>> >>> The only way to find out more is to open up the package and trace the >>> circuitry as Magnus has done for an FTS1200A. >>> However if you do this you may well need to replace the foam plastic >>> (urethane?) insulation used in addition to the vaccum insulated flask. >>> >> >> Or you could just connect the 24V supply and see if you get the clock >> out, and vice versa. This is certainly a lot easier and less >> destructive than taking the thing apart to find out which supply is >> which surely. >> >> >>> Bruce >>> >>> > Steve > > The oven and oscillator buffer supplies are already known. > > In the absence of specifications, some details of the circuitry are > required to get some idea of the power supply limits. Well, IMHO, it's not worth the risk of opening the thing up instead of just putting in a regulator to supply the heater. 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From ryabsley at optonline.net Fri Jan 16 02:58:35 2009 From: ryabsley at optonline.net (ryabsley at optonline.net) Date: Fri, 16 Jan 2009 02:58:35 +0000 (GMT) Subject: [time-nuts] Austron 2000C receiver manual. Message-ID: HI , ? I am looking for an e-copy of Austron 2000C receiver manual. ? Do you know where I could find one ? WA2WNY RICH From tlinbeck at sbcglobal.net Fri Jan 16 04:12:29 2009 From: tlinbeck at sbcglobal.net (Thomas Linbeck) Date: Thu, 15 Jan 2009 22:12:29 -0600 Subject: [time-nuts] Austron 2000C receiver manual. In-Reply-To: References: Message-ID: <010701c97790$a619bb70$4501a8c0@DJXTKX61> I think you can get one from Brooke Clarke PRC68.com -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of ryabsley at optonline.net Sent: Thursday, January 15, 2009 8:59 PM To: time-nuts at febo.com Subject: [time-nuts] Austron 2000C receiver manual. HI , ? I am looking for an e-copy of Austron 2000C receiver manual. ? Do you know where I could find one ? WA2WNY RICH _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From holrum at hotmail.com Fri Jan 16 06:02:03 2009 From: holrum at hotmail.com (Mark Sims) Date: Fri, 16 Jan 2009 06:02:03 +0000 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: References: Message-ID: Ahhh, yes... as the Great One once said: If it jams, force it. If it breaks, it needed fixing anyway... ------ >> Or you could just connect the 24V supply and see if you get the clock >> out, and vice versa. This is certainly a lot easier and less >> destructive than taking the thing apart to find out which supply is >> which surely. >> _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From magnus at rubidium.dyndns.org Fri Jan 16 09:04:51 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 16 Jan 2009 10:04:51 +0100 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: References: Message-ID: <49704DB3.5010000@rubidium.dyndns.org> Mark Sims skrev: > Ahhh, yes... as the Great One once said: If it jams, force it. If it breaks, it needed fixing anyway... So my first attempt should be to apply 230 VAC directly, since if it fails it needs fixing anyway... Sorry. Broken logic. Try again. This is one of the fields which that kind of reasoning DOES NOT APPLY. Overvoltage and overcurrent is things you need to know the limits for not to cause a mess. There are other things in which the logic may apply, but again, this is not one of those. When having a component in your hand, the same kind of range of allowed voltages etc. is not expected since it is expected that the box that they go into will handle that as a complete design. If every component would have huge overvoltage protection schemes they would be bulky and overpriced. Besides, I have been fairly successful at opening up things and reverse them to the level that I know what levels I can use. Cheers, Magnus > ------ > >>> Or you could just connect the 24V supply and see if you get the clock >>> out, and vice versa. This is certainly a lot easier and less >>> destructive than taking the thing apart to find out which supply is >>> which surely. >>> > _________________________________________________________________ > Windows Live?: Keep your life in sync. > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From david.partridge at dsl.pipex.com Fri Jan 16 09:10:36 2009 From: david.partridge at dsl.pipex.com (David C. Partridge) Date: Fri, 16 Jan 2009 09:10:36 -0000 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <49704DB3.5010000@rubidium.dyndns.org> References: <49704DB3.5010000@rubidium.dyndns.org> Message-ID: <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> I think Mark was being ironic - i.e. he agrees with you. D. -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Magnus Danielson Sent: 16 January 2009 09:05 To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] FTS Datum 1000A-100 Mark Sims skrev: > Ahhh, yes... as the Great One once said: If it jams, force it. If it breaks, it needed fixing anyway... So my first attempt should be to apply 230 VAC directly, since if it fails it needs fixing anyway... Sorry. Broken logic. Try again. This is one of the fields which that kind of reasoning DOES NOT APPLY. Overvoltage and overcurrent is things you need to know the limits for not to cause a mess. There are other things in which the logic may apply, but again, this is not one of those. When having a component in your hand, the same kind of range of allowed voltages etc. is not expected since it is expected that the box that they go into will handle that as a complete design. If every component would have huge overvoltage protection schemes they would be bulky and overpriced. Besides, I have been fairly successful at opening up things and reverse them to the level that I know what levels I can use. Cheers, Magnus > ------ > >>> Or you could just connect the 24V supply and see if you get the >>> clock out, and vice versa. This is certainly a lot easier and less >>> destructive than taking the thing apart to find out which supply is >>> which surely. >>> > _________________________________________________________________ > Windows LiveT: Keep your life in sync. > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_0120 > 09 _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From magnus at rubidium.dyndns.org Fri Jan 16 09:19:04 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 16 Jan 2009 10:19:04 +0100 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> References: <49704DB3.5010000@rubidium.dyndns.org> <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> Message-ID: <49705108.6050106@rubidium.dyndns.org> David C. Partridge skrev: > I think Mark was being ironic - i.e. he agrees with you. Unfortunately, being ironic on a public email-list or forum needs to be applied with care. When a less knowing person comes in it can go terribly wrong in this case. Lack of traditional markings like :-> etc which could give a hint is also important. Within a group of peers it's not as much a problem as when others come in... Cheers, Magnus > D. > > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On > Behalf Of Magnus Danielson > Sent: 16 January 2009 09:05 > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] FTS Datum 1000A-100 > > Mark Sims skrev: >> Ahhh, yes... as the Great One once said: If it jams, force it. If it > breaks, it needed fixing anyway... > > So my first attempt should be to apply 230 VAC directly, since if it fails > it needs fixing anyway... > > Sorry. Broken logic. Try again. > > This is one of the fields which that kind of reasoning DOES NOT APPLY. > Overvoltage and overcurrent is things you need to know the limits for not to > cause a mess. > > There are other things in which the logic may apply, but again, this is not > one of those. When having a component in your hand, the same kind of range > of allowed voltages etc. is not expected since it is expected that the box > that they go into will handle that as a complete design. If every component > would have huge overvoltage protection schemes they would be bulky and > overpriced. > > Besides, I have been fairly successful at opening up things and reverse them > to the level that I know what levels I can use. > > Cheers, > Magnus > >> ------ >> >>>> Or you could just connect the 24V supply and see if you get the >>>> clock out, and vice versa. This is certainly a lot easier and less >>>> destructive than taking the thing apart to find out which supply is >>>> which surely. >>>> >> _________________________________________________________________ >> Windows LiveT: Keep your life in sync. >> http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_0120 >> 09 _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From ernieperes at aol.com Fri Jan 16 10:19:21 2009 From: ernieperes at aol.com (ernieperes at aol.com) Date: Fri, 16 Jan 2009 05:19:21 -0500 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <49705108.6050106@rubidium.dyndns.org> References: <49704DB3.5010000@rubidium.dyndns.org><38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> <49705108.6050106@rubidium.dyndns.org> Message-ID: <8CB45DB0849D2FB-15D4-2077@FWM-D09.sysops.aol.com> No too mention other people having other mother tongue. Cheers, Ernie. -----Original Message----- From: Magnus Danielson To: Discussion of precise time and frequency measurement Sent: Fri, 16 Jan 2009 10:19 am Subject: Re: [time-nuts] FTS Datum 1000A-100 David C. Partridge skrev: > I think Mark was being ironic - i.e. he agrees with you. Unfortunately, being ironic on a public email-list or forum needs to be applied with care. When a less knowing person comes in it can go terribly wrong in this case. Lack of traditional markings like :-> etc which could give a hint is also important. Within a group of peers it's not as much a problem as when others come in... Cheers, Magnus > D. > > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On > Behalf Of Magnus Danielson > Sent: 16 January 2009 09:05 > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] FTS Datum 1000A-100 > > Mark Sims skrev: >> Ahhh, yes... as the Great One once said: If it jams, force it. If it > breaks, it needed fixing anyway... > > So my first attempt should be to apply 230 VAC directly, since if it fails > it needs fixing anyway... > > Sorry. Broken logic. Try again. > > This is one of the fields which that kind of reasoning DOES NOT APPLY. > Overvoltage and overcurrent is things you need to know the limits for not to > cause a mess. > > There are other things in which the logic may apply, but again, this is not > one of those. When having a component in your hand, the same kind of range > of allowed voltages etc. is not expected since it is expected that the box > that they go into will handle that as a complete design. If every component > would have huge overvoltage protection schemes they would be bulky and > overpriced. > > Besides, I have been fairly successful at opening up things and reverse them > to the level that I know what levels I can use. > > Cheers, > Magnus > >> ------ >> >>>> Or you could just connect the 24V supply and see if you get the >>>> clock out, and vice versa. This is certainly a lot easier and less >>>> destructive than taking the thing apart to find out which supply is >>>> which surely. >>>> >> _________________________________________________________________ >> Windows LiveT: Keep your life in sync. >> http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_0120 >> 09 _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From bruce.griffiths at xtra.co.nz Fri Jan 16 11:20:17 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 17 Jan 2009 00:20:17 +1300 Subject: [time-nuts] FTS Datum 1000A-100 In-Reply-To: <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> References: <49704DB3.5010000@rubidium.dyndns.org> <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> Message-ID: <49706D71.6040304@xtra.co.nz> Another factor to bear in mind is that some of these older OCXOs used insulating foams that are chemically unstable. With age these revert to a sticky mess which should be replaced in any case, to ensure that the thermal insulation is increased to the design value. Thus it can be useful to at least partially disassemble such OCXOs to check for such problems. A lot of the early conductive foams are similarly unstable and breakdown over the decades. However there are a few OCXOs that use beryllium oxide within them, these are usually labelled as such and no attempt at reverse engineering should be made. I have one of these lying around. Safe disposal of such devices is also problematic. Bruce David C. Partridge wrote: > I think Mark was being ironic - i.e. he agrees with you. > > D. > > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On > Behalf Of Magnus Danielson > Sent: 16 January 2009 09:05 > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] FTS Datum 1000A-100 > > Mark Sims skrev: > >> Ahhh, yes... as the Great One once said: If it jams, force it. If it >> > breaks, it needed fixing anyway... > > So my first attempt should be to apply 230 VAC directly, since if it fails > it needs fixing anyway... > > Sorry. Broken logic. Try again. > > This is one of the fields which that kind of reasoning DOES NOT APPLY. > Overvoltage and overcurrent is things you need to know the limits for not to > cause a mess. > > There are other things in which the logic may apply, but again, this is not > one of those. When having a component in your hand, the same kind of range > of allowed voltages etc. is not expected since it is expected that the box > that they go into will handle that as a complete design. If every component > would have huge overvoltage protection schemes they would be bulky and > overpriced. > > Besides, I have been fairly successful at opening up things and reverse them > to the level that I know what levels I can use. > > Cheers, > Magnus > > >> ------ >> >> >>>> Or you could just connect the 24V supply and see if you get the >>>> clock out, and vice versa. This is certainly a lot easier and less >>>> destructive than taking the thing apart to find out which supply is >>>> which surely. >>>> >>>> From cdelect at juno.com Fri Jan 16 16:49:09 2009 From: cdelect at juno.com (Corby Dawson) Date: Fri, 16 Jan 2009 08:49:09 -0800 Subject: [time-nuts] FTS Datum 1000A-100 Message-ID: <20090116.084909.3044.0.cdelect@juno.com> Hi all, The pinout is known and I have run the unit for a couple weeks at the +15V and +24V levels which is what the mainframe it came out of supplied. I'll just end up 3 terminaling to get the +15 from the +24. Just hoped there were some specs floating around out there! On another subject I will be adding some more to the quartz oscillator short term stability list I posted last year. A couple FTS1200 with accelerometers + a few more misc. oscillators. Cheers, Corby Dawson ____________________________________________________________ Beauty School Programs - Get the career you've always wanted. Click Now. http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw3iMbDFUFphunhH0yXJ5EVDm5mufE83xFrKpIyUJMAOMHVIV/ From brooke at pacific.net Fri Jan 16 17:21:38 2009 From: brooke at pacific.net (Brooke Clarke) Date: Fri, 16 Jan 2009 09:21:38 -0800 Subject: [time-nuts] beryllium oxide In-Reply-To: <49706D71.6040304@xtra.co.nz> References: <49704DB3.5010000@rubidium.dyndns.org> <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> <49706D71.6040304@xtra.co.nz> Message-ID: <4970C222.5090707@pacific.net> Hi Bruce: Why is beryllium oxide a problem when it's already in a product? I believe the danger is something similar to asbestos where inhaling large amounts it is the problem. Shipyard workers applying loose asbestos to pipes and boilers inhaled the material all during there work day and ended up with medical problems. I've heard that electronics workers that made products from beryllium oxide also suffered medical problems. They were breathing a lot of the dust. Mechanics who grind brake material will have no problem from asbestos just as motorists since the "fish hooks" are no longer present in the asbestos dust. I used to have a sheet of asbestos that fit into the oven and was used to bake bread. It's OK to eat asbestos and probably beryllium oxide. There's a disused hotel on our main street that's a brick building heated with a steam boiler with the whole system insulated with asbestos. It's a real (expensive) problem to remove that asbestos in a way safe for the person doing it and doing all the needed OSH paperwork. I believe the cost to remove the asbestos far exceeds the economic value of the building and the land it's sitting on. In time that will change. Don't see any problem related to (beryllium oxide) oscillator disposal. Can you elaborate? Have Fun, Brooke Clarke http://www.prc68.com Bruce Griffiths wrote: . . . > > However there are a few OCXOs that use beryllium oxide within them, > these are usually labelled as such and no attempt at reverse engineering > should be made. > I have one of these lying around. > Safe disposal of such devices is also problematic. > > Bruce From rdarlington at gmail.com Fri Jan 16 17:22:50 2009 From: rdarlington at gmail.com (Robert Darlington) Date: Fri, 16 Jan 2009 10:22:50 -0700 Subject: [time-nuts] beryllium oxide In-Reply-To: <4970C222.5090707@pacific.net> References: <49704DB3.5010000@rubidium.dyndns.org> <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> <49706D71.6040304@xtra.co.nz> <4970C222.5090707@pacific.net> Message-ID: Beryliosis. On 1/16/09, Brooke Clarke wrote: > Hi Bruce: > > Why is beryllium oxide a problem when it's already in a product? > > I believe the danger is something similar to asbestos where inhaling large > amounts it is the problem. Shipyard workers applying loose asbestos to > pipes > and boilers inhaled the material all during there work day and ended up with > medical problems. I've heard that electronics workers that made products > from > beryllium oxide also suffered medical problems. They were breathing a lot > of > the dust. Mechanics who grind brake material will have no problem from > asbestos just as motorists since the "fish hooks" are no longer present in > the > asbestos dust. I used to have a sheet of asbestos that fit into the oven and > was used to bake bread. It's OK to eat asbestos and probably beryllium > oxide. > There's a disused hotel on our main street that's a brick building heated > with a steam boiler with the whole system insulated with asbestos. It's a > real > (expensive) problem to remove that asbestos in a way safe for the person > doing > it and doing all the needed OSH paperwork. I believe the cost to remove the > asbestos far exceeds the economic value of the building and the land it's > sitting on. In time that will change. > > Don't see any problem related to (beryllium oxide) oscillator disposal. Can > you elaborate? > > Have Fun, > > Brooke Clarke > http://www.prc68.com > > Bruce Griffiths wrote: > . . . >> >> However there are a few OCXOs that use beryllium oxide within them, >> these are usually labelled as such and no attempt at reverse engineering >> should be made. >> I have one of these lying around. >> Safe disposal of such devices is also problematic. >> >> Bruce > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Sent from my mobile device From dforbes at dakotacom.net Fri Jan 16 17:29:16 2009 From: dforbes at dakotacom.net (David Forbes) Date: Fri, 16 Jan 2009 10:29:16 -0700 Subject: [time-nuts] beryllium oxide In-Reply-To: <4970C222.5090707@pacific.net> References: <49704DB3.5010000@rubidium.dyndns.org> <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> <49706D71.6040304@xtra.co.nz> <4970C222.5090707@pacific.net> Message-ID: <4970C3EC.3060201@dakotacom.net> Brooke Clarke wrote: > Hi Bruce: > > Why is beryllium oxide a problem when it's already in a product? > > I believe the danger is something similar to asbestos where inhaling large > amounts it is the problem. Shipyard workers applying loose asbestos to pipes > and boilers inhaled the material all during there work day and ended up with > medical problems. I've heard that electronics workers that made products from > beryllium oxide also suffered medical problems. They were breathing a lot of > the dust. Mechanics who grind brake material will have no problem from > asbestos just as motorists since the "fish hooks" are no longer present in the > asbestos dust. I used to have a sheet of asbestos that fit into the oven and > was used to bake bread. It's OK to eat asbestos and probably beryllium oxide. > There's a disused hotel on our main street that's a brick building heated > with a steam boiler with the whole system insulated with asbestos. It's a real > (expensive) problem to remove that asbestos in a way safe for the person doing > it and doing all the needed OSH paperwork. I believe the cost to remove the > asbestos far exceeds the economic value of the building and the land it's > sitting on. In time that will change. > > Don't see any problem related to (beryllium oxide) oscillator disposal. Can > you elaborate? > > Have Fun, > > Brooke Clarke > http://www.prc68.com > > Bruce Griffiths wrote: > . . . >> However there are a few OCXOs that use beryllium oxide within them, >> these are usually labelled as such and no attempt at reverse engineering >> should be made. >> I have one of these lying around. >> Safe disposal of such devices is also problematic. >> >> Bruce Brooke, My wife is getting a degree in public health and has investigated this stuff. We have a local Brush factory that makes products from beryllium oxide. It does cause some of the workers to get a type of lung disease, in spite of the air handling systems they have in place. My wife told me that there has been a notable, documented incidence of beryllium disease in the OSHA inspectors who check the plants for compliance. So it's not safe even to have a job making sure it's safe! The exposure prevention method is to never breathe the dust. That means keeping it wet or encapsulated at all times. A single particle of beryllium in the right place at the right time can be enough to cause problems. So yeah, don't mess with beryllium oxide. --David Forbes, Tucson AZ From mikes at flatsurface.com Fri Jan 16 17:39:37 2009 From: mikes at flatsurface.com (Mike S) Date: Fri, 16 Jan 2009 12:39:37 -0500 Subject: [time-nuts] beryllium oxide In-Reply-To: References: <49704DB3.5010000@rubidium.dyndns.org> <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> <49706D71.6040304@xtra.co.nz> <4970C222.5090707@pacific.net> Message-ID: <20090116173944.2D4CA116F50@hamburg.alientech.net> At 12:22 PM 1/16/2009, Robert Darlington wrote... >Beryliosis. That's a glib response, which says nothing to contradict Brooke's point. From james.p.lux at jpl.nasa.gov Fri Jan 16 17:45:53 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Fri, 16 Jan 2009 09:45:53 -0800 Subject: [time-nuts] beryllium oxide Message-ID: More realistically, the dangeris dust when something is physically overstressed (dropped, mounting overtightened, thermal shock). That, and if it gets ground up in trash disposal... Say someone throws it in the shredder. -----Original Message----- From: "Mike S" To: "Discussion of precise time and frequency measurement" Cc: "Discussion of precise time and frequency measurement" Sent: 1/16/09 09:41 Subject: Re: [time-nuts] beryllium oxide At 12:22 PM 1/16/2009, Robert Darlington wrote... >Beryliosis. That's a glib response, which says nothing to contradict Brooke's point. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From rdarlington at gmail.com Fri Jan 16 18:08:49 2009 From: rdarlington at gmail.com (Robert Darlington) Date: Fri, 16 Jan 2009 11:08:49 -0700 Subject: [time-nuts] beryllium oxide In-Reply-To: <20090116173944.2D4CA116F50@hamburg.alientech.net> References: <49704DB3.5010000@rubidium.dyndns.org> <38DFD1E9C4DE4793B1FEE5E7776284DF@APOLLO> <49706D71.6040304@xtra.co.nz> <4970C222.5090707@pacific.net> <20090116173944.2D4CA116F50@hamburg.alientech.net> Message-ID: Sorry, don't have time to go into detail, just boarded an airplane. Feel free to google. On 1/16/09, Mike S wrote: > At 12:22 PM 1/16/2009, Robert Darlington wrote... >>Beryliosis. > > That's a glib response, which says nothing to contradict Brooke's > point. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Sent from my mobile device From hmurray at megapathdsl.net Fri Jan 16 18:09:02 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 16 Jan 2009 10:09:02 -0800 Subject: [time-nuts] beryllium oxide In-Reply-To: Message from Robert Darlington of "Fri, 16 Jan 2009 10:22:50 MST." Message-ID: <20090116180903.3C973BCDA@ip-64-139-1-69.sjc.megapath.net> > Beryliosis. The problem that I'm familiar with is dust made when machining beryllium. In the 60s, MIT had a whole building that was full of the stuff leftover from machining parts for the Polaris guidance system. Beryllium is light and stiff, good for making gyros. Beryllium oxide is a ceramic similar to aluminum oxide. I expect it's being used as an insulator with good thermal conductivity. I'd expect that to be safe. There might be troubles if you break it or grind it. (It would probably ignore sandpaper.) From mikes at flatsurface.com Fri Jan 16 18:28:40 2009 From: mikes at flatsurface.com (Mike S) Date: Fri, 16 Jan 2009 13:28:40 -0500 Subject: [time-nuts] beryllium oxide In-Reply-To: References: Message-ID: <20090116182843.207E9116CE1@hamburg.alientech.net> At 12:45 PM 1/16/2009, Lux, James P wrote... >More realistically, the dangeris dust when something is physically >overstressed (dropped, mounting overtightened, thermal shock). That, >and if it gets ground up in trash disposal... Say someone throws it in >the shredder. So, if some electronics have an IC with a BeO package, and it sits undisturbed, what's the problem? It seems to me that most, if not all, such uses would be additionally contained by heatsinks and compound, since it's the thermal conductivity properties which caused it to be used in the first place. Hard to say how much dust might be produced by dropping or overtightening. In my experience, ceramics tend to break pretty cleanly. Maybe BeO is different. Granted, the manufacturer can be expected to be biased, but Brush Ceramics claims "Beryllium oxide (BeO), in solid form and as contained in finished products, presents no special health risks." They also claim "Under federal regulations and most state regulations, BeO ceramic or products containing BeO ceramics that are no longer recyclable and declared solid wastes are not classified as hazardous waste due the content of BeO ceramic." From robert8rpi at yahoo.co.uk Fri Jan 16 18:58:39 2009 From: robert8rpi at yahoo.co.uk (Robert Atkinson) Date: Fri, 16 Jan 2009 18:58:39 +0000 (GMT) Subject: [time-nuts] beryllium oxide In-Reply-To: <20090116182843.207E9116CE1@hamburg.alientech.net> Message-ID: <248002.32823.qm@web27103.mail.ukl.yahoo.com> I've personally seen three applications of BeO in electronics. Two, including the most common, are a possible hazzard. The most common application is RF power devices (transistors and terminating resistors). These hace a "washer" or slab of BeO between the semiconductor device and the mounting stud or flange. Asthis is trypically below the electrical connecting leads (often wide strips or tabs), application of excessive force between heatsink and PCB can fracture the BeO causing dust an chips/splinters. Splinters onder the skin or in the eye can cause problems as well as inhaled dust. force can be applied during manufacture / service or in an accident or if the item containing the unit is crushed. Next most common is the use in metal can semiconductors. One example are early LM78Hxx TO3 regulators. These are fairly safe as the can has to be ruptured. The third is as a block of solid BeO bonded to metal plates used to insulate conduction cooled vacuum tubes. Some power tubesmay use it internally. A big problem is that it looks like any other ceramic. In some UK equipment devices containing BeO will be marked with "cornflower blue" paint dot. A non-electronic application is in some (eg argon-ion) lasers. on a side note some vacuum tubes (especially cold cathode types) contain various radioactive materials. Robert G8RPI. --- On Fri, 16/1/09, Mike S wrote: > From: Mike S > Subject: Re: [time-nuts] beryllium oxide > To: "Discussion of precise time and frequency measurement" > Date: Friday, 16 January, 2009, 6:28 PM > At 12:45 PM 1/16/2009, Lux, James P wrote... > >More realistically, the dangeris dust when something is > physically > >overstressed (dropped, mounting overtightened, thermal > shock). That, > >and if it gets ground up in trash disposal... Say > someone throws it in > >the shredder. > > So, if some electronics have an IC with a BeO package, and > it sits > undisturbed, what's the problem? It seems to me that > most, if not all, > such uses would be additionally contained by heatsinks and > compound, > since it's the thermal conductivity properties which > caused it to be > used in the first place. > > Hard to say how much dust might be produced by dropping or > overtightening. In my experience, ceramics tend to break > pretty > cleanly. Maybe BeO is different. > > Granted, the manufacturer can be expected to be biased, but > Brush > Ceramics claims "Beryllium oxide (BeO), in solid form > and as contained > in finished products, presents no special health > risks." They also > claim "Under federal regulations and most state > regulations, BeO > ceramic or products containing BeO > ceramics that are no longer recyclable and declared solid > wastes are > not classified as hazardous waste due the content of BeO > ceramic." > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From richard at karlquist.com Fri Jan 16 19:04:42 2009 From: richard at karlquist.com (Rick Karlquist) Date: Fri, 16 Jan 2009 11:04:42 -0800 (PST) Subject: [time-nuts] beryllium oxide In-Reply-To: <248002.32823.qm@web27103.mail.ukl.yahoo.com> References: <248002.32823.qm@web27103.mail.ukl.yahoo.com> Message-ID: Robert Atkinson wrote: > non-electronic application is in some (eg argon-ion) lasers. > on a side note some vacuum tubes (especially cold cathode types) contain > various radioactive materials. > > Robert G8RPI. Of interest to time nuts is that rubidium standards contain two isotopes of Rb, one of which is slightly radioactive. Also, if you have an Rb in your basement and it starts acting squirrely, it might be because you have helium in the air, since helium gets into "hermetic" stuff. If you do have helium, it is because you have radon, which radiates helium ions, also known as alpha particles. Rick N6RK From bruce.griffiths at xtra.co.nz Fri Jan 16 19:33:29 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 17 Jan 2009 08:33:29 +1300 Subject: [time-nuts] beryllium oxide In-Reply-To: References: <248002.32823.qm@web27103.mail.ukl.yahoo.com> Message-ID: <4970E109.8010608@xtra.co.nz> Rick Karlquist wrote: > Robert Atkinson wrote: > >> non-electronic application is in some (eg argon-ion) lasers. >> on a side note some vacuum tubes (especially cold cathode types) contain >> various radioactive materials. >> >> Robert G8RPI. >> > > Of interest to time nuts is that rubidium standards contain > two isotopes of Rb, one of which is slightly radioactive. > Also, if you have an Rb in your basement and it starts acting > squirrely, it might be because you have helium in the air, > since helium gets into "hermetic" stuff. If you do have helium, > it is because you have radon, which radiates helium ions, > also known as alpha particles. > > Rick N6RK > > > Radon diffuses up through the ground. The radon is a daughter product from natural radioactive decay processes within the Earth. In some areas it is considered good practice to have good ventilation in basements and under the floor to disperse the radon that would otherwise accumulate. There is some epidemiological evidence for enhanced cancer rates when radon concentration is high. The problem isn't the radon itself but its decay products Bruce From d.seiter at comcast.net Fri Jan 16 19:41:24 2009 From: d.seiter at comcast.net (d.seiter at comcast.net) Date: Fri, 16 Jan 2009 19:41:24 +0000 Subject: [time-nuts] beryllium oxide Message-ID: <011620091941.14291.4970E2E4000467DA000037D322007503309D0A9B070A9CD20B@comcast.net> Since we're on the subject, what does BeO typically look like when it's used as a washer, heatsink, etc. I ask because I tend to keep everything and I modify things all the time. Is there any way besides being painted that it could pass as Al? -Dave From bruce.griffiths at xtra.co.nz Fri Jan 16 19:42:39 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 17 Jan 2009 08:42:39 +1300 Subject: [time-nuts] beryllium oxide In-Reply-To: <248002.32823.qm@web27103.mail.ukl.yahoo.com> References: <248002.32823.qm@web27103.mail.ukl.yahoo.com> Message-ID: <4970E32F.2020506@xtra.co.nz> Robert Atkinson wrote: > I've personally seen three applications of BeO in electronics. Two, including the most common, are a possible hazzard. > The most common application is RF power devices (transistors and terminating resistors). These hace a "washer" or slab of BeO between the semiconductor device and the mounting stud or flange. Asthis is trypically below the electrical connecting leads (often wide strips or tabs), application of excessive force between heatsink and PCB can fracture the BeO causing dust an chips/splinters. Splinters onder the skin or in the eye can cause problems as well as inhaled dust. force can be applied during manufacture / service or in an accident or if the item containing the unit is crushed. Next most common is the use in metal can semiconductors. One example are early LM78Hxx TO3 regulators. These are fairly safe as the can has to be ruptured. The third is as a block of solid BeO bonded to metal plates used to insulate conduction cooled vacuum tubes. Some power tubesmay use it internally. A big problem is that it looks like any other ceramic. In some UK equipment > devices containing BeO will be marked with "cornflower blue" paint dot. A non-electronic application is in some (eg argon-ion) lasers. > on a side note some vacuum tubes (especially cold cathode types) contain various radioactive materials. > > Robert G8RPI. > > > --- On Fri, 16/1/09, Mike S wrote: > > >> From: Mike S >> Subject: Re: [time-nuts] beryllium oxide >> To: "Discussion of precise time and frequency measurement" >> Date: Friday, 16 January, 2009, 6:28 PM >> At 12:45 PM 1/16/2009, Lux, James P wrote... >> >>> More realistically, the dangeris dust when something is >>> >> physically >> >>> overstressed (dropped, mounting overtightened, thermal >>> >> shock). That, >> >>> and if it gets ground up in trash disposal... Say >>> >> someone throws it in >> >>> the shredder. >>> >> So, if some electronics have an IC with a BeO package, and >> it sits >> undisturbed, what's the problem? It seems to me that >> most, if not all, >> such uses would be additionally contained by heatsinks and >> compound, >> since it's the thermal conductivity properties which >> caused it to be >> used in the first place. >> >> Hard to say how much dust might be produced by dropping or >> overtightening. In my experience, ceramics tend to break >> pretty >> cleanly. Maybe BeO is different. >> >> Granted, the manufacturer can be expected to be biased, but >> Brush >> Ceramics claims "Beryllium oxide (BeO), in solid form >> and as contained >> in finished products, presents no special health >> risks." They also >> claim "Under federal regulations and most state >> regulations, BeO >> ceramic or products containing BeO >> ceramics that are no longer recyclable and declared solid >> wastes are >> not classified as hazardous waste due the content of BeO >> ceramic." >> >> >> The OCXO in question doesn't have the usual foam insulation that is easily removed, but has cast in place insulation of somewhat higher density. Its impossible to remove without cutting or dissolving, and there is no easy way to know if beryllia powder was used selectively as a thermal conduction enhancement additive rather than beryllia sheets were used internally within semiconductor packages or as thermally conductive washers. I have no data on the pin connections or any other specs. It appears to be a General Radio 1158-4010 with 7 teflon insulated feedthrough insulators. Bruce From ik1odo at spin-it.com Fri Jan 16 19:44:24 2009 From: ik1odo at spin-it.com (Marco IK1ODO) Date: Fri, 16 Jan 2009 20:44:24 +0100 Subject: [time-nuts] beryllium oxide In-Reply-To: <248002.32823.qm@web27103.mail.ukl.yahoo.com> References: <20090116182843.207E9116CE1@hamburg.alientech.net> <248002.32823.qm@web27103.mail.ukl.yahoo.com> Message-ID: Robert, >Some power tubesmay use it internally. As far as I know, from many discussions with power tube manufacturers, no power tube uses beryllia, except for that conduction-cooled Eimac tubes. It's simply not needed. Other tubes (not power ones) may be different, but I never heard of any beryllia in them. Marco IK1ODO / AI4YF From hbonhorst at freenet.de Fri Jan 16 19:48:59 2009 From: hbonhorst at freenet.de (v. Bonhorst) Date: Fri, 16 Jan 2009 20:48:59 +0100 Subject: [time-nuts] beryllium oxide In-Reply-To: <248002.32823.qm@web27103.mail.ukl.yahoo.com> References: <20090116182843.207E9116CE1@hamburg.alientech.net> <248002.32823.qm@web27103.mail.ukl.yahoo.com> Message-ID: BeO furthermore had been used in some types of RF attenuators, especially for higher power, as a insulating washer for transistors (High voltage power transistors, RF terminating resistors, Thermal studs and so on. Although it is replaced nowadays in most cases by different materials, Beo can be found easily in older equipment. Hubert DB 7 ME -----Urspr?ngliche Nachricht----- Von: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] Im Auftrag von Robert Atkinson Gesendet: Freitag, 16. Januar 2009 19:59 An: Discussion of precise time and frequency measurement Betreff: [!! SPAM] Re: [time-nuts] beryllium oxide I've personally seen three applications of BeO in electronics. Two, including the most common, are a possible hazzard. The most common application is RF power devices (transistors and terminating resistors). These hace a "washer" or slab of BeO between the semiconductor device and the mounting stud or flange. Asthis is trypically below the electrical connecting leads (often wide strips or tabs), application of excessive force between heatsink and PCB can fracture the BeO causing dust an chips/splinters. Splinters onder the skin or in the eye can cause problems as well as inhaled dust. force can be applied during manufacture / service or in an accident or if the item containing the unit is crushed. Next most common is the use in metal can semiconductors. One example are early LM78Hxx TO3 regulators. These are fairly safe as the can has to be ruptured. The third is as a block of solid BeO bonded to metal plates used to insulate conduction cooled vacuum tubes. Some power tubesmay use it internally. A big problem is that it looks like any other ceramic. In some UK equipment devices containing BeO will be marked with "cornflower blue" paint dot. A non-electronic application is in some (eg argon-ion) lasers. on a side note some vacuum tubes (especially cold cathode types) contain various radioactive materials. Robert G8RPI. --- On Fri, 16/1/09, Mike S wrote: > From: Mike S > Subject: Re: [time-nuts] beryllium oxide > To: "Discussion of precise time and frequency measurement" > Date: Friday, 16 January, 2009, 6:28 PM > At 12:45 PM 1/16/2009, Lux, James P wrote... > >More realistically, the dangeris dust when something is > physically > >overstressed (dropped, mounting overtightened, thermal > shock). That, > >and if it gets ground up in trash disposal... Say > someone throws it in > >the shredder. > > So, if some electronics have an IC with a BeO package, and > it sits > undisturbed, what's the problem? It seems to me that > most, if not all, > such uses would be additionally contained by heatsinks and > compound, > since it's the thermal conductivity properties which > caused it to be > used in the first place. > > Hard to say how much dust might be produced by dropping or > overtightening. In my experience, ceramics tend to break > pretty > cleanly. Maybe BeO is different. > > Granted, the manufacturer can be expected to be biased, but > Brush > Ceramics claims "Beryllium oxide (BeO), in solid form > and as contained > in finished products, presents no special health > risks." They also > claim "Under federal regulations and most state > regulations, BeO > ceramic or products containing BeO > ceramics that are no longer recyclable and declared solid > wastes are > not classified as hazardous waste due the content of BeO > ceramic." > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From dforbes at dakotacom.net Fri Jan 16 19:46:36 2009 From: dforbes at dakotacom.net (David Forbes) Date: Fri, 16 Jan 2009 12:46:36 -0700 Subject: [time-nuts] beryllium oxide In-Reply-To: <011620091941.14291.4970E2E4000467DA000037D322007503309D0A9B070A9CD20B@comcast.net> References: <011620091941.14291.4970E2E4000467DA000037D322007503309D0A9B070A9CD20B@comcast.net> Message-ID: <4970E41C.7020202@dakotacom.net> d.seiter at comcast.net wrote: > Since we're on the subject, what does BeO typically look like when it's used as a washer, heatsink, etc. I ask because I tend to keep everything and I modify things all the time. Is there any way besides being painted that it could pass as Al? > > -Dave Dave, It's a white ceramic substance. Commonly used on the older "pill" shaped RF power transistors. From ik1odo at spin-it.com Fri Jan 16 19:46:26 2009 From: ik1odo at spin-it.com (Marco IK1ODO) Date: Fri, 16 Jan 2009 20:46:26 +0100 Subject: [time-nuts] beryllium oxide In-Reply-To: <011620091941.14291.4970E2E4000467DA000037D322007503309D0A9 B070A9CD20B@comcast.net> References: <011620091941.14291.4970E2E4000467DA000037D322007503309D0A9B070A9CD20B@comcast.net> Message-ID: At 20.41 16/01/2009, you wrote: >Since we're on the subject, what does BeO typically look like when >it's used as a washer, heatsink, etc. I ask because I tend to keep >everything and I modify things all the time. Is there any way >besides being painted that it could pass as Al? > >-Dave Exactly as Al. White, hard ceramic. May be colored, but also allumina may be pink or violet (see Russian power tubes). Marco IK1ODO From bruce.griffiths at xtra.co.nz Fri Jan 16 19:47:30 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 17 Jan 2009 08:47:30 +1300 Subject: [time-nuts] beryllium oxide In-Reply-To: <011620091941.14291.4970E2E4000467DA000037D322007503309D0A9B070A9CD20B@comcast.net> References: <011620091941.14291.4970E2E4000467DA000037D322007503309D0A9B070A9CD20B@comcast.net> Message-ID: <4970E452.2030504@xtra.co.nz> d.seiter at comcast.net wrote: > Since we're on the subject, what does BeO typically look like when it's used as a washer, heatsink, etc. I ask because I tend to keep everything and I modify things all the time. Is there any way besides being painted that it could pass as Al? > > -Dave > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Dave The TO3 beryllia washers I have are light blue, but pure beryllia is white. Various ionic impurities can be used to impart different colours to the final product. Pure Alumina is also white but pink TO3 alumina washers are/were available. Bruce From holrum at hotmail.com Fri Jan 16 19:50:10 2009 From: holrum at hotmail.com (Mark Sims) Date: Fri, 16 Jan 2009 19:50:10 +0000 Subject: [time-nuts] beryllium oxide In-Reply-To: References: Message-ID: Three other places one may encounter beryllium are: 1) Beryllium copper springs and contacts, usually around 2-3% beryllium. Not likely to cause a problem unless you get your jollies grinding up springy metal and snorting the powder. 2) Beryllium tools! Tools (particularly screwdrivers and pliers) can be made out of pure beryllium metal. They are not magnetic, very strong, very light. They were used a lot in aerospace and military applications. One thing that used to appear on the surplus market was an EOD toolkit used by bomb disposal techs. Even had a beryllium hammer. These were wonderful tools which you might just find when clearing out old uncle Bob's estate... 3) Nuclear reactors and weapons. Be careful when disassembling that surplus nuke you picked up on your last trip to eastern Europe... Beryllium was originally called glucinium becuase it and its salts tasted very sweet. In fact, tasting used to be a diagnostic test for the presence of beryllium. _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From magnus at rubidium.dyndns.org Fri Jan 16 19:59:41 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 16 Jan 2009 20:59:41 +0100 Subject: [time-nuts] beryllium oxide In-Reply-To: References: Message-ID: <4970E72D.1050300@rubidium.dyndns.org> Mark Sims skrev: > Three other places one may encounter beryllium are: > > 1) Beryllium copper springs and contacts, usually around 2-3% beryllium. Not likely to cause a problem unless you get your jollies grinding up springy metal and snorting the powder. > > 2) Beryllium tools! Tools (particularly screwdrivers and pliers) can be made out of pure beryllium metal. They are not magnetic, very strong, very light. They were used a lot in aerospace and military applications. One thing that used to appear on the surplus market was an EOD toolkit used by bomb disposal techs. Even had a beryllium hammer. These were wonderful tools which you might just find when clearing out old uncle Bob's estate... > > 3) Nuclear reactors and weapons. Be careful when disassembling that surplus nuke you picked up on your last trip to eastern Europe... Oh... where did I put that pile of junk? :-> > Beryllium was originally called glucinium becuase it and its salts tasted very sweet. In fact, tasting used to be a diagnostic test for the presence of beryllium. Sounds dangerous... I have encountered Beryllium in a field none of you mentioned, as material for speaker cones. Light and very rigid. Perfect for the top driver for horns. I recall something about high speed of sound. Cheers, Magnus From holrum at hotmail.com Fri Jan 16 20:00:15 2009 From: holrum at hotmail.com (Mark Sims) Date: Fri, 16 Jan 2009 20:00:15 +0000 Subject: [time-nuts] beryllium oxide In-Reply-To: References: Message-ID: Oh, and one more place to find pure beryllium in the home... high end stereo equipment... specifically in speakers and tweeters. For an example of this: http://www.utopia-be.com/Technology/Beryllium.htm Couple a few of those with your cesium locked turntable and $100,000 oxygen free copper/polymer power cord and you're good to go... _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_012009 From phk at phk.freebsd.dk Fri Jan 16 20:10:53 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 16 Jan 2009 20:10:53 +0000 Subject: [time-nuts] beryllium oxide In-Reply-To: Your message of "Fri, 16 Jan 2009 20:59:41 +0100." <4970E72D.1050300@rubidium.dyndns.org> Message-ID: <22975.1232136653@critter.freebsd.dk> In message <4970E72D.1050300 at rubidium.dyndns.org>, Magnus Danielson writes: >I have encountered Beryllium in a field none of you mentioned, as >material for speaker cones. Light and very rigid. Perfect for the top >driver for horns. I recall something about high speed of sound. It is also used for mirrors for certain, usually classified, applications. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Fri Jan 16 20:12:12 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 16 Jan 2009 20:12:12 +0000 Subject: [time-nuts] beryllium oxide In-Reply-To: Your message of "Fri, 16 Jan 2009 20:10:53 GMT." <22975.1232136653@critter.freebsd.dk> Message-ID: <23010.1232136732@critter.freebsd.dk> In message <22975.1232136653 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >It is also used for mirrors for certain, usually classified, >applications. Actually, isn't the James Webb space telescope using a Be mirror now that I think about it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From kc0vsj at yahoo.com Fri Jan 16 20:20:39 2009 From: kc0vsj at yahoo.com (Tom Clifton) Date: Fri, 16 Jan 2009 12:20:39 -0800 (PST) Subject: [time-nuts] beryllium oxide Message-ID: <894801.88483.qm@web37006.mail.mud.yahoo.com> Also used on old "lighthouse" tubes used for uhf and low microwave applications fro the '40's and '50's. If my memory serves me, these tubes were found in devices like the airborne APX-6 IFF Transponder in which the greatest hazard was the detonators used to destroy the device should a plane go down over enemy teritory... An instrucor in the 70's made sure we were paranoid about both the berylium oxide and explosives... From mike.clapp at gmail.com Fri Jan 16 20:25:33 2009 From: mike.clapp at gmail.com (Mike Clapp) Date: Fri, 16 Jan 2009 15:25:33 -0500 Subject: [time-nuts] beryllium oxide In-Reply-To: <894801.88483.qm@web37006.mail.mud.yahoo.com> References: <894801.88483.qm@web37006.mail.mud.yahoo.com> Message-ID: <230c2f110901161225h37360437w25db82bbb01c2fd2@mail.gmail.com> James Webb space telescope and Utah Beryllium mine http://heliophysics.org/headlines/y2008/10dec_mirror.htm On Fri, Jan 16, 2009 at 3:20 PM, Tom Clifton wrote: > Also used on old "lighthouse" tubes used for uhf and low microwave > applications fro the '40's and '50's. If my memory serves me, these tubes > were found in devices like the airborne APX-6 IFF Transponder in which the > greatest hazard was the detonators used to destroy the device should a plane > go down over enemy teritory... > > An instrucor in the 70's made sure we were paranoid about both the berylium > oxide and explosives... > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From imp at bsdimp.com Fri Jan 16 20:34:03 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri, 16 Jan 2009 13:34:03 -0700 (MST) Subject: [time-nuts] beryllium oxide In-Reply-To: References: Message-ID: <20090116.133403.-432807207.imp@bsdimp.com> But what about the Beryllium Sphere? What happens when you activate that? Warner In message: Mark Sims writes: : Three other places one may encounter beryllium are: : : 1) Beryllium copper springs and contacts, usually around 2-3% beryllium. Not likely to cause a problem unless you get your jollies grinding up springy metal and snorting the powder. : : 2) Beryllium tools! Tools (particularly screwdrivers and pliers) can be made out of pure beryllium metal. They are not magnetic, very strong, very light. They were used a lot in aerospace and military applications. One thing that used to appear on the surplus market was an EOD toolkit used by bomb disposal techs. Even had a beryllium hammer. These were wonderful tools which you might just find when clearing out old uncle Bob's estate... : : 3) Nuclear reactors and weapons. Be careful when disassembling that surplus nuke you picked up on your last trip to eastern Europe... : : Beryllium was originally called glucinium becuase it and its salts tasted very sweet. In fact, tasting used to be a diagnostic test for the presence of beryllium. : _________________________________________________________________ : Windows Live?: Keep your life in sync. : http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 : _______________________________________________ : time-nuts mailing list -- time-nuts at febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : From bruce.griffiths at xtra.co.nz Fri Jan 16 20:37:28 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 17 Jan 2009 09:37:28 +1300 Subject: [time-nuts] beryllium oxide In-Reply-To: <22975.1232136653@critter.freebsd.dk> References: <22975.1232136653@critter.freebsd.dk> Message-ID: <4970F008.9000602@xtra.co.nz> Poul-Henning Kamp wrote: > In message <4970E72D.1050300 at rubidium.dyndns.org>, Magnus Danielson writes: > > >> I have encountered Beryllium in a field none of you mentioned, as >> material for speaker cones. Light and very rigid. Perfect for the top >> driver for horns. I recall something about high speed of sound. >> > > It is also used for mirrors for certain, usually classified, > applications. > > One unclassified application is the 1.12m diameter secondary mirrors of ESO's 4 VLT telescopes in Chile. Bruce From bruce.griffiths at xtra.co.nz Fri Jan 16 20:49:35 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 17 Jan 2009 09:49:35 +1300 Subject: [time-nuts] beryllium oxide In-Reply-To: <4970F008.9000602@xtra.co.nz> References: <22975.1232136653@critter.freebsd.dk> <4970F008.9000602@xtra.co.nz> Message-ID: <4970F2DF.1030802@xtra.co.nz> Bruce Griffiths wrote: > Poul-Henning Kamp wrote: > >> In message <4970E72D.1050300 at rubidium.dyndns.org>, Magnus Danielson writes: >> >> >> >>> I have encountered Beryllium in a field none of you mentioned, as >>> material for speaker cones. Light and very rigid. Perfect for the top >>> driver for horns. I recall something about high speed of sound. >>> >>> >> It is also used for mirrors for certain, usually classified, >> applications. >> >> >> > One unclassified application is the 1.12m diameter secondary mirrors of > ESO's 4 VLT telescopes in Chile. > > > Bruce > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > For additional applications in some classified and unclassified programs: http://www.mdatechnology.net/techprofile.aspx?id=175 An application for breyllium mirrors at CERN: http://cdsweb.cern.ch/record/944244?ln=no Bruce From wb6bnq at cox.net Fri Jan 16 20:52:41 2009 From: wb6bnq at cox.net (WB6BNQ) Date: Fri, 16 Jan 2009 12:52:41 -0800 Subject: [time-nuts] beryllium oxide References: Message-ID: <4970F399.6F32E227@cox.net> Another place to find it is in old Motorola two-way radio high power VHF amplifiers. These amplifiers used a solid metal anode and the the tubes were clamped up against a beryllium block (white square about 3/4 inch) that was attached to a heat sink. Bill....WB6BNQ From namichie at gmail.com Fri Jan 16 21:10:28 2009 From: namichie at gmail.com (Neville Michie) Date: Sat, 17 Jan 2009 08:10:28 +1100 Subject: [time-nuts] beryllium oxide In-Reply-To: <4970F399.6F32E227@cox.net> References: <4970F399.6F32E227@cox.net> Message-ID: > I was once told that the white sticky paste put under power > transistors years ago as a heat conduction aid was dangerous because it was based on berylium oxide cheers, Neville Michie > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ > time-nuts > and follow the instructions there. From brooke at pacific.net Fri Jan 16 21:51:19 2009 From: brooke at pacific.net (Brooke Clarke) Date: Fri, 16 Jan 2009 13:51:19 -0800 Subject: [time-nuts] beryllium oxide In-Reply-To: <4970F2DF.1030802@xtra.co.nz> References: <22975.1232136653@critter.freebsd.dk> <4970F008.9000602@xtra.co.nz> <4970F2DF.1030802@xtra.co.nz> Message-ID: <49710157.5030900@pacific.net> Hi Bruce: Thanks for the MDA Technology link. I didn't know that Beryllium was used to make mirrors and their metering structures for space apps. It sure sounds like the best material for that use. I'd bet that's how spy sat mirrors are made. Have Fun, Brooke Clarke http://www.prc68.com Bruce Griffiths wrote: > Bruce Griffiths wrote: >> Poul-Henning Kamp wrote: >> >>> In message <4970E72D.1050300 at rubidium.dyndns.org>, Magnus Danielson writes: >>> >>> >>> >>>> I have encountered Beryllium in a field none of you mentioned, as >>>> material for speaker cones. Light and very rigid. Perfect for the top >>>> driver for horns. I recall something about high speed of sound. >>>> >>>> >>> It is also used for mirrors for certain, usually classified, >>> applications. >>> >>> >>> >> One unclassified application is the 1.12m diameter secondary mirrors of >> ESO's 4 VLT telescopes in Chile. >> >> >> Bruce >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > For additional applications in some classified and unclassified programs: > > http://www.mdatechnology.net/techprofile.aspx?id=175 > > An application for breyllium mirrors at CERN: > http://cdsweb.cern.ch/record/944244?ln=no > > Bruce > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From phk at phk.freebsd.dk Fri Jan 16 22:10:25 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 16 Jan 2009 22:10:25 +0000 Subject: [time-nuts] beryllium oxide In-Reply-To: Your message of "Fri, 16 Jan 2009 13:51:19 PST." <49710157.5030900@pacific.net> Message-ID: <23436.1232143825@critter.freebsd.dk> In message <49710157.5030900 at pacific.net>, Brooke Clarke writes: >I'd bet that's how spy sat mirrors are made. Your Tax Money At Work Quiz: 1. Why do you think there was so little research involved in the mirror construction for the Webb Telescope ? 2. Why do you think the KeyHole satellites where so friggin expensive ? 3. Connect the dots. :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From sar10538 at gmail.com Fri Jan 16 22:15:23 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Sat, 17 Jan 2009 11:15:23 +1300 Subject: [time-nuts] beryllium oxide In-Reply-To: <23436.1232143825@critter.freebsd.dk> References: <49710157.5030900@pacific.net> <23436.1232143825@critter.freebsd.dk> Message-ID: <1231b6a80901161415v32c37305u5a88d0aaa342e545@mail.gmail.com> Guys, isn't this whole thread getting a bit off-topic. 2009/1/17 Poul-Henning Kamp : > In message <49710157.5030900 at pacific.net>, Brooke Clarke writes: > >>I'd bet that's how spy sat mirrors are made. > > Your Tax Money At Work Quiz: > > 1. Why do you think there was so little research involved in the > mirror construction for the Webb Telescope ? > > 2. Why do you think the KeyHole satellites where so friggin expensive ? > > 3. Connect the dots. > > :-) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From holrum at hotmail.com Fri Jan 16 22:20:22 2009 From: holrum at hotmail.com (Mark Sims) Date: Fri, 16 Jan 2009 22:20:22 +0000 Subject: [time-nuts] Beryllium mirror In-Reply-To: References: Message-ID: For $72.95 you can own your very own beryllium mirror.... Ebay item 350134412234. Note that all the beryllium tools listed on Ebay are copper or aluminium alloy non-sparking tools... not those lovely old surplus EOD tools. _________________________________________________________________ Windows Live? Hotmail?: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 From james.p.lux at jpl.nasa.gov Fri Jan 16 22:33:15 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Fri, 16 Jan 2009 14:33:15 -0800 Subject: [time-nuts] beryllium oxide In-Reply-To: <20090116.133403.-432807207.imp@bsdimp.com> Message-ID: On 1/16/09 12:34 PM, "M. Warner Losh" wrote: > But what about the Beryllium Sphere? What happens when you activate > that? > > Warner > The sphere merely provides the power for the Omega 13. That's what gets activated. And now that you mention such things, the Omega 13 has effects that would surely interest a time-nut. For all we know tvb has one (or three) stashed in his secret lair. From w1ksz at earthlink.net Sat Jan 17 00:03:40 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Fri, 16 Jan 2009 17:03:40 -0700 (GMT-07:00) Subject: [time-nuts] beryllium oxide Message-ID: <29752186.1232150621148.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Also in the Heath SB-230. I wish I still had mine. 73, Dick, W1KSZ -----Original Message----- >From: WB6BNQ >Sent: Jan 16, 2009 1:52 PM >To: Discussion of precise time and frequency measurement >Subject: Re: [time-nuts] beryllium oxide > > >Another place to find it is in old Motorola two-way radio high power VHF amplifiers. These amplifiers used a solid metal anode and the the tubes were clamped >up against a beryllium block (white square about 3/4 inch) that was attached to a heat sink. > >Bill....WB6BNQ > > > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From garnere at gmail.com Sat Jan 17 03:12:22 2009 From: garnere at gmail.com (Eric Garner) Date: Fri, 16 Jan 2009 19:12:22 -0800 Subject: [time-nuts] beryllium oxide In-Reply-To: <1231b6a80901161415v32c37305u5a88d0aaa342e545@mail.gmail.com> References: <49710157.5030900@pacific.net> <23436.1232143825@critter.freebsd.dk> <1231b6a80901161415v32c37305u5a88d0aaa342e545@mail.gmail.com> Message-ID: Re: Beryllium was originally called glucinium becuase it and its salts tasted very sweet. In fact, tasting used to be a diagnostic test for the presence of beryllium. I remember from my inorganic chem course that lead acetate was also called "sugar of lead" because of it's sweet taste. and if tasting lead salts doesn't send a shiver up your spine... http://en.wikipedia.org/wiki/Lead(II)_acetate On Fri, Jan 16, 2009 at 2:15 PM, Steve Rooke wrote: > Guys, isn't this whole thread getting a bit off-topic. > Yes, it is getting off topic. Delightfully so. > 2009/1/17 Poul-Henning Kamp : >> In message <49710157.5030900 at pacific.net>, Brooke Clarke writes: >> >>>I'd bet that's how spy sat mirrors are made. >> >> Your Tax Money At Work Quiz: >> >> 1. Why do you think there was so little research involved in the >> mirror construction for the Webb Telescope ? >> >> 2. Why do you think the KeyHole satellites where so friggin expensive ? >> >> 3. Connect the dots. >> >> :-) >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk at FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > > > -- > Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW > Omnium finis imminet > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- --Eric _________________________________________ Eric Garner From Hrosenberg at catena.nl Sat Jan 17 15:46:36 2009 From: Hrosenberg at catena.nl (Hans Rosenberg) Date: Sat, 17 Jan 2009 16:46:36 +0100 Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <496E5BF3.4000500@xtra.co.nz> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> <496E547C.2050408@xtra.co.nz> <496E557E.2040604@xtra.co.nz>,<496E5BF3.4000500@xtra.co.nz> Message-ID: <403082D2BFB6104D8DC09D14E1770CBA0557977E9B@CMESVRMS01.topcat.catenagroup.com> Hi Bruce, Thanks a lot for all the input. Do you have any figures on the noise voltage on a led? A good buried zener reference does 100nV/rt Hz, what does a led do? You mention that an amplitude control mechanism influences phase noise. Are you suggesting that a good amplitude control is better than turning off the active device for some time each cycle? I started having a close look at the driscoll design. It looks really nice. It seems much more elegant than what I was trying to do. I do have one question about the AGC circuit. The tune-voltage must be kept in the middle of the supply, otherwise the amplitude control loop will modulate the overall capacitance of the capacitive attenuator. So this is critical to set correctly in practice. There probably is a good reason why the current in the transistor is not changed to achieve amplitude control. Do the capacitances in the transistors vary so much that they start introducing more phase errors than when tuning a capacitive attenuator correctly? Or is there another reason. My isolation chain is indeed build with cb stages and not cascodes (wrong terminology from my side). I generate a current using a degenerated differential pair (the solution in the driscoll oscillator looks much more elegant). My limiterstage is build with a differential pair with 2 resistors in the collectors. The differential limited voltage goes to a transformer. The secondary side of that transformer is biased to 1.4V and drives a 74ABT inverter. I choose these inverters for their very low output impedance so I can drive a load with a high slewrate. However too much slewrate may cause a lot of interference and maybe reflections, so I'm thinking about putting a 33OHm resistor in series with the output to limit the bandwidth and reflections somewhat. Do you have any experience which family of ports (ac, hc, abt etc) delivers the best phase noise results (I should not have that much problems since I'm driving it with a pretty good squarewave but am curious what you think of it). I also would really like to get my hands on a 33.8688MHz SC-cut crystal, but I found they are hard to get. I guess this means starting up a production run at a manufacturer which is quite expensive. And I guess I'd have to include a temperature control circuit since the temperature characteristics of SC-cut crystals are not that good. Nice to hear that you're into optics as well! I build some basic telescopes, although I never made my own lenses or mirrors. But I'm very fascinated by the subject. I used to work for ASTRON, which is a company that builds radiotelescopes. I also used to give stargazing evenings for tourists at a local observatory which was a lot of fun. We had a 60cm mirrortelescope there. Unfortunately, this is a bit of overkill in holland with the bad seeing we usually have here. Thanks again for the nice input. Best regards, Hans Rosenberg ________________________________________ From: time-nuts-bounces at febo.com [time-nuts-bounces at febo.com] On Behalf Of Bruce Griffiths [bruce.griffiths at xtra.co.nz] Sent: Wednesday, January 14, 2009 10:41 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Ultra low noise Pierce oscillator??? Bruce Griffiths wrote: > Bruce Griffiths wrote: > >> Hans >> >> Hans Rosenberg wrote: >> >> >>> Hi Time-nuts people, >>> >>> I'm new to this forum and really enjoyed reading all the design strategies on oscillators. >>> >>> I'm currently designing a low noise oscillator and I wonder if you can help me with some questions. I've attached a picture of the oscillator core I'm using. I decided to go for a Pierce design some time ago after looking at a few topologies. I took a number of measures to give the design a low 1/f noise. >>> >>> >>> 1. Low DC gain. There is a transformer in the drain line. >>> 2. Ultra low noise supply (not on the schematic) using an ad586 buried zener reference with a -3dB lowpass at 0.1Hz. This 5V reference is then increased to 12V using a low noise discrete buffer. >>> 3. The phase shift across T1 is only a few degrees (<5degrees), low phaseshift in the amplifier reduces 1/f noise. >>> 4. I chose a fet in order to minimize the load at the 'output' of the crystal, the only load I have now is the bias resistor of 100k. This resistor does cause low frequency noise (at higher frequencies C1 shorts it). This may be the problem in this circuit, Cgd is modulated by this noise and a low frequency voltage is applied at the gate, which is however not amplified because of the currentsource in the source line which should cause nearly infinite feedback for low frequencies making the DC gain even lower. >>> 5. The current source produces low frequency noise. I have to have a current source though (I could use a resistor but I calculated that produces more noise). I could increase the voltage across R5 and make R5 bigger to reduce the noise, however, this will reduce Vgd which means modulation of Cgd becomes worse. I think I'm ok here by dividing the voltage across the currentsource and the active oscillator element in half. Cgd of a J309 is around 2.5pF at Vds=10V (it is a little higher in my case since Vgd is lower) >>> 6. L2 can be mounted to accommodate overtone crystals. ( I still have to calculate a value for L2 and C2 to get the correct impedance at resonance) >>> 7. F1 and F2 are ferrite beads with a low impedance at DC (far less then an ohm) and rising impedance at higher frequencies to prevent oscillation of the RF transistors. >>> 8. I've found a really good overtonecrystal from Citizen. CM309S. I measured the unloaded Q to be 313000, the loaded Q (using simple estimation) should be around 280000 in the circuit. (C0=2.5pF, R=20Ohm, C1=0.75fF, L=29.444mH, can be aquired at digikey). The spec for Rs was <130Ohms, I guess reality is much better :-) >>> 9. The transformeroutputs are going to an isolationchain using 3 cascodes and then a discrete limiter not shown on the schematic. >>> 10. This whole oscillator core will be placed in an RF shielding can. The isolationchain will have a can of it's own to so pulling should be nearly eliminated. >>> >>> Now my questions are: >>> >>> >>> 1. I don't see a pierce design in any of the low noise oscillator circuits in the discussion threads about low noise oscillator design. Is there something fundamentally wrong about this topology? >>> 2. I read a few times that ferrites in inductors (and I assume transformers as well) can be a real problem for 1/f noise. I'm using a transformer (TC1-1t from minicircuits) which is made with a ferrite bead. Do you know of any transformers or inductors that have low 1/f noise ferrite material. >>> 3. Have I missed something fundamental in the design. The goal is to build a very good oscillator. I would like to achieve something like -110dBc/Hz at 10Hz distance at 33.8688MHz. >>> >>> Thanks in advance for having a look and best regards, >>> >>> Hans Rosenberg >>> >>> >>> >>> >> 1) A LED plus a BJT and resistor makes a much lower noise current source >> than a zener based reference plus a BJT and resistor. >> Some shielding of the LED from ambient light may be required as LEDs (as >> all PN junctions) are photosensitive. >> A resistor in series with an RF choke can be used to replace the current >> source. >> >> 2) A BJT with a correctly proportioned coupling network will not >> significantly load the crystal. >> >> 3) There is little isolation between the oscillator and the load, a >> slight change in topology will improve this. >> >> 4) Modified Pierce overtone crystal oscillators using JFETs were popular >> in the 1960's and 1970's. >> >> 5) The amplitude limiting mechanism in the oscillator is important as it >> affects the phase noise. >> >> 6) A lower noise audio BJT will make a much lower (flicker) noise >> current source than a 9GHz transistor. >> >> 7) Its usually better to use the crystal to filter the output signal. >> >> 8) One of the Driscoll BJT oscillators or a variant thereof is a good >> stating point. >> AGC via a varactor based attenuator can be used. >> The output signal can be extracted from the second transistor collector >> using a transformer with little interaction with the collector tank tuning. >> >> >> Bruce >> >> >> > Addendum > > 9) Having a dc voltage across the crystal isnt a good idea as it can > lead to unwanted phase modulation. > > > 10) The current source transistor collector base voltage seems a little low. > > Bruce > > Addendum II 11) A common base cascade will have much lower noise than a cascode chain, however the CB cascade needs a current input. This can be derived in your modified Pierce circuit by connecting C1 to the emitter of the input CB transistor rather than to ground. The transformer is then not required. A lower impedance input at the CB stage emitter can be achieved by replacing the Cb transistor by a CECB feedback pair. Whats the limiter circuit? Is it at the cascode buffer chain output? Bruce _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From richard at karlquist.com Sat Jan 17 16:21:41 2009 From: richard at karlquist.com (Richard (Rick) Karlquist) Date: Sat, 17 Jan 2009 09:21:41 -0700 Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <403082D2BFB6104D8DC09D14E1770CBA0557977E9B@CMESVRMS01.topcat.catenagroup.com> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> <496E547C.2050408@xtra.co.nz> <496E557E.2040604@xtra.co.nz>, <496E5BF3.4000500@xtra.co.nz> <403082D2BFB6104D8DC09D14E1770CBA0557977E9B@CMESVRMS01.topcat.catenagroup.com> Message-ID: <49720595.2020304@karlquist.com> I would like to add some perspective to this discussion. The 10811 oscillator simply uses a plain vanilla Pierce circuit configured so that one terminal of the crystal is at ground. The base emitter capacitor is replaced by a mode suppression network to force operation to the correct overtone and mode (C as opposed to B). It uses a common (at the time) transistor, the 2N5179. The AGC varies the DC collector current in the transistor. A zener diode of a type which is known to have low noise is used to bias the varactor. There is no magic here. The results are that below 100 Hz, the noise is strictly determined by the intrinsic crystal noise (yes, crystals have their own noise). Intrinsic crystal noise can be measured with an HP3048 type phase noise system, if you know what you are doing. At 1 kHz and above, the noise is strictly determined by the buffer amplifier following the oscillator circuit. Read Rob Burgoon's patent to understand why his patented buffer is the best that can be built (ie limited by physics). The actual buffer used in the 10811 has some compromises in it that increase the phase noise floor. You can easily get back to optimum performance by using a string of common base amplifiers. It is therefore puzzling to me that there is a search for the holy grail low noise oscillator circuit. What is it that you do not like about the 10811 circuit? Rick Karlquist N6RK From N3IZN at aol.com Sat Jan 17 19:52:47 2009 From: N3IZN at aol.com (N3IZN at aol.com) Date: Sat, 17 Jan 2009 14:52:47 EST Subject: [time-nuts] Free programs to read NEMA data. Message-ID: What good programs are out there to read NEMA data? Nothing fancy but able to sync time would be great. Was using NMEAT on old PC but can't find the registration code. **************Inauguration '09: Get complete coverage from the nation's capital. (http://news.aol.com/main/politics/inauguration?ncid=emlcntusnews00000003) From bruce.griffiths at xtra.co.nz Sat Jan 17 21:15:05 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 18 Jan 2009 10:15:05 +1300 Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <403082D2BFB6104D8DC09D14E1770CBA0557977E9B@CMESVRMS01.topcat.catenagroup.com> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> <496E547C.2050408@xtra.co.nz> <496E557E.2040604@xtra.co.nz>, <496E5BF3.4000500@xtra.co.nz> <403082D2BFB6104D8DC09D14E1770CBA0557977E9B@CMESVRMS01.topcat.catenagroup.com> Message-ID: <49724A59.5080708@xtra.co.nz> Hans Hans Rosenberg wrote: > Hi Bruce, > > Thanks a lot for all the input. > > Do you have any figures on the noise voltage on a led? A good buried zener reference does 100nV/rt Hz, what does a led do? > > A good one (like all forward biased PN junctions) will be much quieter than a zener. > You mention that an amplitude control mechanism influences phase noise. Are you suggesting that a good amplitude control is better than turning off the active device for some time each cycle? > > I started having a close look at the driscoll design. It looks really nice. It seems much more elegant than what I was trying to do. I do have one question about the AGC circuit. The tune-voltage must be kept in the middle of the supply, otherwise the amplitude control loop will modulate the overall capacitance of the capacitive attenuator. So this is critical to set correctly in practice. There probably is a good reason why the current in the transistor is not changed to achieve amplitude control. Do the capacitances in the transistors vary so much that they start introducing more phase errors than when tuning a capacitive attenuator correctly? Or is there another reason. > > My isolation chain is indeed build with cb stages and not cascodes (wrong terminology from my side). I generate a current using a degenerated differential pair (the solution in the driscoll oscillator looks much more elegant). My limiterstage is build with a differential pair with 2 resistors in the collectors. The differential limited voltage goes to a transformer. The secondary side of that transformer is biased to 1.4V and drives a 74ABT inverter. I choose these inverters for their very low output impedance so I can drive a load with a high slewrate. However too much slewrate may cause a lot of interference and maybe reflections, so I'm thinking about putting a 33OHm resistor in series with the output to limit the bandwidth and reflections somewhat. Do you have any experience which family of ports (ac, hc, abt etc) delivers the best phase noise results (I should not have that much problems since I'm driving it with a pretty good squarewave but am curious what you think of it). > > A self biased inverter with resistive feedback between input and output driven directly with the RF signal (~1V rms amplitude for 3V Vcc) usually has a slightly lower phase noise. However one then needs to ensure that the RF input signal is always present (otherwise Vcc current can be high). RC decoupling the Vcc supply of the inverter is also useful. I have no data on ABT devices, you would need to measure it - not too difficult (no phase lock loop required just a phase shifter) with a splitter, sound card, a mixer etc. > I also would really like to get my hands on a 33.8688MHz SC-cut crystal, but I found they are hard to get. I guess this means starting up a production run at a manufacturer which is quite expensive. And I guess I'd have to include a temperature control circuit since the temperature characteristics of SC-cut crystals are not that good. > > Using a LED within an oven may not be that reliable, depending on the LED packaging and operating current. > Nice to hear that you're into optics as well! I build some basic telescopes, although I never made my own lenses or mirrors. But I'm very fascinated by the subject. I used to work for ASTRON, which is a company that builds radiotelescopes. I also used to give stargazing evenings for tourists at a local observatory which was a lot of fun. We had a 60cm mirrortelescope there. Unfortunately, this is a bit of overkill in holland with the bad seeing we usually have here. > > The local astronomical society has a 61cm classical Cassegrain plus a 14"Meade and various Dobsonians. We also have a dish for radio astronomy (but no hydrogen maser). > Thanks again for the nice input. > > Best regards, > > Hans Rosenberg > > ________________________________________ > From: time-nuts-bounces at febo.com [time-nuts-bounces at febo.com] On Behalf Of Bruce Griffiths [bruce.griffiths at xtra.co.nz] > Sent: Wednesday, January 14, 2009 10:41 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Ultra low noise Pierce oscillator??? > > Bruce Griffiths wrote: > >> Bruce Griffiths wrote: >> >> >>> Hans >>> >>> Hans Rosenberg wrote: >>> >>> >>> >>>> Hi Time-nuts people, >>>> >>>> I'm new to this forum and really enjoyed reading all the design strategies on oscillators. >>>> >>>> I'm currently designing a low noise oscillator and I wonder if you can help me with some questions. I've attached a picture of the oscillator core I'm using. I decided to go for a Pierce design some time ago after looking at a few topologies. I took a number of measures to give the design a low 1/f noise. >>>> >>>> >>>> 1. Low DC gain. There is a transformer in the drain line. >>>> 2. Ultra low noise supply (not on the schematic) using an ad586 buried zener reference with a -3dB lowpass at 0.1Hz. This 5V reference is then increased to 12V using a low noise discrete buffer. >>>> 3. The phase shift across T1 is only a few degrees (<5degrees), low phaseshift in the amplifier reduces 1/f noise. >>>> 4. I chose a fet in order to minimize the load at the 'output' of the crystal, the only load I have now is the bias resistor of 100k. This resistor does cause low frequency noise (at higher frequencies C1 shorts it). This may be the problem in this circuit, Cgd is modulated by this noise and a low frequency voltage is applied at the gate, which is however not amplified because of the currentsource in the source line which should cause nearly infinite feedback for low frequencies making the DC gain even lower. >>>> 5. The current source produces low frequency noise. I have to have a current source though (I could use a resistor but I calculated that produces more noise). I could increase the voltage across R5 and make R5 bigger to reduce the noise, however, this will reduce Vgd which means modulation of Cgd becomes worse. I think I'm ok here by dividing the voltage across the currentsource and the active oscillator element in half. Cgd of a J309 is around 2.5pF at Vds=10V (it is a little higher in my case since Vgd is lower) >>>> 6. L2 can be mounted to accommodate overtone crystals. ( I still have to calculate a value for L2 and C2 to get the correct impedance at resonance) >>>> 7. F1 and F2 are ferrite beads with a low impedance at DC (far less then an ohm) and rising impedance at higher frequencies to prevent oscillation of the RF transistors. >>>> 8. I've found a really good overtonecrystal from Citizen. CM309S. I measured the unloaded Q to be 313000, the loaded Q (using simple estimation) should be around 280000 in the circuit. (C0=2.5pF, R=20Ohm, C1=0.75fF, L=29.444mH, can be aquired at digikey). The spec for Rs was <130Ohms, I guess reality is much better :-) >>>> 9. The transformeroutputs are going to an isolationchain using 3 cascodes and then a discrete limiter not shown on the schematic. >>>> 10. This whole oscillator core will be placed in an RF shielding can. The isolationchain will have a can of it's own to so pulling should be nearly eliminated. >>>> >>>> Now my questions are: >>>> >>>> >>>> 1. I don't see a pierce design in any of the low noise oscillator circuits in the discussion threads about low noise oscillator design. Is there something fundamentally wrong about this topology? >>>> 2. I read a few times that ferrites in inductors (and I assume transformers as well) can be a real problem for 1/f noise. I'm using a transformer (TC1-1t from minicircuits) which is made with a ferrite bead. Do you know of any transformers or inductors that have low 1/f noise ferrite material. >>>> 3. Have I missed something fundamental in the design. The goal is to build a very good oscillator. I would like to achieve something like -110dBc/Hz at 10Hz distance at 33.8688MHz. >>>> >>>> Thanks in advance for having a look and best regards, >>>> >>>> Hans Rosenberg >>>> >>>> >>>> >>>> >>>> >>> 1) A LED plus a BJT and resistor makes a much lower noise current source >>> than a zener based reference plus a BJT and resistor. >>> Some shielding of the LED from ambient light may be required as LEDs (as >>> all PN junctions) are photosensitive. >>> A resistor in series with an RF choke can be used to replace the current >>> source. >>> >>> 2) A BJT with a correctly proportioned coupling network will not >>> significantly load the crystal. >>> >>> 3) There is little isolation between the oscillator and the load, a >>> slight change in topology will improve this. >>> >>> 4) Modified Pierce overtone crystal oscillators using JFETs were popular >>> in the 1960's and 1970's. >>> >>> 5) The amplitude limiting mechanism in the oscillator is important as it >>> affects the phase noise. >>> >>> 6) A lower noise audio BJT will make a much lower (flicker) noise >>> current source than a 9GHz transistor. >>> >>> 7) Its usually better to use the crystal to filter the output signal. >>> >>> 8) One of the Driscoll BJT oscillators or a variant thereof is a good >>> stating point. >>> AGC via a varactor based attenuator can be used. >>> The output signal can be extracted from the second transistor collector >>> using a transformer with little interaction with the collector tank tuning. >>> >>> >>> Bruce >>> >>> >>> >>> >> Addendum >> >> 9) Having a dc voltage across the crystal isnt a good idea as it can >> lead to unwanted phase modulation. >> >> >> 10) The current source transistor collector base voltage seems a little low. >> >> Bruce >> >> >> > Addendum II > > 11) A common base cascade will have much lower noise than a cascode > chain, however the CB cascade needs a current input. > This can be derived in your modified Pierce circuit by connecting C1 to > the emitter of the input CB transistor rather than to ground. > The transformer is then not required. > A lower impedance input at the CB stage emitter can be achieved by > replacing the Cb transistor by a CECB feedback pair. > > Whats the limiter circuit? > Is it at the cascode buffer chain output? > > Bruce > > Bruce From bruce.griffiths at xtra.co.nz Sat Jan 17 21:43:41 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 18 Jan 2009 10:43:41 +1300 Subject: [time-nuts] Ultra low noise Pierce oscillator??? In-Reply-To: <403082D2BFB6104D8DC09D14E1770CBA0557977E9B@CMESVRMS01.topcat.catenagroup.com> References: <403082D2BFB6104D8DC09D14E1770CBA05579E6538@CMESVRMS01.topcat.catenagroup.com> <496E547C.2050408@xtra.co.nz> <496E557E.2040604@xtra.co.nz>, <496E5BF3.4000500@xtra.co.nz> <403082D2BFB6104D8DC09D14E1770CBA0557977E9B@CMESVRMS01.topcat.catenagroup.com> Message-ID: <4972510D.20108@xtra.co.nz> Hans Hans Rosenberg wrote: > Hi Bruce, > > Thanks a lot for all the input. > > Do you have any figures on the noise voltage on a led? A good buried zener reference does 100nV/rt Hz, what does a led do? > > You mention that an amplitude control mechanism influences phase noise. Are you suggesting that a good amplitude control is better than turning off the active device for some time each cycle? > > There is some debate about this in the literature. > I started having a close look at the driscoll design. It looks really nice. It seems much more elegant than what I was trying to do. I do have one question about the AGC circuit. The tune-voltage must be kept in the middle of the supply, otherwise the amplitude control loop will modulate the overall capacitance of the capacitive attenuator. The input capacitance doesn't vary that much if the attenuator is correctly proportioned: http://www.karlquist.com/97bri.pdf > So this is critical to set correctly in practice. There probably is a good reason why the current in the transistor is not changed to achieve amplitude control. Do the capacitances in the transistors vary so much that they start introducing more phase errors than when tuning a capacitive attenuator correctly? Or is there another reason. > > > Thanks again for the nice input. > > Best regards, > > Hans Rosenberg > > Bruce From N3IZN at aol.com Sat Jan 17 23:16:43 2009 From: N3IZN at aol.com (N3IZN at aol.com) Date: Sat, 17 Jan 2009 18:16:43 EST Subject: [time-nuts] Free programs to read NEMA data. Message-ID: OK I found my registration for NMEAT. Now that I upgraded my hobby PC I'm giving it a work out by running as many applications as I can. I have NMEAT running from a Jupiter GPS engine and I have T-Bolt mon going at the same time. They are 16 seconds off from each other? I see on Tboltmon there is a field for UTC offset and 15 seconds is entered there. Any ideas? Chris What good programs are out there to read NEMA data? Nothing fancy but able to sync time would be great. Was using NMEAT on old PC but can't find the registration code. **************Inauguration '09: Get complete coverage from the nation's capital. (http://news.aol.com/main/politics/inauguration?ncid=emlcntusnews00000003) From imp at bsdimp.com Sat Jan 17 23:30:31 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 17 Jan 2009 16:30:31 -0700 (MST) Subject: [time-nuts] Free programs to read NEMA data. In-Reply-To: References: Message-ID: <20090117.163031.-713520017.imp@bsdimp.com> In message: N3IZN at aol.com writes: : : OK I found my registration for NMEAT. Now that I upgraded my hobby PC I'm : giving it a work out by running as many applications as I can. I have NMEAT : running from a Jupiter GPS engine and I have T-Bolt mon going at the same time. : They are 16 seconds off from each other? I see on Tboltmon there is a field : for UTC offset and 15 seconds is entered there. Any ideas? The current UTC GPS offset is 16, and has been for the last 17 days or so :) Warner From bg at lysator.liu.se Sat Jan 17 23:55:33 2009 From: bg at lysator.liu.se (=?ISO-8859-1?Q?Bj=F6rn?= Gabrielsson) Date: Sun, 18 Jan 2009 00:55:33 +0100 Subject: [time-nuts] Free programs to read NEMA data. In-Reply-To: <20090117.163031.-713520017.imp@bsdimp.com> References: <20090117.163031.-713520017.imp@bsdimp.com> Message-ID: <1232236533.26603.8.camel@bg-desktop> Hi Warner, On Sat, 2009-01-17 at 16:30 -0700, M. Warner Losh wrote: > In message: > N3IZN at aol.com writes: > : > : OK I found my registration for NMEAT. Now that I upgraded my hobby PC I'm > : giving it a work out by running as many applications as I can. I have NMEAT > : running from a Jupiter GPS engine and I have T-Bolt mon going at the same time. > : They are 16 seconds off from each other? I see on Tboltmon there is a field > : for UTC offset and 15 seconds is entered there. Any ideas? > > The current UTC GPS offset is 16, and has been for the last 17 days or > so :) That is not the view of USNO... ftp://tycho.usno.navy.mil/pub/gps/leapsecnanu.txt nor the Meinberg receiver I take care of. $ ntpq -c cv timehost.lysator.liu.se | grep gps_utc gps_utc_correction="current correction 15 sec, last correction on cd068600.00000000 Thu, Jan 1 2009 0:00:00.000", However I once had a Jupiter receiver where the NMEA output came 1.0xx seconds late or 2.0xx seconds late. Btw, the Jupiter/Zodiac binary was much better timed. > Warner -- Bj?rn From imp at bsdimp.com Sun Jan 18 01:17:13 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 17 Jan 2009 18:17:13 -0700 (MST) Subject: [time-nuts] Free programs to read NEMA data. In-Reply-To: <1232236533.26603.8.camel@bg-desktop> References: <20090117.163031.-713520017.imp@bsdimp.com> <1232236533.26603.8.camel@bg-desktop> Message-ID: <20090117.181713.1619583539.imp@bsdimp.com> In message: <1232236533.26603.8.camel at bg-desktop> Bj?rn Gabrielsson writes: : Hi Warner, : : On Sat, 2009-01-17 at 16:30 -0700, M. Warner Losh wrote: : > In message: : > N3IZN at aol.com writes: : > : : > : OK I found my registration for NMEAT. Now that I upgraded my hobby PC I'm : > : giving it a work out by running as many applications as I can. I have NMEAT : > : running from a Jupiter GPS engine and I have T-Bolt mon going at the same time. : > : They are 16 seconds off from each other? I see on Tboltmon there is a field : > : for UTC offset and 15 seconds is entered there. Any ideas? : > : > The current UTC GPS offset is 16, and has been for the last 17 days or : > so :) : : That is not the view of USNO... : : ftp://tycho.usno.navy.mil/pub/gps/leapsecnanu.txt : : nor the Meinberg receiver I take care of. : : $ ntpq -c cv timehost.lysator.liu.se | grep gps_utc : : gps_utc_correction="current correction 15 sec, last correction on : cd068600.00000000 Thu, Jan 1 2009 0:00:00.000", : : However I once had a Jupiter receiver where the NMEA output came 1.0xx : seconds late or 2.0xx seconds late. Btw, the Jupiter/Zodiac binary was : much better timed. Doh! I added two seconds to my internal leap second delta counter. My bad. Warner From N3IZN at aol.com Sun Jan 18 02:43:24 2009 From: N3IZN at aol.com (N3IZN at aol.com) Date: Sat, 17 Jan 2009 21:43:24 EST Subject: [time-nuts] Free programs to read NEMA data. Message-ID: OK I found the place in the Tboltmon to select UTC instead of GPS. Now I have one second difference. I use windows XP to update the PC clock through the internet and it matches the T_Bolt. Lets see what my next device says. And I use to laugh at those guys with too many clocks............. **************Inauguration '09: Get complete coverage from the nation's capital. (http://news.aol.com/main/politics/inauguration?ncid=emlcntusnews00000003) From grant at ghengineering.co.uk Sun Jan 18 20:32:50 2009 From: grant at ghengineering.co.uk (Grant Hodgson) Date: Sun, 18 Jan 2009 20:32:50 +0000 Subject: [time-nuts] Tbolt with Palisade? In-Reply-To: References: Message-ID: <497391F2.7020409@ghengineering.co.uk> Does anybody know how difficult it would be to use just the antenna + LNA part of a Trimble Palisade? Have Tbolt but no antenna. I can get a Palisade for much less than a proper GPS antenna. Coax length would be about 20 feet, connected to the output of the Palisade's LNA (or output filter if fitted). Only possible problem I envisage is that the Palisade LNA will probably have less gain than say a 58532A. However, the latter is designed for long cable runs; I'm guessing that this unusual arrangement might work with a fairly short cable run. Powering the Palisade LNA shouldn't be too difficult me thinks. regards Grant From bill at iaxs.net Sun Jan 18 00:02:04 2009 From: bill at iaxs.net (Bill Hawkins) Date: Sat, 17 Jan 2009 18:02:04 -0600 Subject: [time-nuts] Free programs to read NEMA data. In-Reply-To: References: Message-ID: <65C7F7FCCB594166B523B847CA6B0009@system071> Found this with Google: http://www.holysmoke.org/gps/talker1.htm Full name is NMEATalker Bill Hawkins -----Original Message----- From: Chris N3IZN at aol.com Sent: Saturday, January 17, 2009 5:17 PM OK I found my registration for NMEAT. From bg at lysator.liu.se Sun Jan 18 21:05:11 2009 From: bg at lysator.liu.se (=?ISO-8859-1?Q?Bj=F6rn?= Gabrielsson) Date: Sun, 18 Jan 2009 22:05:11 +0100 Subject: [time-nuts] Tbolt with Palisade? In-Reply-To: <497391F2.7020409@ghengineering.co.uk> References: <497391F2.7020409@ghengineering.co.uk> Message-ID: <1232312711.26603.31.camel@bg-desktop> On Sun, 2009-01-18 at 20:32 +0000, Grant Hodgson wrote: > Does anybody know how difficult it would be to use just the antenna + > LNA part of a Trimble Palisade? Have Tbolt but no antenna. I can get a > Palisade for much less than a proper GPS antenna. Coax length would be > about 20 feet, connected to the output of the Palisade's LNA (or output > filter if fitted). Does the Palisade have an LNA at the antenna? Since it is an integrated receiver antenna construction, I would imagine they use a passive antenna. And you have no ready to use coaxial connector to the Palisade housing. Is it worth your time? Why not take a small mag-mount antenna (++many available at sub $10 at an online auction site close to you.) They usually have up to about 5 meters of thin coax (RG174 or equiv.). -- Bj?rn From stanley_reynolds at yahoo.com Sat Jan 17 21:14:15 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Sat, 17 Jan 2009 13:14:15 -0800 (PST) Subject: [time-nuts] Free programs to read NEMA data. References: Message-ID: <730726.82639.qm@web30301.mail.mud.yahoo.com> I have not used any free programs but TAC32 has lots of features not bad for $55 US for members of TAPR. http://www.tapr.org/gps_tac32.html At $20 why not just get a new key http://www.visualgps.net/NMEATime/?? An email to ask about your key would be?free?and they may have a record of your previous key. I like the program but it is quiting about once a week and needs to be restarted may be the old OS windows 2000 I have it running on. Stanley ________________________________ From: "N3IZN at aol.com" To: time-nuts at febo.com Sent: Saturday, January 17, 2009 1:52:47 PM Subject: [time-nuts] Free programs to read NEMA data. What good programs are out there to read NEMA data? Nothing fancy but able? to sync time would be great. Was using NMEAT on old PC but can't find the? registration code. **************Inauguration '09:? Get complete coverage from the nation's capital. (http://news.aol.com/main/politics/inauguration?ncid=emlcntusnews00000003) _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From stanley_reynolds at yahoo.com Sun Jan 18 03:29:18 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Sat, 17 Jan 2009 19:29:18 -0800 (PST) Subject: [time-nuts] FTS 1000B OCXO from a FTS 4040 CS Message-ID: <822135.80157.qm@web30308.mail.mud.yahoo.com> Was unable to adjust to 5Mhz, 4.9999752 was the best I could get with external pot. Internal pot has no effect, assume it is disconnected when external is present ? Was not hard to dissemble, the oven is not warm but has 29 volts maybe problem in the control circuit. Does anyone have any info I could use ? I have downloaded a 4040B operation manual but it is not that similar to the 4040. This unit uses a 1802 RCA microprocessor so is much older than the B model, think it uses a 68xx type processor. I have no manuals for the FTS-4040 and been unable to connect a PC to the 9 pin monitor/sync connector on the back, I need the pin out and perhaps a older monitor program as I only have monitor 2 and monitor 3 programs. What I can see of the ocxo outside: Has 2 SMA RF out connectors and a 9 pin D connector inside: Oven was inside a glass vacuum bottle with layers of foam insulation to close one end. 2 MTH15N20 transistors to heat the oven temp sensor on a small separate pc board part #56219-03909 REV A attached to oven main board not insulated is part # 56219-06802-00 REV D From bg at lysator.liu.se Sun Jan 18 22:57:56 2009 From: bg at lysator.liu.se (=?ISO-8859-1?Q?Bj=F6rn?= Gabrielsson) Date: Sun, 18 Jan 2009 23:57:56 +0100 Subject: [time-nuts] FTS 1000B OCXO from a FTS 4040 CS In-Reply-To: <822135.80157.qm@web30308.mail.mud.yahoo.com> References: <822135.80157.qm@web30308.mail.mud.yahoo.com> Message-ID: <1232319476.26603.38.camel@bg-desktop> Hi Stanley, On Sat, 2009-01-17 at 19:29 -0800, Stanley Reynolds wrote: > Was unable to adjust to 5Mhz, 4.9999752 was the best I could get with external pot. Internal pot has no effect, assume it is disconnected when external is present ? Was not hard to dissemble, the oven is not warm but has 29 volts maybe problem in the control circuit. Does anyone have any info I could use ? > > I have downloaded a 4040B operation manual but it is not that similar to the 4040. This unit uses a 1802 RCA microprocessor so is much older than the B model, think it uses a 68xx type processor. > > I have no manuals for the FTS-4040 and been unable to connect a PC to the 9 pin monitor/sync connector on the back, I need the pin out and perhaps a older monitor program as I only have monitor 2 and monitor 3 programs. > > What I can see of the ocxo outside: > > Has 2 SMA RF out connectors and a 9 pin D connector > inside: > Oven was inside a glass vacuum bottle with layers of foam insulation to close one end. > 2 MTH15N20 transistors to heat the oven > temp sensor on a small separate pc board part #56219-03909 REV A attached to oven > main board not insulated is part # 56219-06802-00 REV D There is some pinout information for 1000A and relatives in ftp://ftp.lysator.liu.se/~bg/time-nuts/FTS1200Doku.pdf I do not know if pinout applies to 1000B. -- Bj?rn From stanley_reynolds at yahoo.com Sun Jan 18 23:00:16 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Sun, 18 Jan 2009 15:00:16 -0800 (PST) Subject: [time-nuts] FTS 1000B OCXO from a FTS 4040 CS References: <822135.80157.qm@web30308.mail.mud.yahoo.com> Message-ID: <466220.21798.qm@web30306.mail.mud.yahoo.com> Looks like my 5030 package is a 5Mhz ocxo version of the FTS 4060 described on pcr68.com. Hand written note on ocxo indicates 74 degrees at 41ma guessing this is Centigrade operating temp. Stanley ? ________________________________ From: Stanley Reynolds To: time-nuts at febo.com Sent: Saturday, January 17, 2009 9:29:18 PM Subject: [time-nuts] FTS 1000B OCXO from a FTS 4040 CS Was unable to adjust to 5Mhz, 4.9999752 was the best I could get with external pot. Internal pot has no effect, assume it is disconnected when external is present ? Was not hard to dissemble, the oven is not warm but has 29 volts maybe problem in the control circuit. Does anyone have any info I could use ? I have downloaded a 4040B operation manual but it is not that similar to the 4040. This unit uses a 1802 RCA microprocessor so is much older than the B model, think it uses a 68xx type processor. I have no manuals for the FTS-4040 and been unable to connect a PC to the 9 pin monitor/sync connector on the back, I need the pin out and perhaps a older monitor program as I only have monitor 2 and monitor 3 programs. What I can see of the ocxo outside: Has 2 SMA RF out connectors and a 9 pin D connector inside: Oven was inside a glass vacuum bottle with layers of foam insulation to close one end. 2 MTH15N20 transistors to heat the oven temp sensor on a small separate pc board part #56219-03909 REV A attached to oven main board not insulated is part # 56219-06802-00 REV D _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From frledda at verizon.net Sun Jan 18 23:46:49 2009 From: frledda at verizon.net (Francesco Ledda) Date: Sun, 18 Jan 2009 17:46:49 -0600 Subject: [time-nuts] Set Up instructions: FE-5440A O-1824A/U In-Reply-To: <466220.21798.qm@web30306.mail.mud.yahoo.com> Message-ID: I am looking for a manual for the FEI FE-5440A O-1824A/U cesium source. I also need the instrument power up/set up instructions. Thank you in advance! Regards, Francesco Garland, Texsa From robert8rpi at yahoo.co.uk Mon Jan 19 07:46:39 2009 From: robert8rpi at yahoo.co.uk (Robert Atkinson) Date: Mon, 19 Jan 2009 07:46:39 +0000 (GMT) Subject: [time-nuts] Tbolt with Palisade? In-Reply-To: <497391F2.7020409@ghengineering.co.uk> Message-ID: <494596.22061.qm@web27103.mail.ukl.yahoo.com> Hi Grant, Keep the Palisade as it is. It's got a useful 1 PPS output. Also it's almost impossible to open the case without destroying it. The two halves are epoxyed together with a very good joint geometry! There is no obvious way to get to the antenna output. If you want to hack something, have a look for one of the Vaisalla GPS radiosondes. They have a nice Bi-Helix antenna, LNA and filter. But even a simple patch on a ground plane will do. Robert G8RPI. --- On Sun, 18/1/09, Grant Hodgson wrote: > From: Grant Hodgson > Subject: [time-nuts] Tbolt with Palisade? > To: time-nuts at febo.com > Date: Sunday, 18 January, 2009, 8:32 PM > Does anybody know how difficult it would be to use just the > antenna + > LNA part of a Trimble Palisade? Have Tbolt but no antenna. > I can get a > Palisade for much less than a proper GPS antenna. Coax > length would be > about 20 feet, connected to the output of the > Palisade's LNA (or output > filter if fitted). > > Only possible problem I envisage is that the Palisade LNA > will probably > have less gain than say a 58532A. However, the latter is > designed for > long cable runs; I'm guessing that this unusual > arrangement might work > with a fairly short cable run. Powering the Palisade LNA > shouldn't be > too difficult me thinks. > > regards > > Grant > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From cdelect at juno.com Mon Jan 19 16:46:37 2009 From: cdelect at juno.com (Corby Dawson) Date: Mon, 19 Jan 2009 08:46:37 -0800 Subject: [time-nuts] Datum 1000B OXCO Message-ID: <20090119.084637.3824.0.cdelect@juno.com> Hi, The data sheet for the 1000B is available on the Symmetricom website. The pinout is not given. Here is the pinout. 1- Electronics return 2- Control voltage in -10 to +10 VDC 3- Coarse tune in voltage 4- +12VDC reference out, coarse tune hot 5- Oven return 6- Oven monitor 7- +24VDC oven power 8- +24VDC electronics power 9- Case ground On some units the internal coarse control is disabled and the pot is brought out to the instruments rear panel to allow adjustment without disassembling the unit! You can tell if this is the case if wires are connected to the mainframes connector on pins 1 3 and 4 and finding the pot at the other end. These 1000B have pins 3 and 4 as shown. In this case pins 1 and 4 connect across the pot and the wiper goes to pin 3. The pot on the 1000B will not have any effect. Hope this helps. Corby Dawson ____________________________________________________________ Get the perfect student credit card by clicking now! http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw1e0xOq5mn7DGxkn3GgQYUKX2LjnKcYAJP9imVA6T6FtyuPn/ From dave.g0dja at tiscali.co.uk Mon Jan 19 18:24:39 2009 From: dave.g0dja at tiscali.co.uk (Dave Ackrill) Date: Mon, 19 Jan 2009 18:24:39 +0000 Subject: [time-nuts] Off Topic question... In-Reply-To: <20090119.084637.3824.0.cdelect@juno.com> References: <20090119.084637.3824.0.cdelect@juno.com> Message-ID: <4974C567.2070603@tiscali.co.uk> Sorry for the off topic question, but my partner, Kate, is off visiting friends in Canada and USA on Friday and is in 'panic' mode. The problem is that she has now got it into her head that she might need to get innoculated for 'something', but she doesn't know what and I don't think she needs any jabs... However, as the US immigration people are on holidays for the Presidential inauguration, she can't get a reply until it's too late to do anything about arranging to go to see the Dr. to get any jabs she 'might' need. So, can anyone tell me what jabs, if any, visitors to Canada or the USA might be asked if they have had recently? Thanks - Dave From K3WRY at aol.com Mon Jan 19 18:34:05 2009 From: K3WRY at aol.com (K3WRY at aol.com) Date: Mon, 19 Jan 2009 13:34:05 EST Subject: [time-nuts] Off Topic question... Message-ID: To the best of my knowledge and my traveling to Canada as well as the UK, she should not require any inoculations. Regards, Dr. Joseph G. Palsa P.E. Director Sales & Marketing Clary Corporation Phone 804-674-0364 Phone 800-442-5279 Fax 804 674-0714 Cell 804-350-2665 jpalsa at clary.com djpalsa at yahoo.com k3wry at aol.com In a message dated 1/19/2009 1:25:18 P.M. Eastern Standard Time, dave.g0dja at tiscali.co.uk writes: Sorry for the off topic question, but my partner, Kate, is off visiting friends in Canada and USA on Friday and is in 'panic' mode. The problem is that she has now got it into her head that she might need to get innoculated for 'something', but she doesn't know what and I don't think she needs any jabs... However, as the US immigration people are on holidays for the Presidential inauguration, she can't get a reply until it's too late to do anything about arranging to go to see the Dr. to get any jabs she 'might' need. So, can anyone tell me what jabs, if any, visitors to Canada or the USA might be asked if they have had recently? Thanks - Dave _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From wb6bnq at cox.net Mon Jan 19 18:36:53 2009 From: wb6bnq at cox.net (WB6BNQ) Date: Mon, 19 Jan 2009 10:36:53 -0800 Subject: [time-nuts] Off Topic question... References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> Message-ID: <4974C845.23E2C77F@cox.net> Dave, I would think the immigration people in the UK would probably have some idea in that regard. At least it would not hurt to ask them. Bill....WB6BNQ Dave Ackrill wrote: > Sorry for the off topic question, but my partner, Kate, is off visiting > friends in Canada and USA on Friday and is in 'panic' mode. > > The problem is that she has now got it into her head that she might need > to get innoculated for 'something', but she doesn't know what and I > don't think she needs any jabs... > > However, as the US immigration people are on holidays for the > Presidential inauguration, she can't get a reply until it's too late to > do anything about arranging to go to see the Dr. to get any jabs she > 'might' need. > > So, can anyone tell me what jabs, if any, visitors to Canada or the USA > might be asked if they have had recently? > > Thanks - Dave > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From d.seiter at comcast.net Mon Jan 19 18:43:49 2009 From: d.seiter at comcast.net (d.seiter at comcast.net) Date: Mon, 19 Jan 2009 18:43:49 +0000 Subject: [time-nuts] Off Topic question... Message-ID: <011920091843.6665.4974C9E5000BC62500001A0922007510909D0A9B070A9CD20B@comcast.net> http://wwwn.cdc.gov/travel/destinationUnitedStates.aspx -Dave -------------- Original message -------------- From: WB6BNQ > Dave, > > I would think the immigration people in the UK would probably have some idea in > that regard. At least it would not hurt to ask them. > > Bill....WB6BNQ > > > Dave Ackrill wrote: > > > Sorry for the off topic question, but my partner, Kate, is off visiting > > friends in Canada and USA on Friday and is in 'panic' mode. > > > > The problem is that she has now got it into her head that she might need > > to get innoculated for 'something', but she doesn't know what and I > > don't think she needs any jabs... > > > > However, as the US immigration people are on holidays for the > > Presidential inauguration, she can't get a reply until it's too late to > > do anything about arranging to go to see the Dr. to get any jabs she > > 'might' need. > > > > So, can anyone tell me what jabs, if any, visitors to Canada or the USA > > might be asked if they have had recently? > > > > Thanks - Dave > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From stanley_reynolds at yahoo.com Mon Jan 19 18:59:42 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Mon, 19 Jan 2009 10:59:42 -0800 (PST) Subject: [time-nuts] Off Topic question... References: <011920091843.6665.4974C9E5000BC62500001A0922007510909D0A9B070A9CD20B@comcast.net> Message-ID: <148778.28125.qm@web30301.mail.mud.yahoo.com> Do not confuse requirements for a visit vs immigration they are not the same. This site may help : http://travel.state.gov/visa/temp/types/types_1262.html And if from UK them : http://travel.state.gov/visa/temp/without/without_1990.html Stanley ________________________________ From: "d.seiter at comcast.net" To: Discussion of precise time and frequency measurement Sent: Monday, January 19, 2009 12:43:49 PM Subject: Re: [time-nuts] Off Topic question... http://wwwn.cdc.gov/travel/destinationUnitedStates.aspx -Dave -------------- Original message -------------- From: WB6BNQ > Dave, > > I would think the immigration people in the UK would probably have some idea in > that regard. At least it would not hurt to ask them. > > Bill....WB6BNQ > > > Dave Ackrill wrote: > > > Sorry for the off topic question, but my partner, Kate, is off visiting > > friends in Canada and USA on Friday and is in 'panic' mode. > > > > The problem is that she has now got it into her head that she might need > > to get innoculated for 'something', but she doesn't know what and I > > don't think she needs any jabs... > > > > However, as the US immigration people are on holidays for the > > Presidential inauguration, she can't get a reply until it's too late to > > do anything about arranging to go to see the Dr. to get any jabs she > > 'might' need. > > > > So, can anyone tell me what jabs, if any, visitors to Canada or the USA > > might be asked if they have had recently? > > > > Thanks - Dave > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From n3izn at aol.com Mon Jan 19 18:59:45 2009 From: n3izn at aol.com (n3izn at aol.com) Date: Mon, 19 Jan 2009 13:59:45 -0500 Subject: [time-nuts] Off Topic question... In-Reply-To: <4974C567.2070603@tiscali.co.uk> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> Message-ID: <8CB487F3A355EDA-D70-120F@webmail-me10.sysops.aol.com> I married a limey. Her family and friends use us as a home base as they travel. I've never heard of any special shots required. Standard UK inoculations should be fine. Only special shots I've heard of is when you go to under developed countries. Maybe where she is going has an outbreak of the flu? Biggest problem I hear from my relatives is the depression that sets in when they leave sunny mid 70 degree tempertures every day to a cold rainy Britain. :) -----Original Message----- From: Dave Ackrill To: Discussion of precise time and frequency measurement Sent: Mon, 19 Jan 2009 10:24 am Subject: [time-nuts] Off Topic question... Sorry for the off topic question, but my partner, Kate, is off visiting friends in Canada and USA on Friday and is in 'panic' mode. The problem is that she has now got it into her head that she might need to get innoculated for 'something', but she doesn't know what and I don't think she needs any jabs... However, as the US immigration people are on holidays for the Presidential inauguration, she can't get a reply until it's too late to do anything about arranging to go to see the Dr. to get any jabs she 'might' need. So, can anyone tell me what jabs, if any, visitors to Canada or the USA might be asked if they have had recently? Thanks - Dave _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From SAIDJACK at aol.com Mon Jan 19 19:07:16 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Mon, 19 Jan 2009 14:07:16 EST Subject: [time-nuts] Off Topic question... Message-ID: Coming to the US she will likely need: * Mortgage-meltdown and anti-depression medication * Obama-fever shots * Cold-weather clothing (for the east coast and Canada, we have +22C to +25C and more here in California) * Credit cards and lots of cash since the Sterling has tanked so much lately, and the Dollar is in a head-fake rally That's about it in terms of preparing for the US. In a message dated 1/19/2009 10:25:21 Pacific Standard Time, dave.g0dja at tiscali.co.uk writes: Sorry for the off topic question, but my partner, Kate, is off visiting friends in Canada and USA on Friday and is in 'panic' mode. The problem is that she has now got it into her head that she might need to get innoculated for 'something', but she doesn't know what and I don't think she needs any jabs... However, as the US immigration people are on holidays for the Presidential inauguration, she can't get a reply until it's too late to do anything about arranging to go to see the Dr. to get any jabs she 'might' need. So, can anyone tell me what jabs, if any, visitors to Canada or the USA might be asked if they have had recently? Thanks - Dave _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From dave.g0dja at tiscali.co.uk Mon Jan 19 19:09:35 2009 From: dave.g0dja at tiscali.co.uk (Dave Ackrill) Date: Mon, 19 Jan 2009 19:09:35 +0000 Subject: [time-nuts] Off Topic question... In-Reply-To: <8CB487F3A355EDA-D70-120F@webmail-me10.sysops.aol.com> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <8CB487F3A355EDA-D70-120F@webmail-me10.sysops.aol.com> Message-ID: <4974CFEF.8070702@tiscali.co.uk> Thanks for the replies all. I won't respond to all of them individually, but all the advice and links are grateully received. Thanks - Dave P.S - Yes, the one about coming back to the UK in February from Tampa Bay may well be valid, but the first leg is from mild and wet UK to freezing Ottowa. :-) From magnus at rubidium.dyndns.org Mon Jan 19 19:12:39 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Mon, 19 Jan 2009 20:12:39 +0100 Subject: [time-nuts] Off Topic question... In-Reply-To: <4974C567.2070603@tiscali.co.uk> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> Message-ID: <4974D0A7.3@rubidium.dyndns.org> Dave, Dave Ackrill skrev: > Sorry for the off topic question, but my partner, Kate, is off visiting > friends in Canada and USA on Friday and is in 'panic' mode. > > The problem is that she has now got it into her head that she might need > to get innoculated for 'something', but she doesn't know what and I > don't think she needs any jabs... > > However, as the US immigration people are on holidays for the > Presidential inauguration, she can't get a reply until it's too late to > do anything about arranging to go to see the Dr. to get any jabs she > 'might' need. > > So, can anyone tell me what jabs, if any, visitors to Canada or the USA > might be asked if they have had recently? I think she should just relax and enjoy the ride. I have never got any shots or nor have any of my family, friends and colleagues for as long as I can remember. I have honestly more interesting experiences from all my travels to France than to USA/Canada. Good warm winter clothes is as always recommended as she will probably be colder than in the UK. Besides that normal common sense works well to protect onself, as always. Cheers, Magnus From rk at timing-consultants.com Mon Jan 19 19:37:47 2009 From: rk at timing-consultants.com (Rob Kimberley) Date: Mon, 19 Jan 2009 19:37:47 -0000 Subject: [time-nuts] Off Topic question... In-Reply-To: <8CB487F3A355EDA-D70-120F@webmail-me10.sysops.aol.com> References: <20090119.084637.3824.0.cdelect@juno.com><4974C567.2070603@tiscali.co.uk> <8CB487F3A355EDA-D70-120F@webmail-me10.sysops.aol.com> Message-ID: Steady lad - nowt wrong with good ol' British Weather! We're made of tough stuff over ere thee knows..... Rob Kimberley -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of n3izn at aol.com Sent: 19 January 2009 19:00 To: time-nuts at febo.com Subject: Re: [time-nuts] Off Topic question... I married a limey. Her family and friends use us as a home base as they travel. I've never heard of any special shots required. Standard UK inoculations should be fine. Only special shots I've heard of is when you go to under developed countries. Maybe where she is going has an outbreak of the flu? Biggest problem I hear from my relatives is the depression that sets in when they leave sunny mid 70 degree tempertures every day to a cold rainy Britain. :) -----Original Message----- From: Dave Ackrill To: Discussion of precise time and frequency measurement Sent: Mon, 19 Jan 2009 10:24 am Subject: [time-nuts] Off Topic question... Sorry for the off topic question, but my partner, Kate, is off visiting friends in Canada and USA on Friday and is in 'panic' mode. The problem is that she has now got it into her head that she might need to get innoculated for 'something', but she doesn't know what and I don't think she needs any jabs... However, as the US immigration people are on holidays for the Presidential inauguration, she can't get a reply until it's too late to do anything about arranging to go to see the Dr. to get any jabs she 'might' need. So, can anyone tell me what jabs, if any, visitors to Canada or the USA might be asked if they have had recently? Thanks - Dave _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From w9ddd at tapr.org Mon Jan 19 19:54:58 2009 From: w9ddd at tapr.org (John Koster) Date: Mon, 19 Jan 2009 13:54:58 -0600 (CST) Subject: [time-nuts] time-nuts Digest, Vol 54, Issue 75 In-Reply-To: Message-ID: The airline should be able to answer this question. Unless something has changed in the past month, I'm 99.9999999% sure there's no requirement for shots of any kind. Back in the dark ages (the '70's) you had to have a card with your shot record on it to travel. By the mid eighties that was no longer the case. In the past few years I've been to the Carribean, Thailand, Hong Kong, Colombia, Mexico etc. without any shot requirements going and coming. > > Message: 2 > Date: Mon, 19 Jan 2009 18:24:39 +0000 > From: Dave Ackrill > Subject: [time-nuts] Off Topic question... > To: Discussion of precise time and frequency measurement > > Message-ID: <4974C567.2070603 at tiscali.co.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Sorry for the off topic question, but my partner, Kate, is off visiting > friends in Canada and USA on Friday and is in 'panic' mode. > > The problem is that she has now got it into her head that she might need > to get innoculated for 'something', but she doesn't know what and I > don't think she needs any jabs... > > However, as the US immigration people are on holidays for the > Presidential inauguration, she can't get a reply until it's too late to > do anything about arranging to go to see the Dr. to get any jabs she > 'might' need. > > So, can anyone tell me what jabs, if any, visitors to Canada or the USA > might be asked if they have had recently? > > Thanks - Dave > -- 73, John, W9DDD From kyrrin at bluefeathertech.com Mon Jan 19 19:53:44 2009 From: kyrrin at bluefeathertech.com (Bruce Lane) Date: Mon, 19 Jan 2009 11:53:44 -0800 Subject: [time-nuts] Off Topic question... In-Reply-To: <4974C567.2070603@tiscali.co.uk> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> Message-ID: <200901191153440708.1C9D6479@192.168.42.129> For Canada? Nothing at all. My wife and I are frequent visitors to the BC area, thanks to the fact our falconry mentor lives on Vancouver Island. In four-plus years of frequent border crossings, including one where we were delivering a Harris hawk, not once were we ever asked about innoculations or informed that anyone from the States needs such. Happy travels. *********** REPLY SEPARATOR *********** On 19-Jan-09 at 18:24 Dave Ackrill wrote: >Sorry for the off topic question, but my partner, Kate, is off visiting >friends in Canada and USA on Friday and is in 'panic' mode. > >The problem is that she has now got it into her head that she might need >to get innoculated for 'something', but she doesn't know what and I >don't think she needs any jabs... > >However, as the US immigration people are on holidays for the >Presidential inauguration, she can't get a reply until it's too late to >do anything about arranging to go to see the Dr. to get any jabs she >'might' need. > >So, can anyone tell me what jabs, if any, visitors to Canada or the USA >might be asked if they have had recently? > >Thanks - Dave > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner & Head Hardware Heavy, Blue Feather Technologies -- http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m "Quid Malmborg in Plano..." From ed_palmer at sasktel.net Mon Jan 19 22:04:57 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Mon, 19 Jan 2009 16:04:57 -0600 Subject: [time-nuts] Wenzel Oscillator Repair Message-ID: <4974F909.4070000@sasktel.net> Hello, I have a piece of equipment with a Wenzel 5 MHz oscillator from the Timekeeper line. It's functioning (that is, it's on frequency), but the output level is 20 - 30 db lower than it should be. The level seems to change every time I turn it on. By the way, this unit does NOT have an option to disable the output. I saw that was listed in one of the Timekeeper documents that I found. It seems a shame to junk it when the repair is probably easy. The challenge is how to get into the thing in the first place. Does anyone have any hints & tips on how to open or repair one of these soldered-can oscillators? I found a page that described opening an HP 10811 from a Z3801A, but more ideas are always welcome. Thanks, Ed From jmiles at pop.net Mon Jan 19 22:20:26 2009 From: jmiles at pop.net (John Miles) Date: Mon, 19 Jan 2009 14:20:26 -0800 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <4974F909.4070000@sasktel.net> Message-ID: I had a similar problem with a 5 MHz OCXO from their ULN series. There was a bad solder joint on the output connection, easy enough to fix once I got the unit open. In my case I used a Dremel tool to cut the seam. Suggest wearing a dust mask, obviously, and keep your cuts close to the perimeter of the can, in case the PC board comes right up to the edge like mine did. -- john, KE5FX > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On > Behalf Of Ed Palmer > Sent: Monday, January 19, 2009 2:05 PM > To: time-nuts at febo.com > Subject: [time-nuts] Wenzel Oscillator Repair > > > Hello, > > I have a piece of equipment with a Wenzel 5 MHz oscillator from the > Timekeeper line. > It's functioning (that is, it's on frequency), but the output level is > 20 - 30 db lower than it should be. The level seems to change every > time I turn it on. By the way, this unit does NOT have an option to > disable the output. I saw that was listed in one of the Timekeeper > documents that I found. > > It seems a shame to junk it when the repair is probably easy. The > challenge is how to get into the thing in the first place. Does anyone > have any hints & tips on how to open or repair one of these soldered-can > oscillators? I found a page > that described > opening an HP 10811 from a Z3801A, but more ideas are always welcome. > > Thanks, > Ed > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From danrae at verizon.net Mon Jan 19 22:21:16 2009 From: danrae at verizon.net (Dan Rae) Date: Mon, 19 Jan 2009 14:21:16 -0800 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <4974F909.4070000@sasktel.net> References: <4974F909.4070000@sasktel.net> Message-ID: <4974FCDC.9030600@verizon.net> Ed Palmer wrote: > Does anyone > have any hints & tips on how to open or repair one of these soldered-can > oscillators? Ed, I have opened and repaired several sealed oscillators, OCXOs and TCXOs, as well as crystal filters, with some success. In fact the Isotemp OCXO in my homebrew GPS standard is still going strong after I replaced the TL431 regulator in that ten years ago. What I do is to use a box cutter type knife on the seams, side by side, repeatedly scraping out as much of the solder as possible. After a while the seam can usually be opened up enough to break any remaining solder towards the corners. I think the fact that this avoids any prolonged heating is probably the main advantage of using this method. It takes time, but so far I have not found one that wouldn't open in the end... Do I have to say: be careful and always work away from your fingers? It works for me at any rate, and by not using heat you avoid any extra damage :^) Dan From bruce.griffiths at xtra.co.nz Mon Jan 19 22:22:12 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 20 Jan 2009 11:22:12 +1300 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <4974F909.4070000@sasktel.net> References: <4974F909.4070000@sasktel.net> Message-ID: <4974FD14.7040402@xtra.co.nz> Ed Palmer wrote: > Hello, > > I have a piece of equipment with a Wenzel 5 MHz oscillator from the > Timekeeper line. > It's functioning (that is, it's on frequency), but the output level is > 20 - 30 db lower than it should be. The level seems to change every > time I turn it on. By the way, this unit does NOT have an option to > disable the output. I saw that was listed in one of the Timekeeper > documents that I found. > > It seems a shame to junk it when the repair is probably easy. The > challenge is how to get into the thing in the first place. Does anyone > have any hints & tips on how to open or repair one of these soldered-can > oscillators? I found a page > that described > opening an HP 10811 from a Z3801A, but more ideas are always welcome. > > Thanks, > Ed > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Ed Acts like it has a broken internal wire or similar. The first thing to do is to determine how the base is sealed/connected to the can. It could be: 1) Soldered - unlikely (but not impossible) given the plastic foam insulation within the can 2) Bonded with adhesive? 3) Spot welded? Can you post close up images of the base and the other end with the adjustment seal screw removed? Bruce From sar10538 at gmail.com Mon Jan 19 23:49:35 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Tue, 20 Jan 2009 12:49:35 +1300 Subject: [time-nuts] Off Topic question... In-Reply-To: <4974C567.2070603@tiscali.co.uk> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> Message-ID: <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> How about: Rabies shots. Body armor. Loads and loads of dosh. Websters dictionary. US to UK translator (those chappies have some strange banter, you know). Phone numbers of top quality lawyers (better put them on a retainer) Smog masks. Gaffa tape to tape your fingers crossed that nothing goes wrong. Remember, if you hear a bang, hit the deck. If you hear a voice say "freeze", don't move or you'll be shot. Milk of magnesia to combat the chili dogs. Don't turn on the tv or you may need mental health care. etc... 2009/1/20 Dave Ackrill : > Sorry for the off topic question, but my partner, Kate, is off visiting > friends in Canada and USA on Friday and is in 'panic' mode. > > The problem is that she has now got it into her head that she might need > to get innoculated for 'something', but she doesn't know what and I > don't think she needs any jabs... > > However, as the US immigration people are on holidays for the > Presidential inauguration, she can't get a reply until it's too late to > do anything about arranging to go to see the Dr. to get any jabs she > 'might' need. > > So, can anyone tell me what jabs, if any, visitors to Canada or the USA > might be asked if they have had recently? > > Thanks - Dave > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From stanw1le at verizon.net Mon Jan 19 23:51:02 2009 From: stanw1le at verizon.net (Stan W1LE) Date: Mon, 19 Jan 2009 18:51:02 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <4974F909.4070000@sasktel.net> References: <4974F909.4070000@sasktel.net> Message-ID: <497511E6.3090007@verizon.net> Hello Ed, For soldered cans I use a gas torch to melt the solder and then I pull apart the soldered parts. First I mark one side with a file/scribe to assist reassembly. I usually put the can in a bench vice for a firm mechanical grip. I put the soldered joint the furthest away from the vice jaws to minimize the heat sink effect of the massive vice. I apply heat evenly to the solder joint and pull off the soldered cover. Avoid excessive heat, it will only cook the parts inside. I have used butane and propane gas torches. Have also used acetylene ( no oxy ) as with MAPP gas. May help to have a method of grasping the soldered cover. In production a induction heater is probably used to get the joint hot, then either preformed solder melts or solder is manually applied. What is important on disassembly is to be able to get a grip on the parts, to ease separation. Stan, W1LE FN41sr Cape Cod Ed Palmer wrote: > Hello, > > I have a piece of equipment with a Wenzel 5 MHz oscillator from the > Timekeeper line. > It's functioning (that is, it's on frequency), but the output level is > 20 - 30 db lower than it should be. The level seems to change every > time I turn it on. By the way, this unit does NOT have an option to > disable the output. I saw that was listed in one of the Timekeeper > documents that I found. > > It seems a shame to junk it when the repair is probably easy. The > challenge is how to get into the thing in the first place. Does anyone > have any hints & tips on how to open or repair one of these soldered-can > oscillators? I found a page > that described > opening an HP 10811 from a Z3801A, but more ideas are always welcome. > > Thanks, > Ed > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From ed_palmer at sasktel.net Tue Jan 20 00:07:22 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Mon, 19 Jan 2009 18:07:22 -0600 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <497515BA.9060901@sasktel.net> I hadn't thought of using a Dremel. Did you use an abrasive wheel or a steel cutter? The case on mine looks to be about 20 ga. tin-plated steel (~0.04" thick). The gap is so small it might have been a friction fit to start with. Ed > From: "John Miles" > Subject: Re: [time-nuts] Wenzel Oscillator Repair > To: "Discussion of precise time and frequency measurement" > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I had a similar problem with a 5 MHz OCXO from their ULN series. There was > a bad solder joint on the output connection, easy enough to fix once I got > the unit open. > > In my case I used a Dremel tool to cut the seam. Suggest wearing a dust > mask, obviously, and keep your cuts close to the perimeter of the can, in > case the PC board comes right up to the edge like mine did. > > -- john, KE5FX From ed_palmer at sasktel.net Tue Jan 20 00:19:17 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Mon, 19 Jan 2009 18:19:17 -0600 Subject: [time-nuts] time-nuts Digest, Vol 54, Issue 76 In-Reply-To: References: Message-ID: <49751885.4070808@sasktel.net> I had already started on this idea. Unfortunately, the seam is so small that the blade just isn't penetrating. It's almost like it was a friction fit to begin with. The case appears to be 20 ga (~0.04") tin-plated steel. It just has no give to it at all. When I started, I was cutting through solder, but now I think I'm just skating across steel. I'll keep at it. Maybe I'm closer to getting it open than I thought. Ed > Message: 7 > Date: Mon, 19 Jan 2009 14:21:16 -0800 > From: Dan Rae > Subject: Re: [time-nuts] Wenzel Oscillator Repair > To: Discussion of precise time and frequency measurement > > Message-ID: <4974FCDC.9030600 at verizon.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Ed Palmer wrote: > >> > Does anyone >> > have any hints & tips on how to open or repair one of these soldered-can >> > oscillators? >> > Ed, I have opened and repaired several sealed oscillators, OCXOs and > TCXOs, as well as crystal filters, with some success. In fact the > Isotemp OCXO in my homebrew GPS standard is still going strong after I > replaced the TL431 regulator in that ten years ago. > > What I do is to use a box cutter type knife on the seams, side by side, > repeatedly scraping out as much of the solder as possible. After a > while the seam can usually be opened up enough to break any remaining > solder towards the corners. I think the fact that this avoids any > prolonged heating is probably the main advantage of using this method. > It takes time, but so far I have not found one that wouldn't open in the > end... > > Do I have to say: be careful and always work away from your fingers? > > It works for me at any rate, and by not using heat you avoid any extra > damage :^) From cfharris at erols.com Tue Jan 20 01:10:50 2009 From: cfharris at erols.com (Chuck Harris) Date: Mon, 19 Jan 2009 20:10:50 -0500 Subject: [time-nuts] Off Topic question... In-Reply-To: <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> Message-ID: <4975249A.9000802@erols.com> That is so ignorant I hardly know what to say! Why don't you just admit that you hate all Americans, and know virtually nothing about the US? The biggest risk, to foreign visitors to the US, is pedestrian accidents. We kill a lot of tourists, and a lot of inattentive natives that way. UK tourists are at an extra disadvantage because their training from birth tells them to look the wrong way for US traffic. They look to the right for curb lane traffic, and get hit from the left. -Chuck Harris Steve Rooke wrote: > How about: > > Rabies shots. > Body armor. > Loads and loads of dosh. > Websters dictionary. > US to UK translator (those chappies have some strange banter, you know). > Phone numbers of top quality lawyers (better put them on a retainer) > Smog masks. > Gaffa tape to tape your fingers crossed that nothing goes wrong. > Remember, if you hear a bang, hit the deck. > If you hear a voice say "freeze", don't move or you'll be shot. > Milk of magnesia to combat the chili dogs. > Don't turn on the tv or you may need mental health care. > etc... > From ed_palmer at sasktel.net Tue Jan 20 01:12:37 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Mon, 19 Jan 2009 19:12:37 -0600 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49752505.7060000@sasktel.net> > Message: 8 > Date: Tue, 20 Jan 2009 11:22:12 +1300 > From: Bruce Griffiths > Subject: Re: [time-nuts] Wenzel Oscillator Repair > To: Discussion of precise time and frequency measurement > > Message-ID: <4974FD14.7040402 at xtra.co.nz> > Content-Type: text/plain; charset=ISO-8859-1 > > Ed Palmer wrote: > >> > Hello, >> > >> > I have a piece of equipment with a Wenzel 5 MHz oscillator from the >> > Timekeeper line. >> > It's functioning (that is, it's on frequency), but the output level is >> > 20 - 30 db lower than it should be. The level seems to change every >> > time I turn it on. By the way, this unit does NOT have an option to >> > disable the output. I saw that was listed in one of the Timekeeper >> > documents that I found. >> > >> > It seems a shame to junk it when the repair is probably easy. The >> > challenge is how to get into the thing in the first place. Does anyone >> > have any hints & tips on how to open or repair one of these soldered-can >> > oscillators? I found a page >> > that described >> > opening an HP 10811 from a Z3801A, but more ideas are always welcome. >> > >> > Thanks, >> > Ed >> > _______________________________________________ >> > time-nuts mailing list -- time-nuts at febo.com >> > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> > and follow the instructions there. >> > >> > >> > Ed > > Acts like it has a broken internal wire or similar. > > The first thing to do is to determine how the base is sealed/connected > to the can. > > It could be: > > 1) Soldered - unlikely (but not impossible) given the plastic foam > insulation within the can > I'm pretty sure it's soldered. When I started hacking at it, it cut like solder. > 2) Bonded with adhesive? > I've never seen an oscillator sealed with adhesive. I know - never say never. Let's say that all the ones I've seen have been either soldered or cold welded. Like you, I've always wondered how they did it without melting the foam. > 3) Spot welded? > No spots to be seen. I don't think this case style lends itself to a continuous spot weld or cold weld style seal. I'd expect to see flanges for that. Not to mention this case is pretty thick for that kind of seal. > Can you post close up images of the base and the other end with the > adjustment seal screw removed? > http://i701.photobucket.com/albums/ww18/edpalmer42/wenzel.jpg Why do you want to see the other end? http://i701.photobucket.com/albums/ww18/edpalmer42/Wenzelotherend.jpg > Bruce Ed From sar10538 at gmail.com Tue Jan 20 01:18:20 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Tue, 20 Jan 2009 14:18:20 +1300 Subject: [time-nuts] Off Topic question... In-Reply-To: <4975249A.9000802@erols.com> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> Message-ID: <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> Wow! Just because I forgot the :-) Maybe I should have added, leave you sense of humor at home! 2009/1/20 Chuck Harris : > That is so ignorant I hardly know what to say! > > Why don't you just admit that you hate all Americans, and know > virtually nothing about the US? > > The biggest risk, to foreign visitors to the US, is pedestrian > accidents. We kill a lot of tourists, and a lot of inattentive > natives that way. UK tourists are at an extra disadvantage because > their training from birth tells them to look the wrong way for > US traffic. They look to the right for curb lane traffic, and > get hit from the left. > > -Chuck Harris > > Steve Rooke wrote: >> How about: >> >> Rabies shots. >> Body armor. >> Loads and loads of dosh. >> Websters dictionary. >> US to UK translator (those chappies have some strange banter, you know). >> Phone numbers of top quality lawyers (better put them on a retainer) >> Smog masks. >> Gaffa tape to tape your fingers crossed that nothing goes wrong. >> Remember, if you hear a bang, hit the deck. >> If you hear a voice say "freeze", don't move or you'll be shot. >> Milk of magnesia to combat the chili dogs. >> Don't turn on the tv or you may need mental health care. >> etc... >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From bruce.griffiths at xtra.co.nz Tue Jan 20 01:32:35 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 20 Jan 2009 14:32:35 +1300 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <49752505.7060000@sasktel.net> References: <49752505.7060000@sasktel.net> Message-ID: <497529B3.4030701@xtra.co.nz> Ed Thanks for the images. Ed Palmer wrote: >> Message: 8 >> Date: Tue, 20 Jan 2009 11:22:12 +1300 >> From: Bruce Griffiths >> Subject: Re: [time-nuts] Wenzel Oscillator Repair >> To: Discussion of precise time and frequency measurement >> >> Message-ID: <4974FD14.7040402 at xtra.co.nz> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Ed Palmer wrote: >> >> >>>> Hello, >>>> >>>> I have a piece of equipment with a Wenzel 5 MHz oscillator from the >>>> Timekeeper line. >>>> It's functioning (that is, it's on frequency), but the output level is >>>> 20 - 30 db lower than it should be. The level seems to change every >>>> time I turn it on. By the way, this unit does NOT have an option to >>>> disable the output. I saw that was listed in one of the Timekeeper >>>> documents that I found. >>>> >>>> It seems a shame to junk it when the repair is probably easy. The >>>> challenge is how to get into the thing in the first place. Does anyone >>>> have any hints & tips on how to open or repair one of these soldered-can >>>> oscillators? I found a page >>>> that described >>>> opening an HP 10811 from a Z3801A, but more ideas are always welcome. >>>> >>>> Thanks, >>>> Ed >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts at febo.com >>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >>>> >>> >>> >> Ed >> >> Acts like it has a broken internal wire or similar. >> >> The first thing to do is to determine how the base is sealed/connected >> to the can. >> >> It could be: >> >> 1) Soldered - unlikely (but not impossible) given the plastic foam >> insulation within the can >> >> > I'm pretty sure it's soldered. When I started hacking at it, it cut > like solder. > > It would appear to be soldered. However given the internal foam insulation applied heat must have been very localised. The presence of the insulating foam (as stated on the datasheet) makes using a gas torch or similar technique to heat the can a little tricky if one wishes to avoid melting/damaging the foam. >> 2) Bonded with adhesive? >> >> > I've never seen an oscillator sealed with adhesive. I know - never say > never. Let's say that all the ones I've seen have been either soldered > or cold welded. Like you, I've always wondered how they did it without > melting the foam. > >> 3) Spot welded? >> >> > No spots to be seen. I don't think this case style lends itself to a > continuous spot weld or cold weld style seal. I'd expect to see flanges > for that. Not to mention this case is pretty thick for that kind of seal. > >> Can you post close up images of the base and the other end with the >> adjustment seal screw removed? >> >> > http://i701.photobucket.com/albums/ww18/edpalmer42/wenzel.jpg > > Why do you want to see the other end? > Just curious as to what the screw threaded into. > http://i701.photobucket.com/albums/ww18/edpalmer42/Wenzelotherend.jpg > >> Bruce >> > Ed > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Bruce From had at to-way.com Tue Jan 20 02:12:08 2009 From: had at to-way.com (Had) Date: Mon, 19 Jan 2009 18:12:08 -0800 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <49752505.7060000@sasktel.net> References: <49752505.7060000@sasktel.net> Message-ID: <20090120021211.E49C7D5CA9F@mail-in06.adhost.com> Ed, Here is something else to try after you've got as much solder as possible removed. Place about 1/2" of the end oscillator can in a bench vise and apply light pressure from corner to corner, cross wise. Then reverse the can 180 degrees and do it again. Obviously you don't want to crush anything, just enough pressure to slightly torque the joints. I've had good luck with this method on many different sealed items. Good Luck, Hadley K7MLR > > >> > It seems a shame to junk it when the repair is probably easy. The > >> > challenge is how to get into the thing in the first place. Does anyone > >> > have any hints & tips on how to open or repair one of these > soldered-can > >> > oscillators? I found a page > >> > that described From ed_palmer at sasktel.net Tue Jan 20 02:45:52 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Mon, 19 Jan 2009 20:45:52 -0600 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49753AE0.8070800@sasktel.net> Thanks for the reply, Stan. It sounds like you've had lots of experience with this. I think I'll hold off on using torches until I have a chance to practice on some expendable units! :-) Ed > Message: 1 > Date: Mon, 19 Jan 2009 18:51:02 -0500 > From: Stan W1LE > Subject: Re: [time-nuts] Wenzel Oscillator Repair > To: Discussion of precise time and frequency measurement > > Message-ID: <497511E6.3090007 at verizon.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello Ed, > > For soldered cans I use a gas torch to melt the solder and then I pull > apart the soldered parts. > > First I mark one side with a file/scribe to assist reassembly. > > I usually put the can in a bench vice for a firm mechanical grip. > I put the soldered joint the furthest away from the vice jaws to > minimize the heat sink effect of the massive vice. > > I apply heat evenly to the solder joint and pull off the soldered cover. > Avoid excessive heat, it will only cook the parts inside. > > I have used butane and propane gas torches. > Have also used acetylene ( no oxy ) as with MAPP gas. > > May help to have a method of grasping the soldered cover. > > In production a induction heater is probably used to get the joint hot, > then either preformed solder melts > or solder is manually applied. > > What is important on disassembly is to be able to get a grip on the > parts, to ease separation. > > Stan, W1LE FN41sr Cape Cod > From ed_palmer at sasktel.net Tue Jan 20 02:55:43 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Mon, 19 Jan 2009 20:55:43 -0600 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49753D2F.9090400@sasktel.net> I'll keep that in mind. It might be just the trick to break the last bit of the seal. But the case is so thick that I don't think 'light pressure' will do the job! :-) Ed > Message: 8 > Date: Mon, 19 Jan 2009 18:12:08 -0800 > From: Had > Subject: Re: [time-nuts] Wenzel Oscillator Repair > To: Discussion of precise time and frequency measurement > > Message-ID: <20090120021211.E49C7D5CA9F at mail-in06.adhost.com> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > Ed, > > Here is something else to try after you've got as much solder as > possible removed. > > Place about 1/2" of the end oscillator can in a bench vise and apply > light pressure from corner to corner, cross wise. Then reverse the > can 180 degrees and do it again. Obviously you don't want to crush > anything, just enough pressure to slightly torque the joints. I've > had good luck with this method on many different sealed items. > > Good Luck, > > Hadley > K7MLR > From jmiles at pop.net Tue Jan 20 05:20:54 2009 From: jmiles at pop.net (John Miles) Date: Mon, 19 Jan 2009 21:20:54 -0800 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <497515BA.9060901@sasktel.net> Message-ID: I used a fiberglass-reinforced cutoff wheel. This can open practically anything, but it puts a lot of vibration and dust into the innards of whatever you're taking apart. My guess was that this was safer than using a torch. Since I wasn't going to be able to maintain the original hermeticity, I remounted the oscillator in a Hammond box, like so: http://www.thegleam.com/ke5fx/w1.jpg I brought the trimmer (which was also damaged in this particular oscillator) and oven-status LED out to the box lid, along with the four original terminals. Makes a nice package that can be easily opened for maintenance: http://www.thegleam.com/ke5fx/w2.jpg The repackaged OCXO seems to work fine. I haven't made any hardcore measurements with it but I can tell just by watching the counter that its short-term stability is similar to my other unmolested 5 MHz ULN. -- john, KE5FX > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On > Behalf Of Ed Palmer > Sent: Monday, January 19, 2009 4:07 PM > To: time-nuts at febo.com > Subject: Re: [time-nuts] Wenzel Oscillator Repair > > > I hadn't thought of using a Dremel. Did you use an abrasive wheel or a > steel cutter? The case on mine looks to be about 20 ga. tin-plated > steel (~0.04" thick). The gap is so small it might have been a friction > fit to start with. > > Ed > > From: "John Miles" > > Subject: Re: [time-nuts] Wenzel Oscillator Repair > > To: "Discussion of precise time and frequency measurement" > > > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > I had a similar problem with a 5 MHz OCXO from their ULN > series. There was > > a bad solder joint on the output connection, easy enough to fix > once I got > > the unit open. > > > > In my case I used a Dremel tool to cut the seam. Suggest wearing a dust > > mask, obviously, and keep your cuts close to the perimeter of > the can, in > > case the PC board comes right up to the edge like mine did. > > > > -- john, KE5FX > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From cfharris at erols.com Tue Jan 20 05:51:02 2009 From: cfharris at erols.com (Chuck Harris) Date: Tue, 20 Jan 2009 00:51:02 -0500 Subject: [time-nuts] Off Topic question... In-Reply-To: <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> Message-ID: <49756646.4090408@erols.com> Steve, This sort of ignorant commentary comes up in discussion with otherwise reasonable folks so often that it really isn't funny anymore. -Chuck Harris Steve Rooke wrote: > Wow! Just because I forgot the :-) > > Maybe I should have added, leave you sense of humor at home! > > 2009/1/20 Chuck Harris : >> That is so ignorant I hardly know what to say! >> >> Why don't you just admit that you hate all Americans, and know >> virtually nothing about the US? From cfharris at erols.com Tue Jan 20 05:55:49 2009 From: cfharris at erols.com (Chuck Harris) Date: Tue, 20 Jan 2009 00:55:49 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49756765.7080902@erols.com> John Miles wrote: > I used a fiberglass-reinforced cutoff wheel. This can open practically > anything, but it puts a lot of vibration and dust into the innards of > whatever you're taking apart. My guess was that this was safer than using a > torch. I've repaired many "hermetically" sealed oscillators by unsoldering the can with a torch. It works out just fine. You first make sure that you can hold the can in something stationary...I use a vise.. and that you have a good handle on the base, take the torch and apply it for a couple of seconds, and zip it comes apart. None the worse for the wear. -Chuck Harris From sar10538 at gmail.com Tue Jan 20 07:17:16 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Tue, 20 Jan 2009 20:17:16 +1300 Subject: [time-nuts] Off Topic question... In-Reply-To: <49756646.4090408@erols.com> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> <49756646.4090408@erols.com> Message-ID: <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> Chuck, Well, I've heard the same sort of stereotypical comments about the Brits so many times I am fed up with them too. Besides which of those comments can you say does not have an air of truth about them for someone coming from England, or may other places in the World for that matter. You've turned a simple friendly poke at the US system into an all out attack on every US citizen. I read an article the other day about the British "hacker" who "broke into" the military systems over there looking for UFO data. The comments were that he should be given 70 years inside, executed, and a whole lot of stuff about how this guy was such a terrible criminal. No one talked about how the US military had connected a system with secret classified data onto the Net with no admin password. But apparently all the blame was on him. If you leave your car with the door open and the keys in the ignition wouldn't you expect to have it pinched. And whats this stuff about the land of the free, you guys have more legislation on yourselves and on other countries people than many other countries. I sat and watched all the discussion about shooting guns at New Year and the chances of people getting killed. They get killed anyway because it is so easy to get guns over there. Everybody gets the chance to be a crim. Our police don't carry guns routinely and we don't have a gun problem. Sure some idiots get hold of them, and some innocent people get hurt or killed, but it's a major event in this country when that happens, not just the way of life it is for you guys. So please don't come back at me all innocent like and hurt. Regards, Steve 2009/1/20 Chuck Harris : > Steve, > > This sort of ignorant commentary comes up in discussion with > otherwise reasonable folks so often that it really isn't funny > anymore. > > -Chuck Harris > > Steve Rooke wrote: >> Wow! Just because I forgot the :-) >> >> Maybe I should have added, leave you sense of humor at home! >> >> 2009/1/20 Chuck Harris : >>> That is so ignorant I hardly know what to say! >>> >>> Why don't you just admit that you hate all Americans, and know >>> virtually nothing about the US? > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From grant at ghengineering.co.uk Tue Jan 20 09:31:56 2009 From: grant at ghengineering.co.uk (Grant Hodgson) Date: Tue, 20 Jan 2009 09:31:56 +0000 Subject: [time-nuts] Tbolt with Palisade? In-Reply-To: <275039.49449.qm@web27106.mail.ukl.yahoo.com> References: <275039.49449.qm@web27106.mail.ukl.yahoo.com> Message-ID: <49759A0C.6010603@ghengineering.co.uk> Robert Thanks, looks like the hassle factor is greater than the fun factor on this one :( Guess I'll have to start a search for an HP58532A, VIC-100, Vaisala or similar. I don't think a cheapy ?4 patch antenna will give the same performance. regards Grant > Hi Grant, > Keep the Palisade as it is. It's got a useful 1 PPS output. Also it's almost impossible to open the case without destroying it. The two halves are epoxyed together with a very good joint geometry! There is no obvious way to get to the antenna output. If you want to hack something, have a look for one of the Vaisalla GPS radiosondes. They have a nice Bi-Helix antenna, LNA and filter. But even a simple patch on a ground plane will do. > > Robert G8RPI. > > > From ed_palmer at sasktel.net Tue Jan 20 13:58:59 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Tue, 20 Jan 2009 07:58:59 -0600 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <4975D8A3.8060804@sasktel.net> Now I understand! I was planning to reuse the case. It didn't occur to me to sacrifice the case and put the oscillator in another box. Thanks for the idea, John. Ed > Message: 3 > Date: Mon, 19 Jan 2009 21:20:54 -0800 > From: "John Miles" > Subject: Re: [time-nuts] Wenzel Oscillator Repair > To: "Discussion of precise time and frequency measurement" > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I used a fiberglass-reinforced cutoff wheel. This can open practically > anything, but it puts a lot of vibration and dust into the innards of > whatever you're taking apart. My guess was that this was safer than using a > torch. > > Since I wasn't going to be able to maintain the original hermeticity, I > remounted the oscillator in a Hammond box, like so: > > http://www.thegleam.com/ke5fx/w1.jpg > > I brought the trimmer (which was also damaged in this particular oscillator) > and oven-status LED out to the box lid, along with the four original > terminals. Makes a nice package that can be easily opened for maintenance: > > http://www.thegleam.com/ke5fx/w2.jpg > > The repackaged OCXO seems to work fine. I haven't made any hardcore > measurements with it but I can tell just by watching the counter that its > short-term stability is similar to my other unmolested 5 MHz ULN. > > -- john, KE5FX > >> -----Original Message----- >> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On >> Behalf Of Ed Palmer >> Sent: Monday, January 19, 2009 4:07 PM >> To: time-nuts at febo.com >> Subject: Re: [time-nuts] Wenzel Oscillator Repair >> >> >> I hadn't thought of using a Dremel. Did you use an abrasive wheel or a >> steel cutter? The case on mine looks to be about 20 ga. tin-plated >> steel (~0.04" thick). The gap is so small it might have been a friction >> fit to start with. >> >> Ed >> >>> From: "John Miles" >>> Subject: Re: [time-nuts] Wenzel Oscillator Repair >>> To: "Discussion of precise time and frequency measurement" >>> >>> Message-ID: >>> Content-Type: text/plain; charset="us-ascii" >>> >>> I had a similar problem with a 5 MHz OCXO from their ULN >>> >> series. There was >> >>> a bad solder joint on the output connection, easy enough to fix >>> >> once I got >> >>> the unit open. >>> >>> In my case I used a Dremel tool to cut the seam. Suggest wearing a dust >>> mask, obviously, and keep your cuts close to the perimeter of >>> >> the can, in >> >>> case the PC board comes right up to the edge like mine did. >>> >>> -- john, KE5FX >>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> From rick at cnssys.com Tue Jan 20 14:26:00 2009 From: rick at cnssys.com (Richard M. Hambly) Date: Tue, 20 Jan 2009 09:26:00 -0500 Subject: [time-nuts] Agilent 53132A Needs Help Message-ID: <94B59D31CF9A49978777EB497CE354DE@RICK> All, One of my 53132As, an Agilent unit, s/n KR01202209 fail the power-on self test with a FAIL:ROM error message. During the test the front panel display looks quite odd compared with the other counters. If I ignore the error and press Recall (my settings are in Recall 1) I can proceed to what seems like normal operation and the time intervals I have been collecting for years on this counter seem OK. I opened it up and there is not much there. While I suppose I could perform some simple tests like checking power supply outputs, I just wondered if any of you have had a similar experience or if you knew of a reasonable place to have it repaired. I can only imagine what Agilent would charge for this. Rick W2GPS Richard M. Hambly, CNS Systems, Inc. 363 Hawick Court, Severna Park, MD 21146 410-987-7835 phone, 410-987-7836 Fax, 410-299-2147 cell rick at cnssys.com, www.cnssys.com, www.gpstime.com From n3izn at aol.com Tue Jan 20 15:37:14 2009 From: n3izn at aol.com (n3izn at aol.com) Date: Tue, 20 Jan 2009 10:37:14 -0500 Subject: [time-nuts] Off Topic question... In-Reply-To: <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> References: <20090119.084637.3824.0.cdelect@juno.com><4974C567.2070603@tiscali.co.uk><1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com><4975249A.9000802@erols.com><1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com><49756646.4090408@erols.com> <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> Message-ID: <8CB492C1A47292D-1178-923@MBLK-M35.sysops.aol.com> In all of this Anglo American battering there is one thing we can agree on. Jason Bourne can kick James Bond's butt (or arse). From johnday at wordsnimages.com Tue Jan 20 16:19:20 2009 From: johnday at wordsnimages.com (John Day) Date: Tue, 20 Jan 2009 11:19:20 -0500 Subject: [time-nuts] Off Topic question... In-Reply-To: <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.co m> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> <49756646.4090408@erols.com> <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> Message-ID: At 02:17 AM 1/20/2009, you wrote: >Chuck, > >Well, I've heard the same sort of stereotypical comments about the >Brits so many times I am fed up with them too. Besides which of those >comments can you say does not have an air of truth about them for >someone coming from England, or may other places in the World for that >matter. > >You've turned a simple friendly poke at the US system into an all out >attack on every US citizen. I read an article the other day about the >British "hacker" who "broke into" the military systems over there >looking for UFO data. The comments were that he should be given 70 >years inside, executed, and a whole lot of stuff about how this guy >was such a terrible criminal. No one talked about how the US military >had connected a system with secret classified data onto the Net with >no admin password. But apparently all the blame was on him. If you >leave your car with the door open and the keys in the ignition >wouldn't you expect to have it pinched. > >And whats this stuff about the land of the free, you guys have more >legislation on yourselves and on other countries people than many >other countries. I sat and watched all the discussion about shooting >guns at New Year and the chances of people getting killed. They get >killed anyway because it is so easy to get guns over there. Everybody >gets the chance to be a crim. Our police don't carry guns routinely >and we don't have a gun problem. Sure some idiots get hold of them, >and some innocent people get hurt or killed, but it's a major event in >this country when that happens, not just the way of life it is for you >guys. > >So please don't come back at me all innocent like and hurt. > >Regards, >Steve Steve, What you need to remember is that some Americans have a superiority complex - there is nothing of worth or value from anywhere else. We shouldn't take this to heart, this is the way they are educated. From a very early age Americans are taught that the US is the greatest country in the world. The American military is invincible, the American education system excels and everybody in the world wants to live in the US so we need to keep them out. Parts of this are true, the US is a great country. But no more so than Britain, Canada, Australia, Germany or just about any other country. Americans are proud of their country, but often unjustifiably so because their media and education system is severely xenophobic. The American military isn't bad, but invincible? Hardly. The US does have some good universities, but it doesn't mean any means have a caveat on good education. Illiteracy rates in the US are high for a first world nation. But to understand the attitude you need to know a lot about the US. Since 1973 I have lived in the US on several occasions. I have worked for US corporations and the US government. I have also had to live in a country where the rest of the world barely exists for the media. Where major government figures at the Federal and State level are almost totally ignorant of even their closest neighbour. So these days I live in a community of malcontents! Many of my friends here in Canada are Americans who have chosen not to live in the US for a variety of reasons. As an immigrant to this country I have spoken to many people to try and figure out how Canadians define themselves. The one core theme I detect is "we are not Americans". Having lived in the US I am happy not to live there now. But don't be discouraged, the sort of reaction you have seen here is fairly typical. On the whole Americans are very sensitive about any perceived criticism of their country and just don't seem to have a handle on anyone else's sense of humour. John (An Australian who has lived in too many places to recall). From jra at febo.com Tue Jan 20 16:31:50 2009 From: jra at febo.com (John Ackermann N8UR) Date: Tue, 20 Jan 2009 11:31:50 -0500 Subject: [time-nuts] Off Topic question... In-Reply-To: References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> <49756646.4090408@erols.com> <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> Message-ID: <4975FC76.40404@febo.com> Folks, this started out as an off-topic question about getting inoculations, and has turned into something even more off-topic and less informative. Time-nuts now has over 750 subscribers who joined the list because they are interested in a high signal-to-noise ratio discussion of precise time and frequency measurement. Let's respect their time and bandwidth by limiting discussions to things within the list's charter. Specifically, let's close off this discussion of who's stereotyping whom before it degenerates further. Thanks, John YrSysAdmin ---- John Day wrote: > At 02:17 AM 1/20/2009, you wrote: >> Chuck, >> >> Well, I've heard the same sort of stereotypical comments about the >> Brits so many times I am fed up with them too. Besides which of those >> comments can you say does not have an air of truth about them for >> someone coming from England, or may other places in the World for that >> matter. >> >> You've turned a simple friendly poke at the US system into an all out >> attack on every US citizen. I read an article the other day about the >> British "hacker" who "broke into" the military systems over there >> looking for UFO data. The comments were that he should be given 70 >> years inside, executed, and a whole lot of stuff about how this guy >> was such a terrible criminal. No one talked about how the US military >> had connected a system with secret classified data onto the Net with >> no admin password. But apparently all the blame was on him. If you >> leave your car with the door open and the keys in the ignition >> wouldn't you expect to have it pinched. >> >> And whats this stuff about the land of the free, you guys have more >> legislation on yourselves and on other countries people than many >> other countries. I sat and watched all the discussion about shooting >> guns at New Year and the chances of people getting killed. They get >> killed anyway because it is so easy to get guns over there. Everybody >> gets the chance to be a crim. Our police don't carry guns routinely >> and we don't have a gun problem. Sure some idiots get hold of them, >> and some innocent people get hurt or killed, but it's a major event in >> this country when that happens, not just the way of life it is for you >> guys. >> >> So please don't come back at me all innocent like and hurt. >> >> Regards, >> Steve > > Steve, > > What you need to remember is that some Americans have a superiority > complex - there is nothing of worth or value from anywhere else. We > shouldn't take this to heart, this is the way they are educated. From > a very early age Americans are taught that the US is the greatest > country in the world. The American military is invincible, the > American education system excels and everybody in the world wants to > live in the US so we need to keep them out. > > Parts of this are true, the US is a great country. But no more so > than Britain, Canada, Australia, Germany or just about any other > country. Americans are proud of their country, but often > unjustifiably so because their media and education system is severely > xenophobic. > > The American military isn't bad, but invincible? Hardly. > > The US does have some good universities, but it doesn't mean any > means have a caveat on good education. Illiteracy rates in the US are > high for a first world nation. > > But to understand the attitude you need to know a lot about the US. > Since 1973 I have lived in the US on several occasions. I have worked > for US corporations and the US government. I have also had to live in > a country where the rest of the world barely exists for the media. > Where major government figures at the Federal and State level are > almost totally ignorant of even their closest neighbour. > > So these days I live in a community of malcontents! Many of my > friends here in Canada are Americans who have chosen not to live in > the US for a variety of reasons. As an immigrant to this country I > have spoken to many people to try and figure out how Canadians define > themselves. The one core theme I detect is "we are not Americans". > Having lived in the US I am happy not to live there now. But don't be > discouraged, the sort of reaction you have seen here is fairly > typical. On the whole Americans are very sensitive about any > perceived criticism of their country and just don't seem to have a > handle on anyone else's sense of humour. > > John > (An Australian who has lived in too many places to recall). > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From had at to-way.com Tue Jan 20 17:03:33 2009 From: had at to-way.com (Had) Date: Tue, 20 Jan 2009 09:03:33 -0800 Subject: [time-nuts] Off Topic question... In-Reply-To: <4975FC76.40404@febo.com> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> <49756646.4090408@erols.com> <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> <4975FC76.40404@febo.com> Message-ID: <20090120170336.E78528ADF10@mail-in07.adhost.com> Thank You! John Had K7MLR At 08:31 AM 1/20/2009, you wrote: >Folks, this started out as an off-topic question about getting >inoculations, and has turned into something even more off-topic and less >informative. > >Time-nuts now has over 750 subscribers who joined the list because they >are interested in a high signal-to-noise ratio discussion of precise >time and frequency measurement. Let's respect their time and bandwidth >by limiting discussions to things within the list's charter. > >Specifically, let's close off this discussion of who's stereotyping whom >before it degenerates further. From jmiles at pop.net Tue Jan 20 17:20:53 2009 From: jmiles at pop.net (John Miles) Date: Tue, 20 Jan 2009 09:20:53 -0800 Subject: [time-nuts] Agilent 53132A Needs Help In-Reply-To: <94B59D31CF9A49978777EB497CE354DE@RICK> Message-ID: I'd be inclined to take the error message at face value; you have some corruption in EPROM or flash memory that isn't in an area that gets used during the measurements you're making. Contacting an Agilent rep would make sense, as the 53132A is new enough that there might be an easy way to upgrade/reflash the firmware. -- john, KE5FX > > One of my 53132As, an Agilent unit, s/n KR01202209 fail the power-on self > test with a FAIL:ROM error message. During the test the front > panel display > looks quite odd compared with the other counters. If I ignore the > error and > press Recall (my settings are in Recall 1) I can proceed to what > seems like > normal operation and the time intervals I have been collecting > for years on > this counter seem OK. > > > > I opened it up and there is not much there. While I suppose I > could perform > some simple tests like checking power supply outputs, I just > wondered if any > of you have had a similar experience or if you knew of a > reasonable place to > have it repaired. I can only imagine what Agilent would charge for this. > > From jmiles at pop.net Tue Jan 20 17:28:31 2009 From: jmiles at pop.net (John Miles) Date: Tue, 20 Jan 2009 09:28:31 -0800 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <4975D8A3.8060804@sasktel.net> Message-ID: You probably have a lot more room to play with, given the larger housing on your OCXO. The ULN series is rather densely packaged, and that was one reason why I wasn't crazy about going after it with a propane torch. In your case I'd be tempted to try the torch method before actually damaging the housing with a Dremel tool. While fixing a couple of Ovenaire OCXOs that use a similar form factor, I've noticed that their PC board edges don't come anywhere near the endcap. The Ovenaire parts were sealed with epoxy, so a heat gun was all that was needed to open them, but I'm sure I could've opened them with a torch without hurting anything, if they'd been soldered shut. -- john, KE5FX > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On > Behalf Of Ed Palmer > Sent: Tuesday, January 20, 2009 5:59 AM > To: time-nuts at febo.com > Subject: Re: [time-nuts] Wenzel Oscillator Repair > > > Now I understand! I was planning to reuse the case. It didn't occur to > me to sacrifice the case and put the oscillator in another box. > > Thanks for the idea, John. > > Ed > > > Message: 3 > > Date: Mon, 19 Jan 2009 21:20:54 -0800 > > From: "John Miles" > > Subject: Re: [time-nuts] Wenzel Oscillator Repair > > To: "Discussion of precise time and frequency measurement" > > > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > I used a fiberglass-reinforced cutoff wheel. This can open practically > > anything, but it puts a lot of vibration and dust into the innards of > > whatever you're taking apart. My guess was that this was safer > than using a > > torch. > > > > Since I wasn't going to be able to maintain the original hermeticity, I > > remounted the oscillator in a Hammond box, like so: > > > > http://www.thegleam.com/ke5fx/w1.jpg > > > > I brought the trimmer (which was also damaged in this > particular oscillator) > > and oven-status LED out to the box lid, along with the four original > > terminals. Makes a nice package that can be easily opened for > maintenance: > > > > http://www.thegleam.com/ke5fx/w2.jpg > > > > The repackaged OCXO seems to work fine. I haven't made any hardcore > > measurements with it but I can tell just by watching the > counter that its > > short-term stability is similar to my other unmolested 5 MHz ULN. > > > > -- john, KE5FX > > > >> -----Original Message----- > >> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On > >> Behalf Of Ed Palmer > >> Sent: Monday, January 19, 2009 4:07 PM > >> To: time-nuts at febo.com > >> Subject: Re: [time-nuts] Wenzel Oscillator Repair > >> > >> > >> I hadn't thought of using a Dremel. Did you use an abrasive wheel or a > >> steel cutter? The case on mine looks to be about 20 ga. tin-plated > >> steel (~0.04" thick). The gap is so small it might have been > a friction > >> fit to start with. > >> > >> Ed > >> > >>> From: "John Miles" > >>> Subject: Re: [time-nuts] Wenzel Oscillator Repair > >>> To: "Discussion of precise time and frequency measurement" > >>> > >>> Message-ID: > >>> Content-Type: text/plain; charset="us-ascii" > >>> > >>> I had a similar problem with a 5 MHz OCXO from their ULN > >>> > >> series. There was > >> > >>> a bad solder joint on the output connection, easy enough to fix > >>> > >> once I got > >> > >>> the unit open. > >>> > >>> In my case I used a Dremel tool to cut the seam. Suggest > wearing a dust > >>> mask, obviously, and keep your cuts close to the perimeter of > >>> > >> the can, in > >> > >>> case the PC board comes right up to the edge like mine did. > >>> > >>> -- john, KE5FX > >>> > >> _______________________________________________ > >> time-nuts mailing list -- time-nuts at febo.com > >> To unsubscribe, go to > >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >> and follow the instructions there. > >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From yuri at ostry.ru Tue Jan 20 17:42:29 2009 From: yuri at ostry.ru (Yuri Ostry) Date: Tue, 20 Jan 2009 20:42:29 +0300 Subject: [time-nuts] Agilent 53132A Needs Help In-Reply-To: <94B59D31CF9A49978777EB497CE354DE@RICK> References: <94B59D31CF9A49978777EB497CE354DE@RICK> Message-ID: <1197596620.20090120204229@ostry.ru> Hello, Tuesday, January 20, 2009, 17:26:00, Richard M. Hambly wrote: R> One of my 53132As, an Agilent unit, s/n KR01202209 fail the power-on self R> test with a FAIL:ROM error message. Cannot say anything about your particular counter, but very often such error is due to 'leaked' EPROM chip, that change value of some memory cells over time. Last years I seen such problems 5 or 6 times with 15+ years old equipment, and in most times original EPROM image still can be read out if you have a EPROM programmer that allow to set arbitrary Vcc for a chip in programming socket. Some background: Erased EPROM cell (actually small piece of metallization between two layers of silicon oxide, acting both as a capacitor and as a gate of MOSFET transistor on underlying layers) reads as logical "one". When it is charged during programming, it start read as "zero". If some cell have small defects in insulating oxide, or just got a hit of some high energy particle, part of charge can be lost and "programmed" bit that should read as "zero" starting to read as "one" under normal conditions (nominal Vcc). There is a chance (very good chance, according to my own experience) that you can find such "partially discharged" bits by lowering (gradually) Vcc and saving read images to disk for further comparsion. Usually I start from 5.0V, make 10-20 reads, saving each one to separate file in a 5V0 directory, then switch to 4.9V, and do the same, saving to 4V9 directory, and so on... Usually it is enough to go below to 4V0... When you analyze saved images later, first compare all files in each directory to each other, you can find some bits that reads unstable at given voltage. Then compare images between nearby voltages and if there is any changes, it may be your "lost" zero bits. If you go too low, some EPROMS that was written before and then erased to program current image may show you some of former programmed bits as zeros - you need to be careful. There was some "erased" EPROM chips that read as blank under 5V but read out their previous content (and CRC perfectly match) when read out at Vcc little below 3.8V (not all brands of EPROM operational at that voltage, though)... If there is a CRC on a EPROM label, it may be very useful in determining that your recovered image is really good. Some devices do CRC check on startup and you can feel yourself safe enough if checksum error is gone. Always keep your original EPROM chip intact and do not expose it to a UV or sunlight (if there is no label that cover their window) until you are completely sure that you have correct image on hand. Use spare EPROM of same type for experiments. BTW: Looks like it is a good idea to have images of EPROMS and calibration EEPROMs (if any) for all equipment in a safe place. -- Best regards, Yuri, UA3ATQ/KI7XJ mailto:yuri at ostry.ru From imp at bsdimp.com Tue Jan 20 18:20:32 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue, 20 Jan 2009 11:20:32 -0700 (MST) Subject: [time-nuts] Off Topic question... In-Reply-To: <8CB492C1A47292D-1178-923@MBLK-M35.sysops.aol.com> References: <49756646.4090408@erols.com> <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> <8CB492C1A47292D-1178-923@MBLK-M35.sysops.aol.com> Message-ID: <20090120.112032.-1795557261.imp@bsdimp.com> In message: <8CB492C1A47292D-1178-923 at MBLK-M35.sysops.aol.com> n3izn at aol.com writes: : In all of this Anglo American battering there is one thing we can agree on. : : Jason Bourne can kick James Bond's butt (or arse). Jason Bourne can kick James Bond's butt but James Bond can kick Jason Bourne's arse. might be a better way to say it :) Warner From dave.g0dja at tiscali.co.uk Tue Jan 20 18:44:27 2009 From: dave.g0dja at tiscali.co.uk (Dave Ackrill) Date: Tue, 20 Jan 2009 18:44:27 +0000 Subject: [time-nuts] Off Topic question... In-Reply-To: <4975FC76.40404@febo.com> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> <49756646.4090408@erols.com> <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> <4975FC76.40404@febo.com> Message-ID: <49761B8B.1030207@tiscali.co.uk> John Ackermann N8UR wrote: > Folks, this started out as an off-topic question about getting > inoculations, and has turned into something even more off-topic and less > informative. > My appologies for starting this. For the record, I asked similar questions on a couple of other forums where I knew people from Canada and the USA would be lurking or posting, as I needed a fairly rapid informed response to allay my partners fears, and this one has taken off like no other! My sole intention was to reassure my partner that she could leave for Canada and the USA on Friday without needing to visit the doctor for 101 innoculations, which many of the initial replies did, despite what one of her less informed internet friends had suggested she would need... I did take on-board the 'Google is your friend' comments, as that's normally my first port of call, but Kate is reasonably internet savvy and knows the problems of making unrestricted Google searches on the standard of the information received. However the pointers to the Canadian and USA official websites were very useful sources of reliable information, and were gratefully received. Thank you. So, in future, I will know better where to ask, and where to keep stum. Dave (G0DJA) From hbonhorst at freenet.de Tue Jan 20 19:33:13 2009 From: hbonhorst at freenet.de (v. Bonhorst) Date: Tue, 20 Jan 2009 20:33:13 +0100 Subject: [time-nuts] New question slightly off topic. In-Reply-To: <49761B8B.1030207@tiscali.co.uk> References: <20090119.084637.3824.0.cdelect@juno.com> <4974C567.2070603@tiscali.co.uk> <1231b6a80901191549w1a5458bdxa0f90fc0356d3614@mail.gmail.com> <4975249A.9000802@erols.com> <1231b6a80901191718p538e0f31w730e6c777cf25d73@mail.gmail.com> <49756646.4090408@erols.com> <1231b6a80901192317x7c1f7a4dg13bbc56bbd4dec58@mail.gmail.com> <4975FC76.40404@febo.com> <49761B8B.1030207@tiscali.co.uk> Message-ID: Knowing the knowledge of many members of the list I hope to find an answer to the following question. Can somebody help to identify and give hints for documentation for the following instrument. Weinschel 1103-5GPA rf power transfer standard. Basically this is a thermally insulated thermistor mount connected to a coaxial directional coupler with some means of tuning. Thank you for any help. Hubert DB7ME From bruce.griffiths at xtra.co.nz Tue Jan 20 19:40:21 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 21 Jan 2009 08:40:21 +1300 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <497628A5.8000007@xtra.co.nz> The relatively low thermal conductivity of the steel can will help considerably in avoiding thermal damage if the heat is applied to the joint. If the can were copper it would be much more difficult to avoid thermal damage. Bruce John Miles wrote: > You probably have a lot more room to play with, given the larger housing on > your OCXO. The ULN series is rather densely packaged, and that was one > reason why I wasn't crazy about going after it with a propane torch. In > your case I'd be tempted to try the torch method before actually damaging > the housing with a Dremel tool. > > While fixing a couple of Ovenaire OCXOs that use a similar form factor, I've > noticed that their PC board edges don't come anywhere near the endcap. The > Ovenaire parts were sealed with epoxy, so a heat gun was all that was needed > to open them, but I'm sure I could've opened them with a torch without > hurting anything, if they'd been soldered shut. > > -- john, KE5FX > > >> -----Original Message----- >> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On >> Behalf Of Ed Palmer >> Sent: Tuesday, January 20, 2009 5:59 AM >> To: time-nuts at febo.com >> Subject: Re: [time-nuts] Wenzel Oscillator Repair >> >> >> Now I understand! I was planning to reuse the case. It didn't occur to >> me to sacrifice the case and put the oscillator in another box. >> >> Thanks for the idea, John. >> >> Ed >> >> >>> Message: 3 >>> Date: Mon, 19 Jan 2009 21:20:54 -0800 >>> From: "John Miles" >>> Subject: Re: [time-nuts] Wenzel Oscillator Repair >>> To: "Discussion of precise time and frequency measurement" >>> >>> Message-ID: >>> Content-Type: text/plain; charset="us-ascii" >>> >>> I used a fiberglass-reinforced cutoff wheel. This can open practically >>> anything, but it puts a lot of vibration and dust into the innards of >>> whatever you're taking apart. My guess was that this was safer >>> >> than using a >> >>> torch. >>> >>> Since I wasn't going to be able to maintain the original hermeticity, I >>> remounted the oscillator in a Hammond box, like so: >>> >>> http://www.thegleam.com/ke5fx/w1.jpg >>> >>> I brought the trimmer (which was also damaged in this >>> >> particular oscillator) >> >>> and oven-status LED out to the box lid, along with the four original >>> terminals. Makes a nice package that can be easily opened for >>> >> maintenance: >> >>> http://www.thegleam.com/ke5fx/w2.jpg >>> >>> The repackaged OCXO seems to work fine. I haven't made any hardcore >>> measurements with it but I can tell just by watching the >>> >> counter that its >> >>> short-term stability is similar to my other unmolested 5 MHz ULN. >>> >>> -- john, KE5FX >>> >>> >>>> -----Original Message----- >>>> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On >>>> Behalf Of Ed Palmer >>>> Sent: Monday, January 19, 2009 4:07 PM >>>> To: time-nuts at febo.com >>>> Subject: Re: [time-nuts] Wenzel Oscillator Repair >>>> >>>> >>>> I hadn't thought of using a Dremel. Did you use an abrasive wheel or a >>>> steel cutter? The case on mine looks to be about 20 ga. tin-plated >>>> steel (~0.04" thick). The gap is so small it might have been >>>> >> a friction >> >>>> fit to start with. >>>> >>>> Ed >>>> >>>> >>>>> From: "John Miles" >>>>> Subject: Re: [time-nuts] Wenzel Oscillator Repair >>>>> To: "Discussion of precise time and frequency measurement" >>>>> >>>>> Message-ID: >>>>> Content-Type: text/plain; charset="us-ascii" >>>>> >>>>> I had a similar problem with a 5 MHz OCXO from their ULN >>>>> >>>>> >>>> series. There was >>>> >>>> >>>>> a bad solder joint on the output connection, easy enough to fix >>>>> >>>>> >>>> once I got >>>> >>>> >>>>> the unit open. >>>>> >>>>> In my case I used a Dremel tool to cut the seam. Suggest >>>>> >> wearing a dust >> >>>>> mask, obviously, and keep your cuts close to the perimeter of >>>>> >>>>> >>>> the can, in >>>> >>>> >>>>> case the PC board comes right up to the edge like mine did. >>>>> >>>>> -- john, KE5FX >>>>> >>>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts at febo.com >>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to >> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From cdelect at juno.com Tue Jan 20 20:35:35 2009 From: cdelect at juno.com (Corby Dawson) Date: Tue, 20 Jan 2009 12:35:35 -0800 Subject: [time-nuts] More quartz short term stabilities Message-ID: <20090120.123535.3172.1.cdelect@juno.com> Short term stabilities of a bunch of quartz oscillators. I had posted this some time ago but this is an updated version. In answer to Ulrich's earlier question on the FTS 1200 #1 I retested it in the same setup as the FTS1200 #2 and it still showed the results below. The Piezos are the 10811 clones. The Motorola units are The large can units you sometimes see on eBay. The DOXO is the clone of the Oscilloquartz dual oven 8663. Seconds 1.0 10 100 1K ------------------------------------------------ 10811-60109 6.11-12 2.52-12 8.78-12 10811-60109 1.65-12 1.91-12 9.79-12 10811-60109 1.65-12 1.99-12 1.11-12 10811-60109 5.47-12 1.16-12 2.38-12 105 STYLE #T 7.60-13 2.01-12 3.94-12 10811-60111 1.27-12 2.65-12 1.93-12 105 STYLE #2 1.14-12 1.57-12 2.26-12 105 STYLE #3 1.31-12 1.58-12 2.68-12 10811-60111 3.04-12 5.54-12 1.47-12 105 STYLE #4 1.38-12 3.49-12 4.84-12 10811-60109 2.05-12 2.89-12 3.24-12 10811-60111 1.36-12 1.17-12 1.75-12 105 STYLE #5 1.14-12 2.09-12 2.51-12 FTS 1200 #1 7.14-13 1.48-12 1.92-12 10543A 2.86-11 1.05-11 1.63-11 FTS 1200 #2 2.99-13 4.30-13 7.69-13 8.65-13 10544A 4.08-12 2.95-12 7.79-12 10811-60111 1.24-12 2.10-12 2.09-12 10811-60111 1.48-12 1.59-12 1.54-12 10544A 1.89-12 2.99-12 5.01-12 105 style #6 2.88-12 2.88-12 7.37-12 105 style #7 9.69-13 2.30-12 3.49-12 10544-60511 8.20-13 2.11-12 2.51-12 Piezo clone 2.57-12 2.23-12 2.17-12 5060A osconly 4.04-12 5.94-12 8.42-12 1.30-11 10811-60111 2.59-12 3.87-12 5.77-12 10811-60109 5.08-13 1.42-12 6.10-13 Motorola 1 1.70-12 2.42-12 1.99-12 Motorola 2 2.01-12 1.71-12 1.75-12 1250B 1.22-11 3.04-12 6.54-12 FTS1000A-100 8.26-13 1.22-12 1.03-12 Piezo X 1.93-12 2.53-12 3.44-12 Piezo 1 1.71-12 3.50-12 3.00-12 Piezo 2 1.34-12 1.94-12 3.08-12 Piezo 3 1.41-11 9.50-12 2.00-12 FTS 9110 1.44-12 4.96-13 3.40-13 Wenzel 4 port 7.34-12 1.11-11 2.61-11 DOXO8663clone 2.68-12 3.52-12 3.16-12 ____________________________________________________________ Purify your water with professional water treatment. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2uXr2KCGbK1miow624gNyYsxN11dFkW3otSdIjJEjbgpH1X/ From stanley_reynolds at yahoo.com Tue Jan 20 20:49:43 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Tue, 20 Jan 2009 12:49:43 -0800 (PST) Subject: [time-nuts] Datum 1000B OXCO Message-ID: <938125.21484.qm@web30304.mail.mud.yahoo.com> Not sure why my email to this list is lost or delayed but some does?get thru. Working on a parts list and circuit diagram for the FTS 1000 which can be found here: www.n4iqt.com/fts1000b Stanley ? ________________________________ From: Stanley Reynolds To: time-nuts at febo.com Sent: Tuesday, January 20, 2009 11:20:28 AM Subject: RE: [time-nuts] Datum 1000B OXCO ----- Forwarded Message ---- From: Stanley Reynolds To: Discussion of precise time and frequency measurement Sent: Monday, January 19, 2009 5:16:51 PM Subject: Re: [time-nuts] Datum 1000B OXCO My control voltage is adjustable from 0 to 12 positive volts maybe in this application no negative supply ? Yes it has the external pot but in this package FTS-4040 the 5030 assembly's long side is from side to side not front to back like the FTS-4060. So the external adjustment is on the left side. I have two 5030's on the way, hope they are the 5 Mhz version 1000B not the 10 Mhz OCXO. I could use a substitute 5 Mhz OCXO and the main board from my broken 1000B to get the two outputs I need but that would be a less desirable option. Started a schematic of the oven circuit see attached bit map file, easy?traces done the hidden parts yet to do. Stanley ________________________________ From: Corby Dawson To: time-nuts at febo.com Sent: Monday, January 19, 2009 10:46:37 AM Subject: Re: [time-nuts] Datum 1000B OXCO Hi, The data sheet for the 1000B is available on the Symmetricom website. The pinout is not given. Here is the pinout. 1- Electronics return 2- Control voltage in -10 to +10 VDC 3- Coarse tune in voltage 4- +12VDC reference out, coarse tune hot 5- Oven return 6- Oven monitor 7- +24VDC oven power 8- +24VDC electronics power 9- Case ground On some units the internal coarse control is disabled and the pot is brought out to the instruments rear panel to allow adjustment without disassembling the unit! You can tell if this is the case? if wires are connected to the mainframes connector on pins 1 3 and 4 and finding the pot at the other end. These 1000B have pins 3 and 4 as shown. In this case pins 1 and 4 connect across the pot and the wiper goes to pin 3. The pot on the 1000B will not have any effect. Hope this helps. Corby Dawson From magnus at rubidium.dyndns.org Tue Jan 20 21:32:15 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Tue, 20 Jan 2009 22:32:15 +0100 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <497628A5.8000007@xtra.co.nz> References: <497628A5.8000007@xtra.co.nz> Message-ID: <497642DF.6050302@rubidium.dyndns.org> Bruce Griffiths skrev: > The relatively low thermal conductivity of the steel can will help > considerably in avoiding thermal damage if the heat is applied to the joint. > If the can were copper it would be much more difficult to avoid thermal > damage. When I needed to have a McCoy oscillator can opened my trusty good old friend Sten did the usual trick of pre-heating the can and then when applying heat to the solder the termal difference is lower and hence the heat-flow away from the joint. Didn't take much time and I think the oscillator is 100% intact. Pre-heating and hot air is his main tools to tricky soldering jobs. He has low fatality rate on problems like that. This is why we let him do that kind of stuff at work. Cheers, Magnus From XDE-L2G3 at myamail.com Tue Jan 20 21:36:38 2009 From: XDE-L2G3 at myamail.com (Mike Monett) Date: Tue, 20 Jan 2009 16:36:38 -0500 Subject: [time-nuts] More quartz short term stabilities References: Message-ID: Date: Tue, 20 Jan 2009 12:35:35 -0800 From: Corby Dawson Subject: Re: [time-nuts] More quartz short term stabilities To: time-nuts at febo.com Message-ID: <20090120.123535.3172.1.cdelect at juno.com> > Short term stabilities of a bunch of quartz oscillators. I had > posted this some time ago but this is an updated version. In > answer to Ulrich's earlier question on the FTS 1200 #1 I retested > it in the same setup as the FTS1200 #2 and it still showed the > results below. > The Piezos are the 10811 clones. The Motorola units are The large > can units you sometimes see on eBay. The DOXO is the clone of the > Oscilloquartz dual oven 8663. Corby, Thank you very much for posting this information. I sorted the list and tabbed the columns to line up in plain ascii. Is the entry marked with the question marks a typo? And are there only two entries with results for 1,000 seconds, or did I goof somewhere? Model Seconds 1.0 10 100 1K 105 STYLE #2 1.14-12 1.57-12 2.26-12 105 STYLE #3 1.31-12 1.58-12 2.68-12 105 STYLE #4 1.38-12 3.49-12 4.84-12 105 STYLE #5 1.14-12 2.09-12 2.51-12 105 style #6 2.88-12 2.88-12 7.37-12 105 style #7 9.69-13 2.30-12 3.49-12 105 STYLE #T 7.60-13 2.01-12 3.94-12 10543A 2.86-11 1.05-11 1.63-11 10544-60511 8.20-13 2.11-12 2.51-12 10544A 1.89-12 2.99-12 5.01-12 10544A 4.08-12 2.95-12 7.79-12 10811-60109 1.65-12 1.91-12 9.79-12 10811-60109 1.65-12 1.99-12 1.11-12 10811-60109 2.05-12 2.89-12 3.24-12 10811-60109 5.08-13 1.42-12 6.10-13 <-- ?? 10811-60109 5.47-12 1.16-12 2.38-12 10811-60109 6.11-12 2.52-12 8.78-12 10811-60111 1.24-12 2.10-12 2.09-12 10811-60111 1.27-12 2.65-12 1.93-12 10811-60111 1.36-12 1.17-12 1.75-12 10811-60111 1.48-12 1.59-12 1.54-12 10811-60111 2.59-12 3.87-12 5.77-12 10811-60111 3.04-12 5.54-12 1.47-12 1250B 1.22-11 3.04-12 6.54-12 5060A osc only 4.04-12 5.94-12 8.42-12 1.30-11 DOXO8663clone 2.68-12 3.52-12 3.16-12 FTS 1200 #1 7.14-13 1.48-12 1.92-12 FTS 1200 #2 2.99-13 4.30-13 7.69-13 8.65-13 FTS 9110 1.44-12 4.96-13 3.40-13 FTS1000A-100 8.26-13 1.22-12 1.03-12 Motorola 1 1.70-12 2.42-12 1.99-12 Motorola 2 2.01-12 1.71-12 1.75-12 Piezo 1 1.71-12 3.50-12 3.00-12 Piezo 2 1.34-12 1.94-12 3.08-12 Piezo 3 1.41-11 9.50-12 2.00-12 Piezo clone 2.57-12 2.23-12 2.17-12 Piezo X 1.93-12 2.53-12 3.44-12 Wenzel 4 port 7.34-12 1.11-11 2.61-11 Thanks, Mike From gwinn at raytheon.com Tue Jan 20 21:41:05 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Tue, 20 Jan 2009 16:41:05 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <497642DF.6050302@rubidium.dyndns.org> Message-ID: time-nuts-bounces at febo.com wrote on 01/20/2009 04:32:15 PM: > Bruce Griffiths skrev: > > The relatively low thermal conductivity of the steel can will help > > considerably in avoiding thermal damage if the heat is > applied to the joint. > > If the can were copper it would be much more difficult to avoid thermal > > damage. > > When I needed to have a McCoy oscillator can opened my trusty good old > friend Sten did the usual trick of pre-heating the can and then when > applying heat to the solder the thermal difference is lower and hence the > heat-flow away from the joint. Didn't take much time and I think the > oscillator is 100% intact. > > Pre-heating and hot air are his main tools for tricky soldering jobs. He > has low fatality rate on problems like that. This is why we let him do > that kind of stuff at work. I imagine that Sten works *very* fast. I've found that when soldering thermally sensitive things like small coil bobbins made of nylon that a high temperature and relatively large iron is best - the terminals come up to temperature almost instantly, and it's all over before the heat can spread and melt the bobbin. Hot air has the advantage over a flame that overtemperature is less likely with hot air. Joe From magnus at rubidium.dyndns.org Tue Jan 20 21:47:26 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Tue, 20 Jan 2009 22:47:26 +0100 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <4976466E.3060702@rubidium.dyndns.org> Joseph M Gwinn skrev: > time-nuts-bounces at febo.com wrote on 01/20/2009 04:32:15 PM: > >> Bruce Griffiths skrev: >>> The relatively low thermal conductivity of the steel can will help >>> considerably in avoiding thermal damage if the heat is >> applied to the joint. >>> If the can were copper it would be much more difficult to avoid > thermal >>> damage. >> When I needed to have a McCoy oscillator can opened my trusty good old >> friend Sten did the usual trick of pre-heating the can and then when >> applying heat to the solder the thermal difference is lower and hence > the >> heat-flow away from the joint. Didn't take much time and I think the >> oscillator is 100% intact. >> >> Pre-heating and hot air are his main tools for tricky soldering jobs. He > >> has low fatality rate on problems like that. This is why we let him do >> that kind of stuff at work. > > I imagine that Sten works *very* fast. I've found that when soldering > thermally sensitive things like small coil bobbins made of nylon that a > high temperature and relatively large iron is best - the terminals come up > to temperature almost instantly, and it's all over before the heat can > spread and melt the bobbin. > > Hot air has the advantage over a flame that overtemperature is less likely > with hot air. Actually, the pre-heating takes a bit of time... but then it doesn't take much effort to push the solder over to melting and it took relatively little time. The pre-heating doesn't go all the way up there, so melting of plastics isn't really a problem. The pre-heating trick actually makes the big soldering iron rest most of the time... We have boards with so much ground/power grids that it is really a headache to do without pre-heating, which is similar to the iron case soldering problem. So, doing it this way makes it go fast. Cheers, Magnus From phk at phk.freebsd.dk Tue Jan 20 22:17:07 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 20 Jan 2009 22:17:07 +0000 Subject: [time-nuts] More quartz short term stabilities In-Reply-To: Your message of "Tue, 20 Jan 2009 16:36:38 EST." Message-ID: <13865.1232489827@critter.freebsd.dk> I notice there are no ISOTemp's OCXO's on the list, are they uninteresting or just hard to lay hands on ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ed_palmer at sasktel.net Tue Jan 20 23:35:12 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Tue, 20 Jan 2009 17:35:12 -0600 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49765FB0.307@sasktel.net> I was reluctant to consider a torch because I haven't done it and didn't want to cause any more damage. The second (and more serious) reason is that I live in an apartment. My office / computer room / mad scientist's lab is actually a bedroom complete with carpet. Soldering irons I can deal with. Open flames however, are not going to happen. In summer I could go out on the balcony, but right now there's a foot or two of snow out there. In any case, the deed is done. My plan was to use a Dremel with a metal disc coated with diamond dust to cut into the solder seam. However, since the sides of the oscillator were slightly bowed, I had to decide whether to sacrifice the can or the bottom. I chose the bottom. Pretty much destroyed it, but the can barely has a mark on it. I think I can fabricate a new bottom - I'll probably attach it with screws rather than resoldering it. When I look inside the can I can see the solder. It extends about 4 mm from the edge. A torch was the only other way I could have gotten it apart. The problem with the oscillator turned out to be even easier to fix than I could have hoped for. There's a ferrite transformer on the output - possibly a balun. The wire is about the thickness of a hair. The ferrite isn't tied down - it's just held by the leads. I don't know if it took a physical hit or if the solder just dissolved the wire over the years, but one of the leads had broken. I resoldered it and instead of a wobbly level of -20 to -30 dbm into 50 ohms, I now have a much more satisfying level of ~ +12 dbm. And the levels in the rest of the unit now make sense. Instead of hitting a Minicircuit RPD-1 Phase Detector with a level around -30 dbm, it's now seeing a level of +7 dbm - just what it should be. I'd like to thank you, John, and everyone else for their ideas. They were a great help. Ed > Message: 1 > Date: Tue, 20 Jan 2009 09:28:31 -0800 > From: "John Miles" > Subject: Re: [time-nuts] Wenzel Oscillator Repair > To: "Discussion of precise time and frequency measurement" > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > You probably have a lot more room to play with, given the larger housing on > your OCXO. The ULN series is rather densely packaged, and that was one > reason why I wasn't crazy about going after it with a propane torch. In > your case I'd be tempted to try the torch method before actually damaging > the housing with a Dremel tool. > > While fixing a couple of Ovenaire OCXOs that use a similar form factor, I've > noticed that their PC board edges don't come anywhere near the endcap. The > Ovenaire parts were sealed with epoxy, so a heat gun was all that was needed > to open them, but I'm sure I could've opened them with a torch without > hurting anything, if they'd been soldered shut. > > -- john, KE5FX > > >> -----Original Message----- >> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On >> Behalf Of Ed Palmer >> Sent: Tuesday, January 20, 2009 5:59 AM >> To: time-nuts at febo.com >> Subject: Re: [time-nuts] Wenzel Oscillator Repair >> >> >> Now I understand! I was planning to reuse the case. It didn't occur to >> me to sacrifice the case and put the oscillator in another box. >> >> Thanks for the idea, John. >> >> Ed >> >> >>> Message: 3 >>> Date: Mon, 19 Jan 2009 21:20:54 -0800 >>> From: "John Miles" >>> Subject: Re: [time-nuts] Wenzel Oscillator Repair >>> To: "Discussion of precise time and frequency measurement" >>> >>> Message-ID: >>> Content-Type: text/plain; charset="us-ascii" >>> >>> I used a fiberglass-reinforced cutoff wheel. This can open practically >>> anything, but it puts a lot of vibration and dust into the innards of >>> whatever you're taking apart. My guess was that this was safer >>> >> than using a >> >>> torch. >>> >>> Since I wasn't going to be able to maintain the original hermeticity, I >>> remounted the oscillator in a Hammond box, like so: >>> >>> http://www.thegleam.com/ke5fx/w1.jpg >>> >>> I brought the trimmer (which was also damaged in this >>> >> particular oscillator) >> >>> and oven-status LED out to the box lid, along with the four original >>> terminals. Makes a nice package that can be easily opened for >>> >> maintenance: >> >>> http://www.thegleam.com/ke5fx/w2.jpg >>> >>> The repackaged OCXO seems to work fine. I haven't made any hardcore >>> measurements with it but I can tell just by watching the >>> >> counter that its >> >>> short-term stability is similar to my other unmolested 5 MHz ULN. >>> >>> -- john, KE5FX >>> >>> >>>> -----Original Message----- >>>> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On >>>> Behalf Of Ed Palmer >>>> Sent: Monday, January 19, 2009 4:07 PM >>>> To: time-nuts at febo.com >>>> Subject: Re: [time-nuts] Wenzel Oscillator Repair >>>> >>>> >>>> I hadn't thought of using a Dremel. Did you use an abrasive wheel or a >>>> steel cutter? The case on mine looks to be about 20 ga. tin-plated >>>> steel (~0.04" thick). The gap is so small it might have been >>>> >> a friction >> >>>> fit to start with. >>>> >>>> Ed >>>> >>>> >>>>> From: "John Miles" >>>>> Subject: Re: [time-nuts] Wenzel Oscillator Repair >>>>> To: "Discussion of precise time and frequency measurement" >>>>> >>>>> Message-ID: >>>>> Content-Type: text/plain; charset="us-ascii" >>>>> >>>>> I had a similar problem with a 5 MHz OCXO from their ULN >>>>> >>>>> >>>> series. There was >>>> >>>> >>>>> a bad solder joint on the output connection, easy enough to fix >>>>> >>>>> >>>> once I got >>>> >>>> >>>>> the unit open. >>>>> >>>>> In my case I used a Dremel tool to cut the seam. Suggest >>>>> >> wearing a dust >> >>>>> mask, obviously, and keep your cuts close to the perimeter of >>>>> >>>>> >>>> the can, in >>>> >>>> >>>>> case the PC board comes right up to the edge like mine did. >>>>> >>>>> -- john, KE5FX >>>>> >>>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- time-nuts at febo.com >>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to >> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > > > From jmiles at pop.net Wed Jan 21 00:18:41 2009 From: jmiles at pop.net (John Miles) Date: Tue, 20 Jan 2009 16:18:41 -0800 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <49765FB0.307@sasktel.net> Message-ID: > The problem with the oscillator turned out to be even easier to fix than > I could have hoped for. There's a ferrite transformer on the output - > possibly a balun. The wire is about the thickness of a hair. The > ferrite isn't tied down - it's just held by the leads. I don't know if > it took a physical hit or if the solder just dissolved the wire over the > years, but one of the leads had broken. I resoldered it and instead of > a wobbly level of -20 to -30 dbm into 50 ohms, I now have a much more > satisfying level of ~ +12 dbm. And the levels in the rest of the unit > now make sense. Instead of hitting a Minicircuit RPD-1 Phase Detector > with a level around -30 dbm, it's now seeing a level of +7 dbm - just > what it should be. > > I'd like to thank you, John, and everyone else for their ideas. They > were a great help. You're welcome; that's exactly what was wrong with my ULN, actually. The output balun had a broken lead. They should be gluing those down, I guess. Someone had also broken the trimmer by shoving an alignment tool in too far, but that wasn't the main problem. -- john, KE5FX From tvb at LeapSecond.com Wed Jan 21 01:14:27 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Tue, 20 Jan 2009 17:14:27 -0800 Subject: [time-nuts] More quartz short term stabilities References: <20090120.123535.3172.1.cdelect@juno.com> Message-ID: <43E9D43AA8B54962A2C444A87C935136@pc52> > Short term stabilities of a bunch of quartz oscillators. > > I had posted this some time ago but this is an updated version. Corby, Nice set of measurements. Here are ADEV plots of your oscillators: http://www.leapsecond.com/pages/corby/adev1.gif http://www.leapsecond.com/pages/corby/adev2.gif http://www.leapsecond.com/pages/corby/adev3.gif Raw data for above: http://www.leapsecond.com/pages/corby/adev.txt /tvb From bruce.griffiths at xtra.co.nz Wed Jan 21 02:04:37 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 21 Jan 2009 15:04:37 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <43E9D43AA8B54962A2C444A87C935136@pc52> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> Message-ID: <497682B5.2080501@xtra.co.nz> If one turns of the disciplining of the Thunderbolt's internal OCXO, then one can log various parameters such as the 1 pps error. A plot of the resulting OADEV (all tau) using such data is attached. For short tau the GPS receiver noise dominates. For large tau the OCXO noise dominates. If the OADEV plot is symmetric about the minimum then the value of tau at the Allan intercept coincides with the value of tau at the minimum in the OADEV plot. In this case the plot has greater slope after the minimum than before so the value of Tau at the Allan intercept is about 500 sec rather than the 400sec corresponding to the minimum in the OADEV plot. The optimum loop time constant for this particular Thunderbolt is thus around 500sec. In the absence of any other means of measuring the performance of the Thunderbolt as a function of the loop time constant, this technique allows the loop time constant to be set near the optimum for each particular Thunderbolt. Bruce -------------- next part -------------- A non-text attachment was scrubbed... Name: Thunderbolt-Internal-OADEV.gif Type: image/gif Size: 25274 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090121/b6b8a96d/attachment-0001.gif From sar10538 at gmail.com Wed Jan 21 03:51:37 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Wed, 21 Jan 2009 16:51:37 +1300 Subject: [time-nuts] Off Topic question... & Apology Message-ID: <1231b6a80901201951k53667411xb54ec79e367ad235@mail.gmail.com> Dear Time-Nutters I wish to humbly apologize to the over 749 subscribers to this list for my stupid rantings. I had a very bad day and this had pushed me into a manic state, which is a problem for someone with bipolar. Rest-assured, it will be a couple of weeks or so before I can dig myself out of the down state I have now fallen into, so your unlikely to hear from me. OK, stop the cheering now :) I have nothing against the American people at all, I have family and friends there, even though I could have stuck my boot firmly up the backside of one famous US personage Yesterday, but that was only part of my stress. 73, Steve 2009/1/21 John Ackermann N8UR : > Folks, this started out as an off-topic question about getting > inoculations, and has turned into something even more off-topic and less > informative. > > Time-nuts now has over 750 subscribers who joined the list because they > are interested in a high signal-to-noise ratio discussion of precise > time and frequency measurement. Let's respect their time and bandwidth > by limiting discussions to things within the list's charter. > > Specifically, let's close off this discussion of who's stereotyping whom > before it degenerates further. > > Thanks, > > John > YrSysAdmin > ---- > > John Day wrote: >> At 02:17 AM 1/20/2009, you wrote: >>> Chuck, >>> >>> Well, I've heard the same sort of stereotypical comments about the >>> Brits so many times I am fed up with them too. Besides which of those >>> comments can you say does not have an air of truth about them for >>> someone coming from England, or may other places in the World for that >>> matter. >>> >>> You've turned a simple friendly poke at the US system into an all out >>> attack on every US citizen. I read an article the other day about the >>> British "hacker" who "broke into" the military systems over there >>> looking for UFO data. The comments were that he should be given 70 >>> years inside, executed, and a whole lot of stuff about how this guy >>> was such a terrible criminal. No one talked about how the US military >>> had connected a system with secret classified data onto the Net with >>> no admin password. But apparently all the blame was on him. If you >>> leave your car with the door open and the keys in the ignition >>> wouldn't you expect to have it pinched. >>> >>> And whats this stuff about the land of the free, you guys have more >>> legislation on yourselves and on other countries people than many >>> other countries. I sat and watched all the discussion about shooting >>> guns at New Year and the chances of people getting killed. They get >>> killed anyway because it is so easy to get guns over there. Everybody >>> gets the chance to be a crim. Our police don't carry guns routinely >>> and we don't have a gun problem. Sure some idiots get hold of them, >>> and some innocent people get hurt or killed, but it's a major event in >>> this country when that happens, not just the way of life it is for you >>> guys. >>> >>> So please don't come back at me all innocent like and hurt. >>> >>> Regards, >>> Steve >> >> Steve, >> >> What you need to remember is that some Americans have a superiority >> complex - there is nothing of worth or value from anywhere else. We >> shouldn't take this to heart, this is the way they are educated. From >> a very early age Americans are taught that the US is the greatest >> country in the world. The American military is invincible, the >> American education system excels and everybody in the world wants to >> live in the US so we need to keep them out. >> >> Parts of this are true, the US is a great country. But no more so >> than Britain, Canada, Australia, Germany or just about any other >> country. Americans are proud of their country, but often >> unjustifiably so because their media and education system is severely >> xenophobic. >> >> The American military isn't bad, but invincible? Hardly. >> >> The US does have some good universities, but it doesn't mean any >> means have a caveat on good education. Illiteracy rates in the US are >> high for a first world nation. >> >> But to understand the attitude you need to know a lot about the US. >> Since 1973 I have lived in the US on several occasions. I have worked >> for US corporations and the US government. I have also had to live in >> a country where the rest of the world barely exists for the media. >> Where major government figures at the Federal and State level are >> almost totally ignorant of even their closest neighbour. >> >> So these days I live in a community of malcontents! Many of my >> friends here in Canada are Americans who have chosen not to live in >> the US for a variety of reasons. As an immigrant to this country I >> have spoken to many people to try and figure out how Canadians define >> themselves. The one core theme I detect is "we are not Americans". >> Having lived in the US I am happy not to live there now. But don't be >> discouraged, the sort of reaction you have seen here is fairly >> typical. On the whole Americans are very sensitive about any >> perceived criticism of their country and just don't seem to have a >> handle on anyone else's sense of humour. >> >> John >> (An Australian who has lived in too many places to recall). >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From tvb at LeapSecond.com Wed Jan 21 04:46:11 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Tue, 20 Jan 2009 20:46:11 -0800 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> Message-ID: Hi Bruce, Couple of questions. To me the plot looks like it is dominated with measurement noise (negative slope on the left) and OCXO frequency drift (positive slope on the right). You mention "GPS receiver noise" but I don't see that in the plot. Is this a free-running TBolt? If so, what 1pps source are you comparing it to? The title of the plot says, "Undisciplined Thunderbolt OCXO vs. Thunderbolt GPS receiver"; so is this maybe a plot between two different Thunderbolts; one locked, the other unlocked? What TIC was used to collect the data? /tvb ----- Original Message ----- From: "Bruce Griffiths" To: "Tom Van Baak" ; "Discussion of precise time and frequency measurement" Sent: Tuesday, January 20, 2009 6:04 PM Subject: Setting loop TC using thunderbolt internal data. > If one turns of the disciplining of the Thunderbolt's internal OCXO, > then one can log various parameters such as the 1 pps error. > A plot of the resulting OADEV (all tau) using such data is attached. > > For short tau the GPS receiver noise dominates. > For large tau the OCXO noise dominates. > > If the OADEV plot is symmetric about the minimum then the value of tau > at the Allan intercept coincides with the value of tau at the minimum in > the OADEV plot. > In this case the plot has greater slope after the minimum than before so > the value of Tau at the Allan intercept is about 500 sec rather than the > 400sec corresponding to the minimum in the OADEV plot. > The optimum loop time constant for this particular Thunderbolt is thus > around 500sec. > > In the absence of any other means of measuring the performance of the > Thunderbolt as a function of the loop time constant, this technique > allows the loop time constant to be set near the optimum for each > particular Thunderbolt. > > Bruce > From bruce.griffiths at xtra.co.nz Wed Jan 21 05:04:55 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 21 Jan 2009 18:04:55 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> Message-ID: <4976ACF7.3070807@xtra.co.nz> Tom I turned of the OCXO discipling using Thunderbolt monitor menu: Control:Disable Discipling Then I used the Window: Logging Dialog box to enable logging of 1) Time of week (sec) 2) PPS offset (ns) 3) 10MHz offset (ppb) 4) DAC voltage 5) Temperature to a data file for about 40K sec. The Thunderbolt keeps the DAC voltage constant and continues to measure the oscillator offset and PPS offset even whilst the OCXO disciplining is disabled. The measurement noise on the LHS is that of the Thunderbolt receiver etc itself. The RHS is essentially OCXO drift whilst discipling is turned off. The thunderbolt has its own internal TIC or equivalent thereto. To increase the certainty that the receiver is behaving as I believe it is when configured like this, it would be nice to simultaneously measure the ADEV of the undisciplined OCXO output by other means. Unfortunately I am not at present able to do this even though I do have another GPSDO availble. Bruce Tom Van Baak wrote: > Hi Bruce, > > Couple of questions. To me the plot looks like it is dominated > with measurement noise (negative slope on the left) and OCXO > frequency drift (positive slope on the right). > > You mention "GPS receiver noise" but I don't see that in the > plot. Is this a free-running TBolt? If so, what 1pps source are > you comparing it to? > > The title of the plot says, "Undisciplined Thunderbolt OCXO vs. > Thunderbolt GPS receiver"; so is this maybe a plot between > two different Thunderbolts; one locked, the other unlocked? > What TIC was used to collect the data? > > /tvb > > ----- Original Message ----- > From: "Bruce Griffiths" > To: "Tom Van Baak" ; "Discussion of precise time and frequency measurement" > Sent: Tuesday, January 20, 2009 6:04 PM > Subject: Setting loop TC using thunderbolt internal data. > > > >> If one turns of the disciplining of the Thunderbolt's internal OCXO, >> then one can log various parameters such as the 1 pps error. >> A plot of the resulting OADEV (all tau) using such data is attached. >> >> For short tau the GPS receiver noise dominates. >> For large tau the OCXO noise dominates. >> >> If the OADEV plot is symmetric about the minimum then the value of tau >> at the Allan intercept coincides with the value of tau at the minimum in >> the OADEV plot. >> In this case the plot has greater slope after the minimum than before so >> the value of Tau at the Allan intercept is about 500 sec rather than the >> 400sec corresponding to the minimum in the OADEV plot. >> The optimum loop time constant for this particular Thunderbolt is thus >> around 500sec. >> >> In the absence of any other means of measuring the performance of the >> Thunderbolt as a function of the loop time constant, this technique >> allows the loop time constant to be set near the optimum for each >> particular Thunderbolt. >> >> Bruce >> >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From holrum at hotmail.com Wed Jan 21 05:00:28 2009 From: holrum at hotmail.com (Mark Sims) Date: Wed, 21 Jan 2009 05:00:28 +0000 Subject: [time-nuts] Wenzel Oscillator Repair (plus Tektronix CG551/CG5001/DC509/DC5009) In-Reply-To: References: Message-ID: Interesting... I just fixed a couple of Tek CG551 and 5001 calibration generators that had the same problem. Tek uses a DC isolated shift register chain to drive the internal control signals. The clock and data lines run through toroidal pulse transformers that are mounted on small plastic carriers. Turns out that the where the toroid leads are attached to the carrier leads they were broken. The toroids are not pookied down to the carrier. And, by the way, if you have a DC509 or DC5009 counter that is displaying error 320, the problem is most likely a ruptured Q1401 transistor on the gate line. I fixed half a dozen of these things (all from different sources) with the exact same problem... magic smoke got out of the package... ---------------------------------------- The problem with the oscillator turned out to be even easier to fix than I could have hoped for. There's a ferrite transformer on the output - possibly a balun. The wire is about the thickness of a hair. The ferrite isn't tied down - it's just held by the leads. _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From tvb at LeapSecond.com Wed Jan 21 05:23:53 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Tue, 20 Jan 2009 21:23:53 -0800 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <4976ACF7.3070807@xtra.co.nz> Message-ID: <7F834998A6DC45AB8744C56D8BDED245@pc52> Ah, OK. So you keep the antenna connected and you keep the GPS receiver in position hold mode, still receiving fixes. All you're doing is disabling the software disciplining algorithm. That sounds like a good test. Let me try this too and see if I agree with your conclusions. I'll try to simultaneously measure the 1PPS or 10 MHz outputs as you suggest. Has anyone hacked a TBolt yet to find which internal pin has a raw 1PPS from the GPS engine (as opposed to the 1PPS divided down from the OCXO)? /tvb ----- Original Message ----- From: "Bruce Griffiths" To: "Tom Van Baak" ; "Discussion of precise time and frequency measurement" Sent: Tuesday, January 20, 2009 9:04 PM Subject: Re: [time-nuts] Setting loop TC using thunderbolt internal data. > Tom > > I turned of the OCXO discipling using Thunderbolt monitor menu: > > Control:Disable Discipling > > > Then I used the Window: Logging Dialog box to enable logging of > > 1) Time of week (sec) > 2) PPS offset (ns) > 3) 10MHz offset (ppb) > 4) DAC voltage > 5) Temperature > > to a data file for about 40K sec. > > > The Thunderbolt keeps the DAC voltage constant and continues to measure > the oscillator offset and PPS offset even whilst the OCXO disciplining > is disabled. > > The measurement noise on the LHS is that of the Thunderbolt receiver etc > itself. > The RHS is essentially OCXO drift whilst discipling is turned off. > > The thunderbolt has its own internal TIC or equivalent thereto. > > To increase the certainty that the receiver is behaving as I believe it > is when configured like this, it would be nice to simultaneously measure > the ADEV of the undisciplined OCXO output by other means. > > Unfortunately I am not at present able to do this even though I do have > another GPSDO availble. > > Bruce > > Tom Van Baak wrote: >> Hi Bruce, >> >> Couple of questions. To me the plot looks like it is dominated >> with measurement noise (negative slope on the left) and OCXO >> frequency drift (positive slope on the right). >> >> You mention "GPS receiver noise" but I don't see that in the >> plot. Is this a free-running TBolt? If so, what 1pps source are >> you comparing it to? >> >> The title of the plot says, "Undisciplined Thunderbolt OCXO vs. >> Thunderbolt GPS receiver"; so is this maybe a plot between >> two different Thunderbolts; one locked, the other unlocked? >> What TIC was used to collect the data? >> >> /tvb >> >> ----- Original Message ----- >> From: "Bruce Griffiths" >> To: "Tom Van Baak" ; "Discussion of precise time and frequency measurement" >> Sent: Tuesday, January 20, 2009 6:04 PM >> Subject: Setting loop TC using thunderbolt internal data. >> >> >> >>> If one turns of the disciplining of the Thunderbolt's internal OCXO, >>> then one can log various parameters such as the 1 pps error. >>> A plot of the resulting OADEV (all tau) using such data is attached. >>> >>> For short tau the GPS receiver noise dominates. >>> For large tau the OCXO noise dominates. >>> >>> If the OADEV plot is symmetric about the minimum then the value of tau >>> at the Allan intercept coincides with the value of tau at the minimum in >>> the OADEV plot. >>> In this case the plot has greater slope after the minimum than before so >>> the value of Tau at the Allan intercept is about 500 sec rather than the >>> 400sec corresponding to the minimum in the OADEV plot. >>> The optimum loop time constant for this particular Thunderbolt is thus >>> around 500sec. >>> >>> In the absence of any other means of measuring the performance of the >>> Thunderbolt as a function of the loop time constant, this technique >>> allows the loop time constant to be set near the optimum for each >>> particular Thunderbolt. >>> >>> Bruce >>> >>> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > > From robert8rpi at yahoo.co.uk Wed Jan 21 08:03:53 2009 From: robert8rpi at yahoo.co.uk (Robert Atkinson) Date: Wed, 21 Jan 2009 08:03:53 +0000 (GMT) Subject: [time-nuts] Tin Can Soldering (was Wenzel Oscillator Repair) Message-ID: <571213.27175.qm@web27108.mail.ukl.yahoo.com> Hi, Wasn't following this one "real-time" but there is a useful trick used on aircraft instruments wit soldered cases. They put a ring of tinned copper wire in the joint before they solder it, leaving a "tail" sticking out. Next time you want to open it, you just pull the wire out (cold) and it brings the solder with it. It also provides a good surface and heat spreader when you are soldering. The aircraft cans have space left for the wire, but many pressed cans have a radius that helps or push the end in below flush. Robert G8RPI. From magnus at rubidium.dyndns.org Wed Jan 21 08:12:07 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 21 Jan 2009 09:12:07 +0100 Subject: [time-nuts] Wenzel Oscillator Repair (plus Tektronix CG551/CG5001/DC509/DC5009) In-Reply-To: References: Message-ID: <4976D8D7.8080805@rubidium.dyndns.org> Mark Sims skrev: > Interesting... I just fixed a couple of Tek CG551 and 5001 calibration generators that had the same problem. Tek uses a DC isolated shift register chain to drive the internal control signals. The clock and data lines run through toroidal pulse transformers that are mounted on small plastic carriers. Turns out that the where the toroid leads are attached to the carrier leads they were broken. The toroids are not pookied down to the carrier. This is a typical design error where the designer should have spent a longer time at the repair-shop prior to getting onto the design desk in order to be experienced enough. I have repaired alot of equipment where people have not understood how unsupported weight may wear and tear over the years. People that think solder is some form of magic super-glue. For a few cases vibration isolation *might* be on their mind, but the solution got wrong never the less. Cheers, Magnus From magnus at rubidium.dyndns.org Wed Jan 21 08:32:51 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 21 Jan 2009 09:32:51 +0100 Subject: [time-nuts] ADEV vs. OADEV Message-ID: <4976DDB3.2030802@rubidium.dyndns.org> Hi! I have been quite surprised to see the abbreviation OADEV appear. I assume that this means Overlapped Allan Deviation, but this is confusing since the Allan Deviation estimates already is overlapping. However, I have seen that some use a non-overlapping estimator, but this type of estimator has an unwanted filtering effect and should not be used. If a distinction between these ADEV estimators should be used, then the standard (overlapping) estimator should continue to be called ADEV and the non-overlapping (back-to-back) could be called NOADEV ?r whatever... I have done a fair amount of digging around many sources around ADEV and friends so I think I got it right. Unless someone can give a meaningful explanation and I really expect a good article detailing the difference and benefits... Cheers, Magnus From magnus at rubidium.dyndns.org Wed Jan 21 08:38:29 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 21 Jan 2009 09:38:29 +0100 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <7F834998A6DC45AB8744C56D8BDED245@pc52> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <4976ACF7.3070807@xtra.co.nz> <7F834998A6DC45AB8744C56D8BDED245@pc52> Message-ID: <4976DF05.1030606@rubidium.dyndns.org> Tom, Tom Van Baak skrev: > Ah, OK. So you keep the antenna connected and you keep the > GPS receiver in position hold mode, still receiving fixes. > > All you're doing is disabling the software disciplining algorithm. > That sounds like a good test. Let me try this too and see if I > agree with your conclusions. We discussed this a little while back. I proposed a three-cornered hat using two receivers and one counter... as the Thunderbolts has a builtin TIC to GPS which can be logged. We also discussed just running a single Thunderbolt in holdover. Others had already tried that approach. Bruce and I discussed to some degree the effect of steering on the result. > I'll try to simultaneously measure the 1PPS or 10 MHz outputs > as you suggest. > > Has anyone hacked a TBolt yet to find which internal pin has > a raw 1PPS from the GPS engine (as opposed to the 1PPS > divided down from the OCXO)? Hmm... I have not even "repaired" (in the sense, that they are broken until opened and "repaired", i.e. just looking under the hood for sake of curiosity). any of mine... Cheers, Magnus From bruce.griffiths at xtra.co.nz Wed Jan 21 09:01:13 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 21 Jan 2009 22:01:13 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <4976DF05.1030606@rubidium.dyndns.org> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <4976ACF7.3070807@xtra.co.nz> <7F834998A6DC45AB8744C56D8BDED245@pc52> <4976DF05.1030606@rubidium.dyndns.org> Message-ID: <4976E459.3000707@xtra.co.nz> Magnus Danielson wrote: > Tom, > > Tom Van Baak skrev: > >> Ah, OK. So you keep the antenna connected and you keep the >> GPS receiver in position hold mode, still receiving fixes. >> >> All you're doing is disabling the software disciplining algorithm. >> That sounds like a good test. Let me try this too and see if I >> agree with your conclusions. >> > > We discussed this a little while back. I proposed a three-cornered hat > using two receivers and one counter... as the Thunderbolts has a builtin > TIC to GPS which can be logged. We also discussed just running a single > Thunderbolt in holdover. Others had already tried that approach. Bruce > and I discussed to some degree the effect of steering on the result. > > >> I'll try to simultaneously measure the 1PPS or 10 MHz outputs >> as you suggest. >> >> Has anyone hacked a TBolt yet to find which internal pin has >> a raw 1PPS from the GPS engine (as opposed to the 1PPS >> divided down from the OCXO)? >> > > Hmm... I have not even "repaired" (in the sense, that they are broken > until opened and "repaired", i.e. just looking under the hood for sake > of curiosity). any of mine... > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > Magnus There may not even be a real PPS signal produced by the GPS engine which is compared with the PPS generated by dividing down the OCXO output. With the GPS engine LO derived from the OCXO, having a real PPS signal generated by the GPS engine for such a comparison isnt necessary in order to measure the phase error of the PPS signal generated from the OCXO output. Bruce From GandalfG8 at aol.com Wed Jan 21 09:24:06 2009 From: GandalfG8 at aol.com (GandalfG8 at aol.com) Date: Wed, 21 Jan 2009 04:24:06 EST Subject: [time-nuts] Tbolt with Palisade? Message-ID: In a message dated 20/01/2009 09:32:45 GMT Standard Time, grant at ghengineering.co.uk writes: Guess I'll have to start a search for an HP58532A, VIC-100, Vaisala or similar. I don't think a cheapy ?4 patch antenna will give the same performance. ----------------- Hi Grant I think this really does depend on where you are, satellites in view etc, and what level of performance you're actually looking for. I have a few different timing antennas but have found these don't give very reliable reception indoors. Until I can get these mounted outdoors I have been having good results on various receivers using some small Trimble magnetic patch antennas, specified 26dB gain, attached to a steel plate and sitting on a shelf inside a one level timber framed house on the west coast of Scotland. These came via a buy it now from the usual place at $21 for 10 about a year ago. Driving a pair of Thunderbolts with these and comparing them with an HP 53132A counter, either one as reference and the other as input, once locked I see variations of just a few places around zero in the 10th decimal place. I have used this test on any two units selected from four with consistent results. Not a very scientific test perhaps, and nothing else measured, but as regards frequency at least I don't think they're suffering too much from their "lesser" antennas:-) regards Nigel GM8PZR From VK3FGJM at commtelns.com Wed Jan 21 13:29:28 2009 From: VK3FGJM at commtelns.com (VK3FGJM) Date: Thu, 22 Jan 2009 00:29:28 +1100 Subject: [time-nuts] Tbolt monitor software Message-ID: <50D403A38069BF4196F41887738C03EE03350B@companyweb> Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM From gwinn at raytheon.com Wed Jan 21 16:06:31 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Wed, 21 Jan 2009 11:06:31 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <4976466E.3060702@rubidium.dyndns.org> Message-ID: Magnus, time-nuts-bounces at febo.com wrote on 01/20/2009 04:47:26 PM: > Joseph M Gwinn skrev: > > time-nuts-bounces at febo.com wrote on 01/20/2009 04:32:15 PM: > > > >> Bruce Griffiths skrev: > >>> The relatively low thermal conductivity of the steel can will help > >>> considerably in avoiding thermal damage if the heat is > >> applied to the joint. > >>> If the can were copper it would be much more difficult to avoid > > thermal > >>> damage. > >> When I needed to have a McCoy oscillator can opened my > trusty good old > >> friend Sten did the usual trick of pre-heating the can and then when > >> applying heat to the solder the thermal difference is lower and hence > > the > >> heat-flow away from the joint. Didn't take much time and I think the > >> oscillator is 100% intact. > >> > >> Pre-heating and hot air are his main tools for tricky > soldering jobs. He > > > >> has low fatality rate on problems like that. This is why we > let him do > >> that kind of stuff at work. > > > > I imagine that Sten works *very* fast. I've found that when soldering > > thermally sensitive things like small coil bobbins made of > nylon that a > > high temperature and relatively large iron is best - the > terminals come up > > to temperature almost instantly, and it's all over before theheat can > > spread and melt the bobbin. > > > > Hot air has the advantage over a flame that overtemperature > is less likely > > with hot air. > > Actually, the pre-heating takes a bit of time... but then it doesn't > take much effort to push the solder over to melting and it took > relatively little time. The pre-heating doesn't go all the way up there, > so melting of plastics isn't really a problem. > > The pre-heating trick actually makes the big soldering iron rest most of > the time... > > We have boards with so much ground/power grids that it is really a > headache to do without pre-heating, which is similar to the iron case > soldering problem. > > So, doing it this way makes it go fast. I think we are talking about different things. For getting chips off a big multilayer board, preheat plus hot air is a standard way to go, but we are talking about how to unsolder a steel can with foam insulation within. Slow heating to near soldering temperature is likely to yield a heap of goo. The point of the torch method is to heat the can's solder seam up *fast*, so the solder melts before the foam. Joe From cfharris at erols.com Wed Jan 21 16:34:41 2009 From: cfharris at erols.com (Chuck Harris) Date: Wed, 21 Jan 2009 11:34:41 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49774EA1.2020406@erols.com> Hi Joe, Nope, Magnus is talking about foam insulated hermetically sealed ocxo's. The point you are missing is the preheater is only set for a temperature that the foam, etc. can take on a continuous basis... such as +105C. This preheat reduces the amount of additional heat that must be added to make the solder melt. The net result is usually so nice that you cannot even tell the foam has even been heated. -Chuck Harris > > I think we are talking about different things. For getting chips off a > big multilayer board, preheat plus hot air is a standard way to go, but we > are talking about how to unsolder a steel can with foam insulation within. > Slow heating to near soldering temperature is likely to yield a heap of > goo. > > The point of the torch method is to heat the can's solder seam up *fast*, > so the solder melts before the foam. > > Joe > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From n3izn at aol.com Wed Jan 21 16:55:29 2009 From: n3izn at aol.com (n3izn at aol.com) Date: Wed, 21 Jan 2009 11:55:29 -0500 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <50D403A38069BF4196F41887738C03EE03350B@companyweb> References: <50D403A38069BF4196F41887738C03EE03350B@companyweb> Message-ID: <8CB4A0032F9A9F2-EE8-3B4@webmail-me15.sysops.aol.com> Did you select the right comm port? I power mine off a lot and it has always come back. -----Original Message----- From: VK3FGJM To: time-nuts at febo.com Sent: Wed, 21 Jan 2009 5:29 am Subject: [time-nuts] Tbolt monitor software Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From gwinn at raytheon.com Wed Jan 21 17:17:48 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Wed, 21 Jan 2009 12:17:48 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <49774EA1.2020406@erols.com> Message-ID: Chuck, time-nuts-bounces at febo.com wrote on 01/21/2009 11:34:41 AM: > Hi Joe, > > Nope, Magnus is talking about foam insulated hermetically sealed > ocxo's. > > The point you are missing is the preheater is only set for a temperature > that the foam, etc. can take on a continuous basis... such as +105C. > This preheat reduces the amount of additional heat that must be added > to make the solder melt. The net result is usually so nice that you > cannot even tell the foam has even been heated. That the foam must handle the oven temperature is a good point. Certainly some preheat can help, but typical 63-37 eutectic solder melts at 183 C, and for reasonable speed one must heat the metal at least 50 C hotter, and soldering irons are run at 310 C (590 F, 600 F being typical). The solder used on the cans I've seen looks more like 60-40 radio solder, so higher temperatures may be needed. It's less damaging to go a bit high than a bit low, because if one is high, the can cover still comes off quickly. And the faster this is done, the better. One preheats circuit boards to about 115C before soldering, if only to ensure that all moisture is driven off. So 105C is in the range. Joe > > -Chuck Harris > > > > I think we are talking about different things. For getting chips off a > > big multilayer board, preheat plus hot air is a standard way to go, but we > > are talking about how to unsolder a steel can with foam insulation within. > > Slow heating to near soldering temperature is likely to yield a heap of > > goo. > > > > The point of the torch method is to heat the can's solder seam up *fast*, > > so the solder melts before the foam. > > > > Joe > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to https://www.febo.com/cgi- > bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi- > bin/mailman/listinfo/time-nuts > and follow the instructions there. From cdelect at juno.com Wed Jan 21 17:29:11 2009 From: cdelect at juno.com (Corby Dawson) Date: Wed, 21 Jan 2009 09:29:11 -0800 Subject: [time-nuts] Isotemp OCXO36-54M pinout needed Message-ID: <20090121.092912.1024.2.cdelect@juno.com> Hi, I bought an Isotemp OCXO36-54M a couple years ago on eBay and used it for a short while. I wanted to run some tests on it but I can't find the pinout! Can anyone help? Much Appreciated! Corby Dawson ____________________________________________________________ Find the right voice for your project by clicking here! http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2M9w0AqImkBFZYOgNquPMf3ToZyBWbufcSkFbWCLUKG2ZPr/ From wb6bnq at cox.net Wed Jan 21 17:39:48 2009 From: wb6bnq at cox.net (WB6BNQ) Date: Wed, 21 Jan 2009 09:39:48 -0800 Subject: [time-nuts] Isotemp OCXO36-54M pinout needed References: <20090121.092912.1024.2.cdelect@juno.com> Message-ID: <49775DE3.B279C131@cox.net> Hi Corby, Took a while to find it, but I knew I had uploaded the data. Half way down this page from KO4BB's site. http://www.ko4bb.com/cgi-bin/manuals.pl?dir=05)_GPS_Timing Bill....WB6BNQ Corby Dawson wrote: > Hi, > > I bought an Isotemp OCXO36-54M a couple years ago on eBay and used it > for a short while. > > I wanted to run some tests on it but I can't find the pinout! > > Can anyone help? > > Much Appreciated! > > Corby Dawson > ____________________________________________________________ > Find the right voice for your project by clicking here! > http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2M9w0AqImkBFZYOgNquPMf3ToZyBWbufcSkFbWCLUKG2ZPr/ > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From cfharris at erols.com Wed Jan 21 17:41:44 2009 From: cfharris at erols.com (Chuck Harris) Date: Wed, 21 Jan 2009 12:41:44 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49775E58.7090109@erols.com> Hi Joe, When you preheat to 105C, you don't need to travel as far to reach the melting point of the solder as you do from room temperature (25C). That makes a big difference in how much power you need to couple into the joint to make it melt. If you go straight to the torch, and use the brute force supply of energy to make the joint melt quickly, you will overshoot the temperature every time. A couple of seconds too long, and you can make quite a mess. I've done it both ways, with the torch, you are moving very quickly, and making hasty yanks and grabs to try and remove the cover as quickly as possible. With preheat you can move leisurely, and use a small iron, or hot air gun, to provide the additional calories needed to melt the solder. Preheat is best by a long shot. Try it and I am sure you will agree. -Chuck Harris Joseph M Gwinn wrote: > Chuck, > > > time-nuts-bounces at febo.com wrote on 01/21/2009 11:34:41 AM: > >> Hi Joe, >> >> Nope, Magnus is talking about foam insulated hermetically sealed >> ocxo's. >> >> The point you are missing is the preheater is only set for a temperature >> that the foam, etc. can take on a continuous basis... such as +105C. >> This preheat reduces the amount of additional heat that must be added >> to make the solder melt. The net result is usually so nice that you >> cannot even tell the foam has even been heated. > > That the foam must handle the oven temperature is a good point. Certainly > some preheat can help, but typical 63-37 eutectic solder melts at 183 C, > and for reasonable speed one must heat the metal at least 50 C hotter, and > soldering irons are run at 310 C (590 F, 600 F being typical). The solder > used on the cans I've seen looks more like 60-40 radio solder, so higher > temperatures may be needed. It's less damaging to go a bit high than a > bit low, because if one is high, the can cover still comes off quickly. > And the faster this is done, the better. > > One preheats circuit boards to about 115C before soldering, if only to > ensure that all moisture is driven off. So 105C is in the range. > > Joe > > > >> -Chuck Harris >>> I think we are talking about different things. For getting chips off > a >>> big multilayer board, preheat plus hot air is a standard way to go, > but we >>> are talking about how to unsolder a steel can with foam insulation > within. >>> Slow heating to near soldering temperature is likely to yield a heap > of >>> goo. >>> >>> The point of the torch method is to heat the can's solder seam up > *fast*, >>> so the solder melts before the foam. >>> >>> Joe >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to https://www.febo.com/cgi- >> bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi- >> bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From wb6bnq at cox.net Wed Jan 21 17:42:02 2009 From: wb6bnq at cox.net (WB6BNQ) Date: Wed, 21 Jan 2009 09:42:02 -0800 Subject: [time-nuts] Isotemp OCXO36-54M pinout needed References: <20090121.092912.1024.2.cdelect@juno.com> <49775DE3.B279C131@cox.net> Message-ID: <49775E6A.1CC766A5@cox.net> Corby, My BAD ! I got as far as the word ISOTEMP and failed to pay attention to the part number. Sorry about that. Bill....WB6BNQ WB6BNQ wrote: > Hi Corby, > > Took a while to find it, but I knew I had uploaded the data. Half way down this page from KO4BB's > site. > > http://www.ko4bb.com/cgi-bin/manuals.pl?dir=05)_GPS_Timing > > Bill....WB6BNQ > > Corby Dawson wrote: > > > Hi, > > > > I bought an Isotemp OCXO36-54M a couple years ago on eBay and used it > > for a short while. > > > > I wanted to run some tests on it but I can't find the pinout! > > > > Can anyone help? > > > > Much Appreciated! > > > > Corby Dawson > > ____________________________________________________________ > > Find the right voice for your project by clicking here! > > http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2M9w0AqImkBFZYOgNquPMf3ToZyBWbufcSkFbWCLUKG2ZPr/ > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From bruce.griffiths at xtra.co.nz Wed Jan 21 19:41:40 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Thu, 22 Jan 2009 08:41:40 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <4976DF05.1030606@rubidium.dyndns.org> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <4976ACF7.3070807@xtra.co.nz> <7F834998A6DC45AB8744C56D8BDED245@pc52> <4976DF05.1030606@rubidium.dyndns.org> Message-ID: <49777A74.30203@xtra.co.nz> Hej Magnus Magnus Danielson wrote: > Tom, > > Tom Van Baak skrev: > >> Ah, OK. So you keep the antenna connected and you keep the >> GPS receiver in position hold mode, still receiving fixes. >> >> All you're doing is disabling the software disciplining algorithm. >> That sounds like a good test. Let me try this too and see if I >> agree with your conclusions. >> > > We discussed this a little while back. I proposed a three-cornered hat > using two receivers and one counter... as the Thunderbolts has a builtin > TIC to GPS which can be logged. We also discussed just running a single > Thunderbolt in holdover. Others had already tried that approach. Bruce > and I discussed to some degree the effect of steering on the result. > > The 3 cornered hat technique only works well (even in the extended form allowing finite correlations between the 3 sources) when the ADEV of the sources being compared aren't too disparate. Consequently this comparison will only work well for tau values in the vicinity of the Allan intercepts which in turn will need to be not too disparate. >> I'll try to simultaneously measure the 1PPS or 10 MHz outputs >> as you suggest. >> >> Has anyone hacked a TBolt yet to find which internal pin has >> a raw 1PPS from the GPS engine (as opposed to the 1PPS >> divided down from the OCXO)? >> > > Hmm... I have not even "repaired" (in the sense, that they are broken > until opened and "repaired", i.e. just looking under the hood for sake > of curiosity). any of mine... > > Cheers, > Magnus > > > Bruce From gwinn at raytheon.com Wed Jan 21 20:22:31 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Wed, 21 Jan 2009 15:22:31 -0500 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: <49775E58.7090109@erols.com> Message-ID: Chuck, time-nuts-bounces at febo.com wrote on 01/21/2009 12:41:44 PM: > Hi Joe, > > When you preheat to 105C, you don't need to travel as far to > reach the melting point of the solder as you do from room > temperature (25C). That makes a big difference in how much > power you need to couple into the joint to make it melt. > > If you go straight to the torch, and use the brute force > supply of energy to make the joint melt quickly, you will > overshoot the temperature every time. A couple of seconds > too long, and you can make quite a mess. > > I've done it both ways, with the torch, you are moving very > quickly, and making hasty yanks and grabs to try and remove the > cover as quickly as possible. With preheat you can move > leisurely, and use a small iron, or hot air gun, to provide > the additional calories needed to melt the solder. I've used many a torch, and the trick is to keep the flame far enough from the work, so the temperature of the air hitting the work is reasonable. But it does take practice to get this right. The danger is often overheating terminals and the like, not the big areas of metal. But I do have two hot-air guns as well, glorified hair dryers, one for stripping paint (1000 F?), the other for shrinking tubing (I'll have to measure the temperature). Need to be sure that the gun can melt solder fast enough. > Preheat is best by a long shot. Try it and I am sure you > will agree. Can't say that I ever bothered, but I don't disagree. There is certainly nothing to lose if one preheats. As for epoxy-glued covers, I have a war story. In the 1960s, my Father worked at RCA in a project that was building various components of the moon lander. The electronics was built in "cordwoods" which were a pair of two-sided glass epoxy circuit boards with axial-lead components strung between the two boards. These boards were about 25mm apart, and the bottom board was potted in alumina-loaded epoxy. The epoxy-potted side of the cordwood was glued to an aluminum cold plate with alumina-loaded urethane glue. The alumina was for thermal conductivity. This assembly had to work in a vacuum, so convection was unlikely. The problem was that if a module in the center failed, one had to remove (and usually destroy) all the modules from the closest edge to the bad module, using a hot knife to cut the urethane. Then, one of the technicians had a brilliant idea: Use a paperclip bent into a hook, some stiff wire bent into a bridge, and a rubber band to put a steady pull on the bad module, put the whole affair in the 180 F oven, and go to coffee. On return, the module would be free, dangling on the rubber band. The glue had crept under the combination of heat and steady stress until it let go. This saved an ungodly amount of money. (My Father's role was to do the mechanical analysis to prove that this method wouldn't damage any of the modules, removed or adjacent.) Many epoxies will also creep, especially when hot. Joe > -Chuck Harris > > Joseph M Gwinn wrote: > > Chuck, > > > > > > time-nuts-bounces at febo.com wrote on 01/21/2009 11:34:41 AM: > > > >> Hi Joe, > >> > >> Nope, Magnus is talking about foam insulated hermetically sealed > >> ocxo's. > >> > >> The point you are missing is the preheater is only set for a > temperature > >> that the foam, etc. can take on a continuous basis... such as +105C. > >> This preheat reduces the amount of additional heat that must be added > >> to make the solder melt. The net result is usually so nice that you > >> cannot even tell the foam has even been heated. > > > > That the foam must handle the oven temperature is a good > point. Certainly > > some preheat can help, but typical 63-37 eutectic solder > melts at 183 C, > > and for reasonable speed one must heat the metal at least 50 > C hotter, and > > soldering irons are run at 310 C (590 F, 600 F being > typical). The solder > > used on the cans I've seen looks more like 60-40 radio > solder, so higher > > temperatures may be needed. It's less damaging to go a bit > high than a > > bit low, because if one is high, the can cover still comes > off quickly. > > And the faster this is done, the better. > > > > One preheats circuit boards to about 115C before soldering, if only to > > ensure that all moisture is driven off. So 105C is in the range. > > > > Joe > > > > > > > >> -Chuck Harris > >>> I think we are talking about different things. For gettingchips off > > a > >>> big multilayer board, preheat plus hot air is a standard way to go, > > but we > >>> are talking about how to unsolder a steel can with foam insulation > > within. > >>> Slow heating to near soldering temperature is likely to > yield a heap > > of > >>> goo. > >>> > >>> The point of the torch method is to heat the can's solder seam up > > *fast*, > >>> so the solder melts before the foam. > >>> > >>> Joe > >>> > >>> _______________________________________________ > >>> time-nuts mailing list -- time-nuts at febo.com > >>> To unsubscribe, go to https://www.febo.com/cgi- > >> bin/mailman/listinfo/time-nuts > >>> and follow the instructions there. > >>> > >> _______________________________________________ > >> time-nuts mailing list -- time-nuts at febo.com > >> To unsubscribe, go to https://www.febo.com/cgi- > >> bin/mailman/listinfo/time-nuts > >> and follow the instructions there. > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to https://www.febo.com/cgi- > bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi- > bin/mailman/listinfo/time-nuts > and follow the instructions there. From VK3FGJM at commtelns.com Wed Jan 21 20:32:11 2009 From: VK3FGJM at commtelns.com (VK3FGJM) Date: Thu, 22 Jan 2009 07:32:11 +1100 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <8CB4A0032F9A9F2-EE8-3B4@webmail-me15.sysops.aol.com> References: <50D403A38069BF4196F41887738C03EE03350B@companyweb> <8CB4A0032F9A9F2-EE8-3B4@webmail-me15.sysops.aol.com> Message-ID: <50D403A38069BF4196F41887738C03EE03350C@companyweb> Hi, Yes, I can see alarm status and changes when unplugging antenna etc. As mentioned the unit actually works, just no data certain displayed. Regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of n3izn at aol.com Sent: Thursday, 22 January 2009 3:55 AM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Did you select the right comm port? I power mine off a lot and it has always come back. -----Original Message----- From: VK3FGJM To: time-nuts at febo.com Sent: Wed, 21 Jan 2009 5:29 am Subject: [time-nuts] Tbolt monitor software Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg From cdelect at juno.com Wed Jan 21 20:32:00 2009 From: cdelect at juno.com (Corby Dawson) Date: Wed, 21 Jan 2009 12:32:00 -0800 Subject: [time-nuts] Isotemp OCXO36-54M pinout needed Message-ID: <20090121.123201.1024.4.cdelect@juno.com> Thanks, Those are not the ones. The Isotemp OCXO36-54M is approx 2" X 2" X5" with an octal base. Corby ____________________________________________________________ Buy and sell stock online. Best online broker. Click here. http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw1gl65bkwLqdXTZgogMUZ1rJMplvQuuR7fQP3gi0TtGhy8fv/ From magnus at rubidium.dyndns.org Wed Jan 21 21:05:58 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 21 Jan 2009 22:05:58 +0100 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <4976E459.3000707@xtra.co.nz> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <4976ACF7.3070807@xtra.co.nz> <7F834998A6DC45AB8744C56D8BDED245@pc52> <4976DF05.1030606@rubidium.dyndns.org> <4976E459.3000707@xtra.co.nz> Message-ID: <49778E36.7000004@rubidium.dyndns.org> Bruce Griffiths skrev: > Magnus Danielson wrote: >> Tom, >> >> Tom Van Baak skrev: >> >>> Ah, OK. So you keep the antenna connected and you keep the >>> GPS receiver in position hold mode, still receiving fixes. >>> >>> All you're doing is disabling the software disciplining algorithm. >>> That sounds like a good test. Let me try this too and see if I >>> agree with your conclusions. >>> >> We discussed this a little while back. I proposed a three-cornered hat >> using two receivers and one counter... as the Thunderbolts has a builtin >> TIC to GPS which can be logged. We also discussed just running a single >> Thunderbolt in holdover. Others had already tried that approach. Bruce >> and I discussed to some degree the effect of steering on the result. >> >> >>> I'll try to simultaneously measure the 1PPS or 10 MHz outputs >>> as you suggest. >>> >>> Has anyone hacked a TBolt yet to find which internal pin has >>> a raw 1PPS from the GPS engine (as opposed to the 1PPS >>> divided down from the OCXO)? >>> >> Hmm... I have not even "repaired" (in the sense, that they are broken >> until opened and "repaired", i.e. just looking under the hood for sake >> of curiosity). any of mine... >> >> Cheers, >> Magnus >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > Magnus > > There may not even be a real PPS signal produced by the GPS engine which > is compared with the PPS generated by dividing down the OCXO output. > With the GPS engine LO derived from the OCXO, having a real PPS signal > generated by the GPS engine for such a comparison isnt necessary in > order to measure the phase error of the PPS signal generated from the > OCXO output. Actually, the PPS out may very well be the PPS output of the engine... But yes, I agree. There is no point in realizing the PPS twice when you dicipline the OCXO anyways, and the time-difference is never measured by a TIC, the GPS solution gives the time-error and the PPS only need re-assignment when it is too big. Cheers, Magnus From magnus at rubidium.dyndns.org Wed Jan 21 21:07:09 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 21 Jan 2009 22:07:09 +0100 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <49777A74.30203@xtra.co.nz> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <4976ACF7.3070807@xtra.co.nz> <7F834998A6DC45AB8744C56D8BDED245@pc52> <4976DF05.1030606@rubidium.dyndns.org> <49777A74.30203@xtra.co.nz> Message-ID: <49778E7D.5010803@rubidium.dyndns.org> Bruce Griffiths skrev: > Hej Magnus > > Magnus Danielson wrote: >> Tom, >> >> Tom Van Baak skrev: >> >>> Ah, OK. So you keep the antenna connected and you keep the >>> GPS receiver in position hold mode, still receiving fixes. >>> >>> All you're doing is disabling the software disciplining algorithm. >>> That sounds like a good test. Let me try this too and see if I >>> agree with your conclusions. >>> >> We discussed this a little while back. I proposed a three-cornered hat >> using two receivers and one counter... as the Thunderbolts has a builtin >> TIC to GPS which can be logged. We also discussed just running a single >> Thunderbolt in holdover. Others had already tried that approach. Bruce >> and I discussed to some degree the effect of steering on the result. >> >> > > The 3 cornered hat technique only works well (even in the extended form > allowing finite correlations between the 3 sources) when the ADEV of the > sources being compared aren't too disparate. > Consequently this comparison will only work well for tau values in the > vicinity of the Allan intercepts which in turn will need to be not too > disparate. You already said this. I was only refering back so Tom would get the context. Cheers, Magnus From magnus at rubidium.dyndns.org Wed Jan 21 21:12:03 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Wed, 21 Jan 2009 22:12:03 +0100 Subject: [time-nuts] Wenzel Oscillator Repair In-Reply-To: References: Message-ID: <49778FA3.1000107@rubidium.dyndns.org> Joe, >> The pre-heating trick actually makes the big soldering iron rest most of > >> the time... >> >> We have boards with so much ground/power grids that it is really a >> headache to do without pre-heating, which is similar to the iron case >> soldering problem. >> >> So, doing it this way makes it go fast. > > I think we are talking about different things. For getting chips off a > big multilayer board, preheat plus hot air is a standard way to go, but we > are talking about how to unsolder a steel can with foam insulation within. > Slow heating to near soldering temperature is likely to yield a heap of > goo. Actually no, the physics behind it does not really change and he also did unsolder the endcap of a steel can for me in this fashion. No goo inside as a result. Worked very well. I expect to be able to use it once I am done inside. > The point of the torch method is to heat the can's solder seam up *fast*, > so the solder melts before the foam. Sure. But pre-heating and hot-air works too. Cheers, Magnus From jltran at worldnet.att.net Thu Jan 22 00:41:34 2009 From: jltran at worldnet.att.net (J. L. Trantham) Date: Wed, 21 Jan 2009 18:41:34 -0600 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <50D403A38069BF4196F41887738C03EE03350C@companyweb> Message-ID: <1CBCAC28B82F4DD58EF9C812586F92AB@S0028384766> I had a similar (but probably worse) failure of one of my Tbolt's. When I went back to turn it back on, there was no response on the software. Everything was a 'question'. The 10 MHz output was there but it never 'locked' as compared to my other GPSDO's (although it was EXTREMELY close) and there was no 1 PPS output. I suspect a power issue to the processor and GPS receiver but I have not had a chance to track it down so far. I did open the unit and 'sniffed around' but I did not see any obvious issue. My plan is to set up an operating Tbolt and the 'dead' unit, side by side, and start tracing levels and voltages. I would be very interested in anything you discover. Joe -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of VK3FGJM Sent: Wednesday, January 21, 2009 2:32 PM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Hi, Yes, I can see alarm status and changes when unplugging antenna etc. As mentioned the unit actually works, just no data certain displayed. Regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of n3izn at aol.com Sent: Thursday, 22 January 2009 3:55 AM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Did you select the right comm port? I power mine off a lot and it has always come back. -----Original Message----- From: VK3FGJM To: time-nuts at febo.com Sent: Wed, 21 Jan 2009 5:29 am Subject: [time-nuts] Tbolt monitor software Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From k1ggi at arrl.net Thu Jan 22 02:23:41 2009 From: k1ggi at arrl.net (Ed, k1ggi) Date: Wed, 21 Jan 2009 21:23:41 -0500 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <50D403A38069BF4196F41887738C03EE03350C@companyweb> References: <50D403A38069BF4196F41887738C03EE03350B@companyweb><8CB4A0032F9A9F2-EE8-3B4@webmail-me15.sysops.aol.com> <50D403A38069BF4196F41887738C03EE03350C@companyweb> Message-ID: <033801c97c38$73d63240$0a01a8c0@ATHLONXP1700> Sounds like the tbolt is not getting the queries from the pc and therefore the responses are absent, but the pc is getting the unsolicited info from the tbolt. A fault with pin 3 on the DE9 would do it, or something deeper that kills the pc-to-tbolt comms. Ed, k1ggi -----Original Message----- From: VK3FGJM [mailto:VK3FGJM at commtelns.com] Sent: Wednesday, January 21, 2009 3:32 PM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Hi, Yes, I can see alarm status and changes when unplugging antenna etc. As mentioned the unit actually works, just no data certain displayed. Regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of n3izn at aol.com Sent: Thursday, 22 January 2009 3:55 AM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Did you select the right comm port? I power mine off a lot and it has always come back. -----Original Message----- From: VK3FGJM To: time-nuts at febo.com Sent: Wed, 21 Jan 2009 5:29 am Subject: [time-nuts] Tbolt monitor software Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From df6jb at ulrich-bangert.de Thu Jan 22 09:24:16 2009 From: df6jb at ulrich-bangert.de (Ulrich Bangert) Date: Thu, 22 Jan 2009 10:24:16 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <4976DDB3.2030802@rubidium.dyndns.org> Message-ID: <1524F79A70C54BB196A274363156B731@athlon> Magnus, I am aware that you know a lot about these things. Nevertheless I believe you are starting a most dangerous discussion in the sense that you put some terms into question of which I believed that they have well been established. For that reason let me test where we agree and where not: Mr. Allan decided that for his new statistical measure the summation shall run over square(y(i+1)-y(i)) for frequency data and over square(x(i+2)-2*x(i+1)+(xi)) for phase data. Both in contrast to the standard deviation where the summation runs over squares of distances from the mean. This new variance was called "Allan variance" and its square root "Allan deviation" to honor Mr. Allan for his work. This variance/deviation has a certain "overlapping aspect" since a single y(i) or x(i) appears in multiple terms of the summation. Agreed? Both terms require that the elements with subsequent indices are spaced apart at the "Tau" for wich the computation shall be done. Considered a number of phase measurements spaced 1 s apart then the computation will run over square(x(i+2)-2*x(i+1)+(xi)) for Tau = 1 s. If you are going to compute for Tau = 2 s from the SAME data set you will have to use the "original" samples square(x(5)-2*x(3)+x(1)) for the first summand and square(x(7)-2*x(5)+x(3)) for the second summand and square(x(9)-2*x(7)+x(5)) for the third summand and so on. All indices are incremented by two between neighbour summands because the next summand is 2 s (or two original samples) apart from the current summand. Agreed? As we notice the summation leaves out a number of summands where the elements are also spaced 2 s apart, for example square(x(6)-2*x(4)+x(2)) or square(x(8)-2*x(6)+x(4)) If we use these additional terms in the summation the number of summands increases a lot and improves the confidence interval of the estimation, even though the added summands are NOT completely statistical independend from the original ones and therefore this measure shall be clearly distincted from the original Allan variance/deviation. The summation over the original terms plus the added terms delivers the "Overlapping Allan variance/deviation" in conjunction with a suitable normation factor. Agreed? Best regards Ulrich > -----Urspr?ngliche Nachricht----- > Von: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] Im Auftrag von Magnus Danielson > Gesendet: Mittwoch, 21. Januar 2009 09:33 > An: Discussion of precise time and frequency measurement > Betreff: [time-nuts] ADEV vs. OADEV > > > Hi! > > I have been quite surprised to see the abbreviation OADEV appear. I > assume that this means Overlapped Allan Deviation, but this > is confusing > since the Allan Deviation estimates already is overlapping. > However, I > have seen that some use a non-overlapping estimator, but this type of > estimator has an unwanted filtering effect and should not be used. > > If a distinction between these ADEV estimators should be > used, then the > standard (overlapping) estimator should continue to be called > ADEV and > the non-overlapping (back-to-back) could be called NOADEV ?r > whatever... > > I have done a fair amount of digging around many sources > around ADEV and > friends so I think I got it right. > > Unless someone can give a meaningful explanation and I really > expect a > good article detailing the difference and benefits... > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > and > follow the instructions there. > From magnus at rubidium.dyndns.org Thu Jan 22 09:56:49 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 22 Jan 2009 10:56:49 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <1524F79A70C54BB196A274363156B731@athlon> References: <1524F79A70C54BB196A274363156B731@athlon> Message-ID: <497842E1.8080306@rubidium.dyndns.org> Ulrich, Ulrich Bangert skrev: > Magnus, > > I am aware that you know a lot about these things. Nevertheless I > believe you are starting a most dangerous discussion in the sense that > you put some terms into question of which I believed that they have well > been established. I have only recently seen the OADEV being used where as I have seen countless articles on calculations of these without encountering them, so from my standpoint OADEV is not well established, which is why I raised the question in order to "shake the tree" to see what fruits that I have missed. > For that reason let me test where we agree and where > not: > > Mr. Allan decided that for his new statistical measure the summation > shall run over > > square(y(i+1)-y(i)) > > for frequency data and over > > square(x(i+2)-2*x(i+1)+(xi)) > > for phase data. Both in contrast to the standard deviation where the > summation runs over squares of distances from the mean. This new > variance was called "Allan variance" and its square root "Allan > deviation" to honor Mr. Allan for his work. This variance/deviation has > a certain "overlapping aspect" since a single y(i) or x(i) appears in > multiple terms of the summation. Agreed? Yes, yes.... Actually, what you describe is the estimator formulas rather than definition. This is also targeting the fine point that I am trying to make. It's not about the basic definition, but accepted convention to denote the estimators. > Both terms require that the elements with subsequent indices are spaced > apart at the "Tau" for wich the computation shall be done. Considered a > number of phase measurements spaced 1 s apart then the computation will > run over > > square(x(i+2)-2*x(i+1)+(xi)) > > for Tau = 1 s. If you are going to compute for Tau = 2 s from the SAME > data set you will have to use the "original" samples > > square(x(5)-2*x(3)+x(1)) > > for the first summand and > > square(x(7)-2*x(5)+x(3)) > > for the second summand and > > square(x(9)-2*x(7)+x(5)) > > for the third summand and so on. All indices are incremented by two > between neighbour summands because the next summand is 2 s (or two > original samples) apart from the current summand. Agreed? Yes, yes... > As we notice the summation leaves out a number of summands where the > elements are also spaced 2 s apart, for example > > square(x(6)-2*x(4)+x(2)) > > or > > square(x(8)-2*x(6)+x(4)) > > If we use these additional terms in the summation the number of summands > increases a lot and improves the confidence interval of the estimation, > even though the added summands are NOT completely statistical > independend from the original ones and therefore this measure shall be > clearly distincted from the original Allan variance/deviation. The > summation over the original terms plus the added terms delivers the > "Overlapping Allan variance/deviation" in conjunction with a suitable > normation factor. Agreed? Disagree. The estimator formulation that is classically used includes these "missed" tau0 steps that you claim that OAVAR/OADEV includes. This is my point. Somewhere along the line the established ADEV estimator became the OADEV estimator and another estimator took the ADEV place. This is what I oppose without a more detailed look at things. I agree that it changes the statistical properties in terms of confidence interval, but it also change the frequency dependence. The analysis on frequency dependency needs to be redone as I suspect they do not always agree. Cheers, Magnus From VK3FGJM at commtelns.com Thu Jan 22 10:06:14 2009 From: VK3FGJM at commtelns.com (VK3FGJM) Date: Thu, 22 Jan 2009 21:06:14 +1100 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <033801c97c38$73d63240$0a01a8c0@ATHLONXP1700> References: <50D403A38069BF4196F41887738C03EE03350B@companyweb><8CB4A0032F9A9F2-EE8-3B4@webmail-me15.sysops.aol.com><50D403A38069BF4196F41887738C03EE03350C@companyweb> <033801c97c38$73d63240$0a01a8c0@ATHLONXP1700> Message-ID: <50D403A38069BF4196F41887738C03EE07827D@companyweb> Hi Ed, Initially I felt that was the case, but after some brief RS-232 measurement and the ability to see the TX/RX LED radio buttons sync with TX and RX data on the serial activity Monitor at the bottom left corner, there is nothing wrong with the RS-232 lines. Does anyone have a later version of the Trimble Thunderbolt monitor program or any other thoughts? Kind regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Ed, k1ggi Sent: Thursday, 22 January 2009 1:24 PM To: 'Discussion of precise time and frequency measurement' Subject: Re: [time-nuts] Tbolt monitor software Sounds like the tbolt is not getting the queries from the pc and therefore the responses are absent, but the pc is getting the unsolicited info from the tbolt. A fault with pin 3 on the DE9 would do it, or something deeper that kills the pc-to-tbolt comms. Ed, k1ggi -----Original Message----- From: VK3FGJM [mailto:VK3FGJM at commtelns.com] Sent: Wednesday, January 21, 2009 3:32 PM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Hi, Yes, I can see alarm status and changes when unplugging antenna etc. As mentioned the unit actually works, just no data certain displayed. Regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of n3izn at aol.com Sent: Thursday, 22 January 2009 3:55 AM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Did you select the right comm port? I power mine off a lot and it has always come back. -----Original Message----- From: VK3FGJM To: time-nuts at febo.com Sent: Wed, 21 Jan 2009 5:29 am Subject: [time-nuts] Tbolt monitor software Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From df6jb at ulrich-bangert.de Thu Jan 22 10:50:19 2009 From: df6jb at ulrich-bangert.de (Ulrich Bangert) Date: Thu, 22 Jan 2009 11:50:19 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <497842E1.8080306@rubidium.dyndns.org> Message-ID: Magnus, > Actually, what you describe is the estimator formulas rather than > definition. This is also targeting the fine point that I am trying to > make. It's not about the basic definition, but accepted convention to > denote the estimators. I still do not understand the fine point! A estimator might have this property and that property and may perform this task good and another task bad, but at the basics we have a formula and if the formula is new or different from prior art then the thing needs an name of its own. In this sense the summation over square(y(i+1)-y(i)) is called the base of the "Allan variance/deviation" just for historical reasons. So the name is "Allen deviation" and it is defined by its formula. > Disagree. The estimator formulation that is classically used includes > these "missed" tau0 steps that you claim that OAVAR/OADEV > includes. This is my point. Somewhere along the line the established ADEV estimator > became the OADEV estimator and another estimator took the ADEV place. > This is what I oppose without a more detailed look at things. The OAVAR/OADEV has this name of its own BECAUSE it includes the summands that are missed by the original AVAR/ADEV so its needs an name of its own. >Somewhere along the line the established ADEV estimator became the OADEV estimator If you had said: "The currently established estimator for oscillator stability is the OADEV estimator" I would have perfectly agreed. However, ADEV does already point to a different thing, so to say "Today we call ADEV what was formerly called OADEV and what was formerly called ADEV now is also called different" is not excused with a certain sloppiness in language but simply wrong use of terms. Exactly this is the point why I said that the discussion is dangerous. This is not a change in paradigm this is a case of inaccurate use of scientifical terms. Best regards Ulrich > -----Ursprungliche Nachricht----- > Von: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] Im Auftrag von Magnus Danielson > Gesendet: Donnerstag, 22. Januar 2009 10:57 > An: Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] ADEV vs. OADEV > > > Ulrich, > > Ulrich Bangert skrev: > > Magnus, > > > > I am aware that you know a lot about these things. Nevertheless I > > believe you are starting a most dangerous discussion in the > sense that > > you put some terms into question of which I believed that they have > > well been established. > > I have only recently seen the OADEV being used where as I have seen > countless articles on calculations of these without > encountering them, > so from my standpoint OADEV is not well established, which is why I > raised the question in order to "shake the tree" to see what > fruits that > I have missed. > > > For that reason let me test where we agree and where > > not: > > > > Mr. Allan decided that for his new statistical measure the > summation > > shall run over > > > > square(y(i+1)-y(i)) > > > > for frequency data and over > > > > square(x(i+2)-2*x(i+1)+(xi)) > > > > for phase data. Both in contrast to the standard deviation > where the > > summation runs over squares of distances from the mean. This new > > variance was called "Allan variance" and its square root "Allan > > deviation" to honor Mr. Allan for his work. This variance/deviation > > has a certain "overlapping aspect" since a single y(i) or > x(i) appears > > in multiple terms of the summation. Agreed? > > Yes, yes.... > > Actually, what you describe is the estimator formulas rather than > definition. This is also targeting the fine point that I am trying to > make. It's not about the basic definition, but accepted convention to > denote the estimators. > > > Both terms require that the elements with subsequent indices are > > spaced apart at the "Tau" for wich the computation shall be done. > > Considered a number of phase measurements spaced 1 s apart then the > > computation will run over > > > > square(x(i+2)-2*x(i+1)+(xi)) > > > > for Tau = 1 s. If you are going to compute for Tau = 2 s > from the SAME > > data set you will have to use the "original" samples > > > > square(x(5)-2*x(3)+x(1)) > > > > for the first summand and > > > > square(x(7)-2*x(5)+x(3)) > > > > for the second summand and > > > > square(x(9)-2*x(7)+x(5)) > > > > for the third summand and so on. All indices are incremented by two > > between neighbour summands because the next summand is 2 s (or two > > original samples) apart from the current summand. Agreed? > > Yes, yes... > > > As we notice the summation leaves out a number of summands > where the > > elements are also spaced 2 s apart, for example > > > > square(x(6)-2*x(4)+x(2)) > > > > or > > > > square(x(8)-2*x(6)+x(4)) > > > > If we use these additional terms in the summation the number of > > summands increases a lot and improves the confidence > interval of the > > estimation, even though the added summands are NOT completely > > statistical independend from the original ones and therefore this > > measure shall be clearly distincted from the original Allan > > variance/deviation. The summation over the original terms plus the > > added terms delivers the "Overlapping Allan variance/deviation" in > > conjunction with a suitable normation factor. Agreed? > > Disagree. The estimator formulation that is classically used includes > these "missed" tau0 steps that you claim that OAVAR/OADEV > includes. This > is my point. Somewhere along the line the established ADEV estimator > became the OADEV estimator and another estimator took the ADEV place. > This is what I oppose without a more detailed look at things. > > I agree that it changes the statistical properties in terms of > confidence interval, but it also change the frequency dependence. The > analysis on frequency dependency needs to be redone as I > suspect they do > not always agree. > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > and > follow the instructions there. > From VK3FGJM at commtelns.com Thu Jan 22 11:13:26 2009 From: VK3FGJM at commtelns.com (VK3FGJM) Date: Thu, 22 Jan 2009 22:13:26 +1100 Subject: [time-nuts] Thunderbolt data issue Message-ID: <50D403A38069BF4196F41887738C03EE078281@companyweb> Hi All, To the group, for your interest, a dry solder joint on IC U18 MAX 232 at 5 V logic side caused my issue. Although RS-232 data went in, it did not reach CPU. My MAX 232 was badly soldered due to initial assembly had some discoloured IC pins and solder did not free flow. Completely removed IC, cleaned and reflowed. Thanks to those providing comment. Regards, Gerald VK3FGJM From bruce.griffiths at xtra.co.nz Thu Jan 22 11:40:15 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 00:40:15 +1300 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: References: Message-ID: <49785B1F.4070903@xtra.co.nz> Ulrich Bangert wrote: > Magnus, > > >> Actually, what you describe is the estimator formulas rather than >> definition. This is also targeting the fine point that I am trying to >> make. It's not about the basic definition, but accepted convention to >> denote the estimators. >> > > I still do not understand the fine point! A estimator might have this > property and that property and may perform this task good and another > task bad, but at the basics we have a formula and if the formula is new > or different from prior art then the thing needs an name of its own. In > this sense the summation over square(y(i+1)-y(i)) is called the base of > the "Allan variance/deviation" just for historical reasons. So the name > is "Allen deviation" and it is defined by its formula. > > >> Disagree. The estimator formulation that is classically used includes >> these "missed" tau0 steps that you claim that OAVAR/OADEV >> includes. This is my point. Somewhere along the line the established >> > ADEV estimator > >> became the OADEV estimator and another estimator took the ADEV place. >> This is what I oppose without a more detailed look at things. >> > > The OAVAR/OADEV has this name of its own BECAUSE it includes the > summands that are missed by the original AVAR/ADEV so its needs an name > of its own. > > >> Somewhere along the line the established ADEV estimator became the >> > OADEV estimator > > If you had said: "The currently established estimator for oscillator > stability is the OADEV estimator" I would have perfectly agreed. > However, ADEV does already point to a different thing, so to say "Today > we call ADEV what was formerly called OADEV and what was formerly called > ADEV now is also called different" is not excused with a certain > sloppiness in language but simply wrong use of terms. Exactly this is > the point why I said that the discussion is dangerous. This is not a > change in paradigm this is a case of inaccurate use of scientifical > terms. > > Best regards > Ulrich > > > > >> -----Ursprungliche Nachricht----- >> Von: time-nuts-bounces at febo.com >> [mailto:time-nuts-bounces at febo.com] Im Auftrag von Magnus Danielson >> Gesendet: Donnerstag, 22. Januar 2009 10:57 >> An: Discussion of precise time and frequency measurement >> Betreff: Re: [time-nuts] ADEV vs. OADEV >> >> >> Ulrich, >> >> Ulrich Bangert skrev: >> >>> Magnus, >>> >>> I am aware that you know a lot about these things. Nevertheless I >>> believe you are starting a most dangerous discussion in the >>> >> sense that >> >>> you put some terms into question of which I believed that they have >>> well been established. >>> >> I have only recently seen the OADEV being used where as I have seen >> countless articles on calculations of these without >> encountering them, >> so from my standpoint OADEV is not well established, which is why I >> raised the question in order to "shake the tree" to see what >> fruits that >> I have missed. >> >> >>> For that reason let me test where we agree and where >>> not: >>> >>> Mr. Allan decided that for his new statistical measure the >>> >> summation >> >>> shall run over >>> >>> square(y(i+1)-y(i)) >>> >>> for frequency data and over >>> >>> square(x(i+2)-2*x(i+1)+(xi)) >>> >>> for phase data. Both in contrast to the standard deviation >>> >> where the >> >>> summation runs over squares of distances from the mean. This new >>> variance was called "Allan variance" and its square root "Allan >>> deviation" to honor Mr. Allan for his work. This variance/deviation >>> has a certain "overlapping aspect" since a single y(i) or >>> >> x(i) appears >> >>> in multiple terms of the summation. Agreed? >>> >> Yes, yes.... >> >> Actually, what you describe is the estimator formulas rather than >> definition. This is also targeting the fine point that I am trying to >> make. It's not about the basic definition, but accepted convention to >> denote the estimators. >> >> >>> Both terms require that the elements with subsequent indices are >>> spaced apart at the "Tau" for wich the computation shall be done. >>> Considered a number of phase measurements spaced 1 s apart then the >>> computation will run over >>> >>> square(x(i+2)-2*x(i+1)+(xi)) >>> >>> for Tau = 1 s. If you are going to compute for Tau = 2 s >>> >> from the SAME >> >>> data set you will have to use the "original" samples >>> >>> square(x(5)-2*x(3)+x(1)) >>> >>> for the first summand and >>> >>> square(x(7)-2*x(5)+x(3)) >>> >>> for the second summand and >>> >>> square(x(9)-2*x(7)+x(5)) >>> >>> for the third summand and so on. All indices are incremented by two >>> between neighbour summands because the next summand is 2 s (or two >>> original samples) apart from the current summand. Agreed? >>> >> Yes, yes... >> >> >>> As we notice the summation leaves out a number of summands >>> >> where the >> >>> elements are also spaced 2 s apart, for example >>> >>> square(x(6)-2*x(4)+x(2)) >>> >>> or >>> >>> square(x(8)-2*x(6)+x(4)) >>> >>> If we use these additional terms in the summation the number of >>> summands increases a lot and improves the confidence >>> >> interval of the >> >>> estimation, even though the added summands are NOT completely >>> statistical independend from the original ones and therefore this >>> measure shall be clearly distincted from the original Allan >>> variance/deviation. The summation over the original terms plus the >>> added terms delivers the "Overlapping Allan variance/deviation" in >>> conjunction with a suitable normation factor. Agreed? >>> >> Disagree. The estimator formulation that is classically used includes >> these "missed" tau0 steps that you claim that OAVAR/OADEV >> includes. This >> is my point. Somewhere along the line the established ADEV estimator >> became the OADEV estimator and another estimator took the ADEV place. >> This is what I oppose without a more detailed look at things. >> >> I agree that it changes the statistical properties in terms of >> confidence interval, but it also change the frequency dependence. The >> analysis on frequency dependency needs to be redone as I >> suspect they do >> not always agree. >> >> Cheers, >> Magnus >> >> Ulrich. Magnus Perhaps the situation is best summarised in /NIST special Publication 1065/ (can be downloaded as 2220.pdf from NIST) wherein it is stated that ADEV, AVAR are often taken to mean the overlapped form of the Allan deviation at least in the US. The attached figure graphically illustrates the difference between the ordinary and the overlapped versions. Bruce -------------- next part -------------- A non-text attachment was scrubbed... Name: TQ9132.png Type: image/png Size: 50683 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090123/740e09b3/attachment-0001.png From magnus at rubidium.dyndns.org Thu Jan 22 11:53:11 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 22 Jan 2009 12:53:11 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: References: Message-ID: <49785E27.8020601@rubidium.dyndns.org> Ulrich, Ulrich Bangert skrev: > Magnus, > >> Actually, what you describe is the estimator formulas rather than >> definition. This is also targeting the fine point that I am trying to >> make. It's not about the basic definition, but accepted convention to >> denote the estimators. > > I still do not understand the fine point! A estimator might have this > property and that property and may perform this task good and another > task bad, but at the basics we have a formula and if the formula is new > or different from prior art then the thing needs an name of its own. This part we agree on, however, you fail to see that what I try to point out is that you seems to have the wrong reference to start with. What I am trying to say is that it seems that ADEV is being used to identify a different estimator than I have in my old material, including the articles collected in NIST TN1337, for instance "Time and Frequency (Time-Domain) Characterization, Estimation, and Prediction of Precision Clocks and Oscillators" by David W. Allan. http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf See page 4 and formulas 8 and 9. These are overlapping. > In this sense the summation over square(y(i+1)-y(i)) is called the base of > the "Allan variance/deviation" just for historical reasons. So the name > is "Allen deviation" and it is defined by its formula. A further reference would be the IEEE standard found in http://tf.nist.gov/timefreq/general/tn1337/Tn139.pdf This is also overlapping (from page 2): N-2m ___ 2 1 \ 2 sigma (tau) = ----------- > (x - 2x + x ) y 2 /___ i+2m i+m i 2(N-2m)tau i = 1 a non-interleaved variant would have to be written as (assuming that m divides N): N - - 2 m ___ m \ 2 ------------ > (x - 2x + x ) 2 /___ (i+2)m (i+1)m im 2(N-2m)tau i = 1 and these obviously isn't the same, the later form skips over samples not being a multiple of m. Also, it is still overlapping in the sense that samples is being re-used. >> Disagree. The estimator formulation that is classically used includes >> these "missed" tau0 steps that you claim that OAVAR/OADEV >> includes. This is my point. Somewhere along the line the established > ADEV estimator >> became the OADEV estimator and another estimator took the ADEV place. >> This is what I oppose without a more detailed look at things. > > The OAVAR/OADEV has this name of its own BECAUSE it includes the > summands that are missed by the original AVAR/ADEV so its needs an name > of its own. I deeply disagree, see my reference to early papers (I agree not original). Also, the standardised form is overlapping. This is the reason for me to react. >> Somewhere along the line the established ADEV estimator became the > OADEV estimator > > If you had said: "The currently established estimator for oscillator > stability is the OADEV estimator" I would have perfectly agreed. Well, that part was never what we disagreed on IMHO. > However, ADEV does already point to a different thing, so to say "Today > we call ADEV what was formerly called OADEV and what was formerly called > ADEV now is also called different" is not excused with a certain > sloppiness in language but simply wrong use of terms. Exactly this is > the point why I said that the discussion is dangerous. This is not a > change in paradigm this is a case of inaccurate use of scientifical > terms. Well, if we were doing a shift in interpretation I fully agree with you, but what I reacted on was due to a shift in interpretation as I experienced it and when looking at the old reference material (altought I have not had the time for an extensive search that I would feel confident with). The issue was that I detected the dangerous shift and I wanted to bring it up to bring it back on tracks, or at least learn something useful. I really kindly ask you or anyone else to bring forward articles describing the non-overlapping ADEV and help plotting out the issues. What has become standardised (and thus assumed accepted) as the ADEV estimator is overlappping unless you can point out that I have made a very deep misunderstanding of all those papers, in which case I would be happy to be corrected. Cheers, Magnus From magnus at rubidium.dyndns.org Thu Jan 22 12:24:16 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 22 Jan 2009 13:24:16 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <49785B1F.4070903@xtra.co.nz> References: <49785B1F.4070903@xtra.co.nz> Message-ID: <49786570.8090009@rubidium.dyndns.org> Bruce Griffiths skrev: > Ulrich. Magnus > > Perhaps the situation is best summarised in /NIST special Publication > 1065/ (can be downloaded as 2220.pdf > from NIST) wherein it > is stated that ADEV, AVAR are often taken to mean the overlapped form of > the Allan deviation at least in the US. This is an excellent contribution to the discussion as it details the "Original Allan variance" and "Overlapping Allan variance" and also has a special information box detailing that AVAR and ADEV used mainly (notice standards and much of the reference material) for the overlapping. It also shows the inability for the 2-sample variance (Original Allan variance) to create smooth and good curves. That the 2-sample variance existed and was the basis for Allan variance was know, but the overlapping formulation of the established AVAR and ADEV terms estimators is motivated and accepted for its improved precission was also known to me indirectly, in the sense that I saw they where not directly equivalent but saying the same thing, then I forgot about it until this mysterious OADEV/OAVAR came up recently. There is however a huge difference between the 2-sample variance being the original Allan variance and being AVAR. Here I tend to rely on standards set by IEEE and ITU-T as they establish a defined relationship and I suspect some wisedom was applied in the process. Which estimator is we best serviced by to get defined as AVAR? They chose the overlapping one and it has also been the most used in theoretical analysis to the best of my knowledge. The plots given in the NIST SP 1065 figure 8 is very descriptive on the difference. In the end, I think we must realize that there is a distinction between the 2 sigma (tau) y and AVAR(tau) The former is the Original Allan Variance where as the later is the Overlapping Allan Variance. It is easy to confuse the two. Maybe this is the fundamental problem and not the definitions themselfs. Cheers, Magnus From df6jb at ulrich-bangert.de Thu Jan 22 14:06:31 2009 From: df6jb at ulrich-bangert.de (Ulrich Bangert) Date: Thu, 22 Jan 2009 15:06:31 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <49785E27.8020601@rubidium.dyndns.org> Message-ID: <7C99E10E08554C78A1C35ABC619934AF@athlon> Magnus, the paper http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf is thought-provoking. Not that I would simply say that you are right, but because I dont't understand some things. > > N-2m > ___ > 2 1 \ 2 > sigma (tau) = ----------- > (x - 2x + x ) > y 2 /___ i+2m i+m i > 2(N-2m)tau i = 1 > > a non-interleaved variant would have to be written as > (assuming that m > divides N): > > N > - - 2 > m > ___ > m \ 2 > ------------ > (x - 2x + x ) > 2 /___ (i+2)m (i+1)m im > 2(N-2m)tau i = 1 No discussion about that, simply correct. However the note to figure 8 as well as the note to figure 9 cover the non-overlapping case. Indeed formulas (8) and (10) are overlapping and to me it is a bit kind of magic where they come from in regard to thise two notes. Do you agree to the fact that the ADEV for Tau = 2 s should be the same, regardless if computed from 1 s spaced phase data or from 2 s spaced phase data? Best regards Ulrich > -----Ursprungliche Nachricht----- > Von: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] Im Auftrag von Magnus Danielson > Gesendet: Donnerstag, 22. Januar 2009 12:53 > An: Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] ADEV vs. OADEV > > > Ulrich, > > Ulrich Bangert skrev: > > Magnus, > > > >> Actually, what you describe is the estimator formulas rather than > >> definition. This is also targeting the fine point that I > am trying to > >> make. It's not about the basic definition, but accepted > convention to > >> denote the estimators. > > > > I still do not understand the fine point! A estimator might > have this > > property and that property and may perform this task good > and another > > task bad, but at the basics we have a formula and if the formula is > > new or different from prior art then the thing needs an name of its > > own. > > This part we agree on, however, you fail to see that what I > try to point > out is that you seems to have the wrong reference to start > with. What I > am trying to say is that it seems that ADEV is being used to > identify a > different estimator than I have in my old material, including the > articles collected in NIST TN1337, for instance "Time and Frequency > (Time-Domain) Characterization, Estimation, and Prediction of > Precision > Clocks and Oscillators" by David W. Allan. > http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf > See page 4 and formulas 8 and 9. These are overlapping. > > > In this sense the summation over square(y(i+1)-y(i)) is called the > > base of the "Allan variance/deviation" just for historical > reasons. So > > the name is "Allen deviation" and it is defined by its formula. > > A further reference would be the IEEE standard found in > > http://tf.nist.gov/timefreq/general/tn1337/Tn139.pdf > > This is also overlapping (from page 2): > > N-2m > ___ > 2 1 \ 2 > sigma (tau) = ----------- > (x - 2x + x ) > y 2 /___ i+2m i+m i > 2(N-2m)tau i = 1 > > a non-interleaved variant would have to be written as > (assuming that m > divides N): > > N > - - 2 > m > ___ > m \ 2 > ------------ > (x - 2x + x ) > 2 /___ (i+2)m (i+1)m im > 2(N-2m)tau i = 1 > > and these obviously isn't the same, the later form skips over samples > not being a multiple of m. > > Also, it is still overlapping in the sense that samples is > being re-used. > > >> Disagree. The estimator formulation that is classically > used includes > >> these "missed" tau0 steps that you claim that OAVAR/OADEV > >> includes. This is my point. Somewhere along the line the > established > > ADEV estimator > >> became the OADEV estimator and another estimator took the > ADEV place. > >> This is what I oppose without a more detailed look at things. > > > > The OAVAR/OADEV has this name of its own BECAUSE it includes the > > summands that are missed by the original AVAR/ADEV so its needs an > > name of its own. > > I deeply disagree, see my reference to early papers (I agree not > original). Also, the standardised form is overlapping. > > This is the reason for me to react. > > >> Somewhere along the line the established ADEV estimator became the > > OADEV estimator > > > > If you had said: "The currently established estimator for > oscillator > > stability is the OADEV estimator" I would have perfectly agreed. > > Well, that part was never what we disagreed on IMHO. > > > However, ADEV does already point to a different thing, so to say > > "Today we call ADEV what was formerly called OADEV and what was > > formerly called ADEV now is also called different" is not > excused with > > a certain sloppiness in language but simply wrong use of terms. > > Exactly this is the point why I said that the discussion is > dangerous. > > This is not a change in paradigm this is a case of > inaccurate use of > > scientifical terms. > > Well, if we were doing a shift in interpretation I fully > agree with you, > but what I reacted on was due to a shift in interpretation as I > experienced it and when looking at the old reference material > (altought > I have not had the time for an extensive search that I would feel > confident with). The issue was that I detected the dangerous > shift and I > wanted to bring it up to bring it back on tracks, or at least learn > something useful. > > I really kindly ask you or anyone else to bring forward articles > describing the non-overlapping ADEV and help plotting out the issues. > What has become standardised (and thus assumed accepted) as the ADEV > estimator is overlappping unless you can point out that I have made a > very deep misunderstanding of all those papers, in which case > I would be > happy to be corrected. > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > and > follow the instructions there. > From tvb at LeapSecond.com Thu Jan 22 15:01:10 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Thu, 22 Jan 2009 07:01:10 -0800 Subject: [time-nuts] ADEV vs. OADEV References: <4976DDB3.2030802@rubidium.dyndns.org> Message-ID: <4086A19850F94D609977411F35B12E44@pc52> Hi Magnus, I've never seen it in print either but I coined the name when I wrote my ADEV tools. I've found a profound difference in the overlapping form of ADEV in many cases and so I use it a lot now -- especially when analyzing the effect of tides on precision pendulum clocks, or other periodic effects, such as cycling A/C or diurnal effects. However almost every technical paper in the past few decades uses the plain old textbook non-overlapping back-to-back ADEV so my software tools call the traditional calculation "ADEV" and I call the overlapped version "OADEV". An alternative was to use words "ADEV(normal)", ADEV(overlapped)" and "ADEV(modified)" but I chose the shorter ADEV, OADEV, and MDEV instead. "ADEV" and "MDEV" are already standard, and so "OADEV" seemed to fit. So far no one has been confused, but I can see your point. See the tool page, which includes source code: http://www.leapsecond.com/tools/adev1.htm /tvb ----- Original Message ----- From: "Magnus Danielson" To: "Discussion of precise time and frequency measurement" Sent: Wednesday, January 21, 2009 12:32 AM Subject: [time-nuts] ADEV vs. OADEV Hi! I have been quite surprised to see the abbreviation OADEV appear. I assume that this means Overlapped Allan Deviation, but this is confusing since the Allan Deviation estimates already is overlapping. However, I have seen that some use a non-overlapping estimator, but this type of estimator has an unwanted filtering effect and should not be used. If a distinction between these ADEV estimators should be used, then the standard (overlapping) estimator should continue to be called ADEV and the non-overlapping (back-to-back) could be called NOADEV ?r whatever... I have done a fair amount of digging around many sources around ADEV and friends so I think I got it right. Unless someone can give a meaningful explanation and I really expect a good article detailing the difference and benefits... Cheers, Magnus _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From dave.g0dja at tiscali.co.uk Thu Jan 22 16:15:54 2009 From: dave.g0dja at tiscali.co.uk (Dave Ackrill) Date: Thu, 22 Jan 2009 16:15:54 +0000 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <50D403A38069BF4196F41887738C03EE07827D@companyweb> References: <50D403A38069BF4196F41887738C03EE03350B@companyweb><8CB4A0032F9A9F2-EE8-3B4@webmail-me15.sysops.aol.com><50D403A38069BF4196F41887738C03EE03350C@companyweb> <033801c97c38$73d63240$0a01a8c0@ATHLONXP1700> <50D403A38069BF4196F41887738C03EE07827D@companyweb> Message-ID: <49789BBA.2060609@tiscali.co.uk> VK3FGJM wrote: > Hi Ed, > > Initially I felt that was the case, but after some brief RS-232 > measurement and the ability to see the TX/RX LED radio buttons sync with > TX and RX data on the serial activity Monitor at the bottom left corner, > there is nothing wrong with the RS-232 lines. > > Does anyone have a later version of the Trimble Thunderbolt monitor > program or any other thoughts? > > > > Have you tried using portmon to see what data is beeing sent and received? Of course, you would then need to either know what should be sent/received, or get a copy of someone elses results with a system that was working OK. Dave (G0DJA) From EWKehren at aol.com Thu Jan 22 18:02:51 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Thu, 22 Jan 2009 13:02:51 EST Subject: [time-nuts] Angus Message-ID: Thanks for your offer on the AD1861. I think I found some. Tried to answer you direct. Address was rejected. Thanks again. Bert **************Inauguration '09: Get complete coverage from the nation's capital. (http://news.aol.com/main/politics/inauguration?ncid=emlcntusnews00000003) From grant at ghengineering.co.uk Thu Jan 22 18:25:00 2009 From: grant at ghengineering.co.uk (Grant Hodgson) Date: Thu, 22 Jan 2009 18:25:00 +0000 Subject: [time-nuts] Tbolt with Palisade In-Reply-To: References: Message-ID: <4978B9FC.8000209@ghengineering.co.uk> The antenna will be mounted outside with a reasonably clear view to the horizon from east-south-west. But there are times when there could be a lot of RF in the area - I design and build high power VHF and UHF PAs, amongst other things, and one of the attractions of the quality GPS antennas is the fact that they have a built in filter. But I might try one of the cheap patch antennas as a start with a view to upgrading at some point in the future. regards Grant Nigel Wrote :- > > ----------------- > Hi Grant > > I think this really does depend on where you are, satellites in view etc, > and what level of performance you're actually looking for. > > I have a few different timing antennas but have found these don't give very > reliable reception indoors. > Until I can get these mounted outdoors I have been having good results on > various receivers using some small Trimble magnetic patch antennas, specified > 26dB gain, attached to a steel plate and sitting on a shelf inside a one level > timber framed house on the west coast of Scotland. > These came via a buy it now from the usual place at $21 for 10 about a year > ago. > > Driving a pair of Thunderbolts with these and comparing them with an HP > 53132A counter, either one as reference and the other as input, once locked I see > variations of just a few places around zero in the 10th decimal place. > I have used this test on any two units selected from four with consistent > results. > > Not a very scientific test perhaps, and nothing else measured, but as > regards frequency at least I don't think they're suffering too much from their > "lesser" antennas:-) > > regards > > Nigel > GM8PZR > > ------------------------------ From brooke at pacific.net Thu Jan 22 19:20:46 2009 From: brooke at pacific.net (Brooke Clarke) Date: Thu, 22 Jan 2009 11:20:46 -0800 Subject: [time-nuts] GPS Time to Year? Message-ID: <4978C70E.3030000@pacific.net> Hi: It's my understanding that the slowest time data from GPS is the 10 bit week number. How does a GPS receiver come up with the current Year? -- Have Fun, Brooke Clarke http://www.prc68.com From tvb at LeapSecond.com Thu Jan 22 21:06:43 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Thu, 22 Jan 2009 13:06:43 -0800 Subject: [time-nuts] GPS Time to Year? References: <4978C70E.3030000@pacific.net> Message-ID: > Hi: > > It's my understanding that the slowest time data from GPS is the 10 bit week > number. > How does a GPS receiver come up with the current Year? > > -- > Have Fun, > > Brooke Clarke Hi Brooke, Good question. You are correct that this 10-bit week number wraps once every 2^10=1024 weeks which is once about every 20 years. It's not the slowest GPS data, see below *. Other GPS fields also wrap (more quickly) in a binary way. Most wrist watches, for that matter, wrap 60 seconds, or 60 minutes, or 12 hours. Note: GPS week 0 started MJD 44244 = 1980-01-06 GPS week 0 (1024) started MJD 51412 = 1999-08-22 GPS week 0 (2048) starts MJD 58580 = 2019-04-07 GPS week 0 (3072) starts MJD 65748 = 2038-11-21 The ways GPS receivers come up with the current year are: 1) Since time moves forward only, the real year can't less than what the year was yesterday. So when a GPS receiver on, say, Sunday morning April 4, 2019 sees that the GPS week is now 0 while last night the week was 1023, the GPS receiver can be very sure that the year is still 2019 and not 1980 or 1999 or 2019. As long as a GPS receiver has NVRAM you're all set. 2) The real year can't be less than the year the GPS receiver was manufactured. If the firmware sees GPS week 491, is has the option to decide if that week means 0+491 (June 1989) or 1024+491 (January 2009) or 2048+491 (September 2028). With a +/- 10 year margin the GPS receiver can pick the correct one. On the other hand, those of us with boat anchor GPS receivers from August 1999 know that firmware isn't always perfect.' 3) The real year can be obtained from external sources. Many GPS receivers are now embedded into cell phone or internet-enabled devices so obtaining a hint at the current date is easy. One may even know the date&time well before the first GPS signal lock. 4) The real year can't have fewer leap seconds than the previous year. So if you see that the GPS week number is 0 and the UTC vs. TAI leap second count is around 20 seconds you know it's GPS week 0 and year 1980. If the leap second count is closer to 32 seconds you know it's GPS week 0(1024) and so year 1999. If the count is closer to, say, 44 seconds, then you can be safe that it's GPS week 0(2048), or year 2019. Not perfect, but it will work fine for our lifetimes and more. /tvb *) The 8-bit leap second number is slower, wrapping once every couple of hundred years. Note also that the new GPS data format allows for wider bit fields for this and other parameters. See also: http://leapsecond.com/notes/gpswnro.htm From imp at bsdimp.com Thu Jan 22 21:37:46 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu, 22 Jan 2009 14:37:46 -0700 (MST) Subject: [time-nuts] GPS Time to Year? In-Reply-To: References: <4978C70E.3030000@pacific.net> Message-ID: <20090122.143746.1359841257.imp@bsdimp.com> In message: "Tom Van Baak" writes: : > Hi: : > : > It's my understanding that the slowest time data from GPS is the 10 bit week : > number. : > How does a GPS receiver come up with the current Year? : > : > -- : > Have Fun, : > : > Brooke Clarke : : Hi Brooke, : : Good question. You are correct that this 10-bit week number : wraps once every 2^10=1024 weeks which is once about every : 20 years. It's not the slowest GPS data, see below *. : : Other GPS fields also wrap (more quickly) in a binary way. : Most wrist watches, for that matter, wrap 60 seconds, or 60 : minutes, or 12 hours. : : Note: : GPS week 0 started MJD 44244 = 1980-01-06 : GPS week 0 (1024) started MJD 51412 = 1999-08-22 : GPS week 0 (2048) starts MJD 58580 = 2019-04-07 : GPS week 0 (3072) starts MJD 65748 = 2038-11-21 : : The ways GPS receivers come up with the current year are: : : 1) Since time moves forward only, the real year can't less than : what the year was yesterday. So when a GPS receiver on, say, : Sunday morning April 4, 2019 sees that the GPS week is now 0 : while last night the week was 1023, the GPS receiver can be very : sure that the year is still 2019 and not 1980 or 1999 or 2019. As : long as a GPS receiver has NVRAM you're all set. That works. Even in the coldest of spares will have been on sometime in the last 20 years, which is all that's needed to make this work... : 2) The real year can't be less than the year the GPS receiver was : manufactured. If the firmware sees GPS week 491, is has the : option to decide if that week means 0+491 (June 1989) or 1024+491 : (January 2009) or 2048+491 (September 2028). With a +/- 10 year : margin the GPS receiver can pick the correct one. : : On the other hand, those of us with boat anchor GPS receivers from : August 1999 know that firmware isn't always perfect.' :) : 3) The real year can be obtained from external sources. Many GPS : receivers are now embedded into cell phone or internet-enabled : devices so obtaining a hint at the current date is easy. One may : even know the date&time well before the first GPS signal lock. That's cheating... : 4) The real year can't have fewer leap seconds than the previous : year. So if you see that the GPS week number is 0 and the UTC : vs. TAI leap second count is around 20 seconds you know it's : GPS week 0 and year 1980. If the leap second count is closer to : 32 seconds you know it's GPS week 0(1024) and so year 1999. : If the count is closer to, say, 44 seconds, then you can be safe : that it's GPS week 0(2048), or year 2019. Not perfect, but it will : work fine for our lifetimes and more. Yes. Assuming there's no huge acceleration of the earth... Possible, but very unlikely... And assuming that leap seconds continue... If they stop, it will be hard to know... But if they stop, I can imagine that we could use DUT1 that would have to be published... : *) The 8-bit leap second number is slower, wrapping once every : couple of hundred years. Note also that the new GPS data format : allows for wider bit fields for this and other parameters. See also: : http://leapsecond.com/notes/gpswnro.htm True... Warner From didier at cox.net Thu Jan 22 21:44:56 2009 From: didier at cox.net (Didier Juges) Date: Thu, 22 Jan 2009 15:44:56 -0600 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <50D403A38069BF4196F41887738C03EE03350C@companyweb> Message-ID: <9d05cc6a-1bf1-4298-9423-805343d4e7b6@fis-hts-01.cranecoelectronics.com> I had the same problem here, and as it has been indicated, in my case it was also the unidirectional connection (commands from the PC never made it to the TB, so some data that is not automatically put out never got to the PC). I had a bad pin on the serial port connector. Check your wiring and signal levels, from the PC to the TB. Didier KO4BB -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of VK3FGJM Sent: Wednesday, January 21, 2009 2:32 PM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Hi, Yes, I can see alarm status and changes when unplugging antenna etc. As mentioned the unit actually works, just no data certain displayed. Regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of n3izn at aol.com Sent: Thursday, 22 January 2009 3:55 AM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Did you select the right comm port? I power mine off a lot and it has always come back. -----Original Message----- From: VK3FGJM To: time-nuts at febo.com Sent: Wed, 21 Jan 2009 5:29 am Subject: [time-nuts] Tbolt monitor software Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From magnus at rubidium.dyndns.org Thu Jan 22 22:26:20 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Thu, 22 Jan 2009 23:26:20 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <4086A19850F94D609977411F35B12E44@pc52> References: <4976DDB3.2030802@rubidium.dyndns.org> <4086A19850F94D609977411F35B12E44@pc52> Message-ID: <4978F28C.9020806@rubidium.dyndns.org> Hi Tom, Tom Van Baak skrev: > Hi Magnus, > > I've never seen it in print either but I coined the name when I wrote > my ADEV tools. I've found a profound difference in the overlapping > form of ADEV in many cases and so I use it a lot now -- especially > when analyzing the effect of tides on precision pendulum clocks, or > other periodic effects, such as cycling A/C or diurnal effects. > > However almost every technical paper in the past few decades uses > the plain old textbook non-overlapping back-to-back ADEV so my > software tools call the traditional calculation "ADEV" and I call the > overlapped version "OADEV". > > An alternative was to use words "ADEV(normal)", ADEV(overlapped)" > and "ADEV(modified)" but I chose the shorter ADEV, OADEV, and > MDEV instead. "ADEV" and "MDEV" are already standard, and so > "OADEV" seemed to fit. So far no one has been confused, but I can > see your point. This at least explains the origin of the OADEV name. Many thanks. If you look at the NIST paper that Bruce gave a link for, it makes very clear that the overlapping Allan deviation/variance should be used and that the original Allan deviation/variance should only be used "when necessary". The original form allows for some useful reductions in computation as a form of "quick" processing could be made with factor 2 tau steps. > See the tool page, which includes source code: > http://www.leapsecond.com/tools/adev1.htm I will look at it again, as I recall I have looked at it earlier. Cheers, Magnus From danrae at verizon.net Thu Jan 22 22:32:15 2009 From: danrae at verizon.net (Dan Rae) Date: Thu, 22 Jan 2009 14:32:15 -0800 Subject: [time-nuts] -hp- 10811 repair (Thermistor) Message-ID: <4978F3EF.1090603@verizon.net> The 10811-60111 that came in my 5370B counter turned out to have an open circuit Thermistor in it. This is a "non-replaceable" part in theory. However, nothing to lose, I have successfully substituted a Digikey Part number: 317-1371 100 kOhm 1% Thermistor ( from Cantherm, part number: MF51B104F3950 ). I measured the resistance of it at the target oven temperature, working back from the selected value of R20 that was installed in mine, in this case 0 Ohms for 84C. In fact this thermistor must be very similar to the one used originally, since I only needed to use a value of 110 Ohms for R20 to get bridge balance, instead of the short that was in there previously. Good enough for me... Dan From bruce.griffiths at xtra.co.nz Thu Jan 22 22:48:52 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 11:48:52 +1300 Subject: [time-nuts] -hp- 10811 repair (Thermistor) In-Reply-To: <4978F3EF.1090603@verizon.net> References: <4978F3EF.1090603@verizon.net> Message-ID: <4978F7D4.9020900@xtra.co.nz> Dan Rae wrote: > The 10811-60111 that came in my 5370B counter turned out to have an open > circuit Thermistor in it. This is a "non-replaceable" part in theory. > > However, nothing to lose, I have successfully substituted a Digikey Part > number: 317-1371 100 kOhm 1% Thermistor ( from Cantherm, part number: > MF51B104F3950 ). > > I measured the resistance of it at the target oven temperature, working > back from the selected value of R20 that was installed in mine, in this > case 0 Ohms for 84C. In fact this thermistor must be very similar to > the one used originally, since I only needed to use a value of 110 Ohms > for R20 to get bridge balance, instead of the short that was in there > previously. > > Good enough for me... > > Dan > > Dan The real reasons that this part is labelled non replaceable are 1) its epoxied to the oven. 2) Setting R20 to the correct value actually requires plotting the OCXO frequency vs R20 and selecting R20 so that the OCXO frequency is located at the stationary point on the frequency vs R20 value plot. This requires a high resolution frequency measurement setup with a highly stable reference and takes considerable time as one has to allow the oven temperature to settle between adjustments to R20. Drift due to aging and ambient temperature changes limit the accuracy with which the OCXO turnover temperature can be achieved. Bruce From richard at karlquist.com Thu Jan 22 23:08:48 2009 From: richard at karlquist.com (Rick Karlquist) Date: Thu, 22 Jan 2009 15:08:48 -0800 (PST) Subject: [time-nuts] -hp- 10811 repair (Thermistor) In-Reply-To: <4978F7D4.9020900@xtra.co.nz> References: <4978F3EF.1090603@verizon.net> <4978F7D4.9020900@xtra.co.nz> Message-ID: <50087b0a1d14bfbdb50213a4b60a339a.squirrel@webmail.sonic.net> Bruce Griffiths wrote: >> > Dan > > The real reasons that this part is labelled non replaceable are > > 1) its epoxied to the oven. > > 2) Setting R20 to the correct value actually requires plotting the OCXO > frequency vs R20 and selecting R20 so that the OCXO frequency is located > at the stationary point on the frequency vs R20 value plot. This > requires a high resolution frequency measurement setup with a highly > stable reference and takes considerable time as one has to allow the > oven temperature to settle between adjustments to R20. Drift due to > aging and ambient temperature changes limit the accuracy with which the > OCXO turnover temperature can be achieved. > > Bruce That's news to me. AFAIK, the individual crystal has a known oven set point that is determined in the crystal fab. R20 is selected to achieve this set point. What Dan did is exactly right, IMHO. BTW, many 10811 crystals did not have a turnover temperature as you imply. They simply had a point of minimum (not zero) tempco where there was an inflection point (2nd derivative is zero) but 1st derivative is not zero. This is well established SC cut theory ("true" SC cuts, that is). The stability of the oven set point was quite adequate in terms of the overall 10811 error budget. Most the tempco is due to the electronics pulling the crystal, as detailed in my paper on the E1938 oscillator. When you install the new thermistor, try to duplicate the lead dress of the old one. That was supposed to mitigate against heat running up the leads and corrupting the thermistor. Rick Karlquist, N6RK R&D engineer, HP Santa Clara Division 1979-1998 From bruce.griffiths at xtra.co.nz Thu Jan 22 23:21:28 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 12:21:28 +1300 Subject: [time-nuts] -hp- 10811 repair (Thermistor) In-Reply-To: <50087b0a1d14bfbdb50213a4b60a339a.squirrel@webmail.sonic.net> References: <4978F3EF.1090603@verizon.net> <4978F7D4.9020900@xtra.co.nz> <50087b0a1d14bfbdb50213a4b60a339a.squirrel@webmail.sonic.net> Message-ID: <4978FF78.80104@xtra.co.nz> Rick Karlquist wrote: > Bruce Griffiths wrote: > >> Dan >> >> The real reasons that this part is labelled non replaceable are >> >> 1) its epoxied to the oven. >> >> 2) Setting R20 to the correct value actually requires plotting the OCXO >> frequency vs R20 and selecting R20 so that the OCXO frequency is located >> at the stationary point on the frequency vs R20 value plot. This >> requires a high resolution frequency measurement setup with a highly >> stable reference and takes considerable time as one has to allow the >> oven temperature to settle between adjustments to R20. Drift due to >> aging and ambient temperature changes limit the accuracy with which the >> OCXO turnover temperature can be achieved. >> >> Bruce >> > > That's news to me. AFAIK, the individual crystal has a known oven > set point that is determined in the crystal fab. R20 is selected > to achieve this set point. What Dan did is exactly right, IMHO. > BTW, many 10811 crystals did not have a turnover temperature as > you imply. They simply had a point of minimum (not zero) tempco > where there was an inflection point (2nd derivative is zero) > but 1st derivative is not zero. This is well established SC > cut theory ("true" SC cuts, that is). The stability of the oven > set point was quite adequate in terms of the overall 10811 error > budget. Most the tempco is due to the electronics pulling the > crystal, as detailed in my paper on the E1938 oscillator. > > When you install the new thermistor, try to duplicate the lead > dress of the old one. That was supposed to mitigate against > heat running up the leads and corrupting the thermistor. > > Rick Karlquist, N6RK > R&D engineer, HP Santa Clara Division 1979-1998 > > > > Rick Sorry, as soon as I posted the above, I realised I was actually referring to the older 10544A/B, etc., OCXOs which did require such an involved oven tuning procedure. Meanwhile, before posting a correction I was trying to find data on the oven setpoint temperature tolerance. The relevant HP Journal with an article on the HP10811A is: http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1981-03.pdf One concern is: How accurate does one' thermometer which one uses to calibrate the thermistor bridge setpoint have to be? Bruce From magnus at rubidium.dyndns.org Thu Jan 22 23:29:21 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 00:29:21 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <7C99E10E08554C78A1C35ABC619934AF@athlon> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> Message-ID: <49790151.3010005@rubidium.dyndns.org> Ulrich, Ulrich Bangert skrev: > Magnus, > > the paper http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf is > thought-provoking. Not that I would simply say that you are right, but > because I dont't understand some things. Well, I was taking on this thread in hope to spread some light and I was not sure who would learn what. I think I have learned a few things, but so far it seems my view on things have not changed significantly. I think I can explain some things. >> N-2m >> ___ >> 2 1 \ 2 >> sigma (tau) = ----------- > (x - 2x + x ) >> y 2 /___ i+2m i+m i >> 2(N-2m)tau i = 1 >> >> a non-interleaved variant would have to be written as >> (assuming that m >> divides N): >> >> N >> - - 2 >> m >> ___ >> m \ 2 >> ------------ > (x - 2x + x ) >> 2 /___ (i+2)m (i+1)m im >> 2(N-2m)tau i = 1 > > No discussion about that, simply correct. I thought we would agree on those things. > However the note to figure 8 as well as the note to figure 9 cover the > non-overlapping case. Indeed formulas (8) and (10) are overlapping and > to me it is a bit kind of magic where they come from in regard to thise > two notes. > > Do you agree to the fact that the ADEV for Tau = 2 s should be the same, > regardless if computed from 1 s spaced phase data or from 2 s spaced > phase data? In the ideal world... yes... but in the real world limits hits us differently. The definition only says that it is an average, not how an average should be formed over samples where tau != tau0. A straightforward interpretation will skip samples, but require a much longer sequence and we must recall it is just one of several estimators. Let's make this clear, there is no way to get the real Allan variation, we can only get estimates and choose among estimators. This becomes clear as one reads the Bregni book or look at the ITU-T G.810 standard (get it, it's available for free download as PDF from ITU). Now, with this in mind, the "Overlapping Allan Variance" was chosen as the estimator of choice for the AVAR(n*tau0), and for good reasons. One point of confusion is that AVAR(tau) should not be directly interpreted as Allan Variance in general, it is actually already defined and reserved to mean a chosen Allan Variance estimator. This is an important point when comparing oscillators and systems such as a standard for measuring oscillators or telecom standards. For other uses other estimators may be used, but for precision use the overlapped estimator has been chosen as it better uses the measurement series. So, to sum things up. You can't get the "propper" Allan variance. You can only make estimates. The "Original Allan Variance" is a one of many estimators but to attain good quality it needs a long time-series. The "Overlapping Allan Variance" is another estimator which has improved quality for a limitied time series as compared to the "Original Allan Variance". The terms AVAR and ADEV as specified in several standards denotes an estimator which is the overlapping estimator, not just any Allan variance estimator. Notice also that telecom standards require tau0 to be less than lowest tau, so tau/tau0 is always > 1 as this ensures quality and allows for the specified highpass filter of 10 Hz, which is also being debated as being meaningfull or harmfull (see Bregni). There is still a few lessons to learn on this, but thats about it I think. So no, 1 s data and 2 s data does not necessarily give the same result, it depends on which estimator you are using, because you will be using an estimator regardless of what you think is "right". Thus, if you feel "Original Allan variance" is right for you, you are in your right to use it, but it is not the "propper" one to use, and do not confuse it with AVAR which is a dedicated name for the "Overlapping Allan Variance". Cheers, Magnus From danrae at verizon.net Thu Jan 22 23:42:42 2009 From: danrae at verizon.net (Dan Rae) Date: Thu, 22 Jan 2009 15:42:42 -0800 Subject: [time-nuts] -hp- 10811 repair (Thermistor) In-Reply-To: <4978FF78.80104@xtra.co.nz> References: <4978F3EF.1090603@verizon.net> <4978F7D4.9020900@xtra.co.nz> <50087b0a1d14bfbdb50213a4b60a339a.squirrel@webmail.sonic.net> <4978FF78.80104@xtra.co.nz> Message-ID: <49790472.5030108@verizon.net> Bruce Griffiths wrote: > Meanwhile, before posting a correction I was trying to find data on the > oven setpoint temperature tolerance. > > The relevant HP Journal with an article on the HP10811A is: > http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1981-03.pdf > > One concern is: > How accurate does one' thermometer which one uses to calibrate the > thermistor bridge setpoint have to be? > > Bruce > > > Bruce, I'm guessing that since they quote values of R20 in the manual in intervals of 0.1 Degrees, that is how close they got. Except oddly enough for 83.9 and 84.0 degrees, which are the same, but shouldn't be, IMHO. I don't claim to have got that close in my thermistor tests, maybe 0.5 degrees using a lab type mercury thermometer. But my original point is still valid: I now have a working oven. In my case I will use an external reference for the 5370B so it is kind of not that important anyway... Dan From magnus at rubidium.dyndns.org Thu Jan 22 23:58:17 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 00:58:17 +0100 Subject: [time-nuts] GPS Time to Year? In-Reply-To: References: <4978C70E.3030000@pacific.net> Message-ID: <49790819.9030208@rubidium.dyndns.org> Tom Van Baak skrev: >> Hi: >> >> It's my understanding that the slowest time data from GPS is the 10 bit week >> number. >> How does a GPS receiver come up with the current Year? >> >> -- >> Have Fun, >> >> Brooke Clarke > > Hi Brooke, > > Good question. You are correct that this 10-bit week number > wraps once every 2^10=1024 weeks which is once about every > 20 years. It's not the slowest GPS data, see below *. > > Other GPS fields also wrap (more quickly) in a binary way. > Most wrist watches, for that matter, wrap 60 seconds, or 60 > minutes, or 12 hours. > > Note: > GPS week 0 started MJD 44244 = 1980-01-06 > GPS week 0 (1024) started MJD 51412 = 1999-08-22 > GPS week 0 (2048) starts MJD 58580 = 2019-04-07 > GPS week 0 (3072) starts MJD 65748 = 2038-11-21 > > The ways GPS receivers come up with the current year are: > > 1) Since time moves forward only, the real year can't less than > what the year was yesterday. So when a GPS receiver on, say, > Sunday morning April 4, 2019 sees that the GPS week is now 0 > while last night the week was 1023, the GPS receiver can be very > sure that the year is still 2019 and not 1980 or 1999 or 2019. As > long as a GPS receiver has NVRAM you're all set. > > 2) The real year can't be less than the year the GPS receiver was > manufactured. If the firmware sees GPS week 491, is has the > option to decide if that week means 0+491 (June 1989) or 1024+491 > (January 2009) or 2048+491 (September 2028). With a +/- 10 year > margin the GPS receiver can pick the correct one. > > On the other hand, those of us with boat anchor GPS receivers from > August 1999 know that firmware isn't always perfect.' > > 3) The real year can be obtained from external sources. Many GPS > receivers are now embedded into cell phone or internet-enabled > devices so obtaining a hint at the current date is easy. One may > even know the date&time well before the first GPS signal lock. > > 4) The real year can't have fewer leap seconds than the previous > year. So if you see that the GPS week number is 0 and the UTC > vs. TAI leap second count is around 20 seconds you know it's > GPS week 0 and year 1980. If the leap second count is closer to > 32 seconds you know it's GPS week 0(1024) and so year 1999. > If the count is closer to, say, 44 seconds, then you can be safe > that it's GPS week 0(2048), or year 2019. Not perfect, but it will > work fine for our lifetimes and more. You could use leap second counter as a rought estimate to get the right 1024 week interval. Naturally, if leap seconds is no longer inserted that would break that algorithm. I wonder if this hint have been used by any receivers.. :) You can also use a CMOS backed clock, which many receivers have or there is an external option for a backup battery. That hint is usually valid enought. Also, the CMOS clock can be maintained when running. Storing last seen leap second and week number along with date at time of storage in the CMOS backup memory could also be usefull. Cheers, Magnus From tvb at LeapSecond.com Fri Jan 23 00:02:23 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Thu, 22 Jan 2009 16:02:23 -0800 Subject: [time-nuts] ADEV vs. OADEV References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> Message-ID: <0735942778504E58ACC4F224DF54D6F1@pc52> > One point of confusion is that AVAR(tau) should not be directly > interpreted as Allan Variance in general, it is actually already defined > and reserved to mean a chosen Allan Variance estimator. This is an Sorry if I'm jumping into this thread late, but this statement confuses me. Since when is "AVAR" not simply short-hand for "Allan Variance"? Next you'll tell me SDEV isn't Standard Deviation because some self-important standards organization decided otherwise. /tvb From bruce.griffiths at xtra.co.nz Fri Jan 23 00:04:04 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 13:04:04 +1300 Subject: [time-nuts] -hp- 10811 repair (Thermistor) In-Reply-To: <49790472.5030108@verizon.net> References: <4978F3EF.1090603@verizon.net> <4978F7D4.9020900@xtra.co.nz> <50087b0a1d14bfbdb50213a4b60a339a.squirrel@webmail.sonic.net> <4978FF78.80104@xtra.co.nz> <49790472.5030108@verizon.net> Message-ID: <49790974.9010204@xtra.co.nz> Dan Rae wrote: > Bruce Griffiths wrote: > >> Meanwhile, before posting a correction I was trying to find data on the >> oven setpoint temperature tolerance. >> >> The relevant HP Journal with an article on the HP10811A is: >> http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1981-03.pdf >> >> One concern is: >> How accurate does one' thermometer which one uses to calibrate the >> thermistor bridge setpoint have to be? >> >> Bruce >> >> >> >> > Bruce, I'm guessing that since they quote values of R20 in the manual in > intervals of 0.1 Degrees, that is how close they got. Except oddly > enough for 83.9 and 84.0 degrees, which are the same, but shouldn't be, > IMHO. I don't claim to have got that close in my thermistor tests, > maybe 0.5 degrees using a lab type mercury thermometer. But my original > point is still valid: I now have a working oven. In my case I will use > an external reference for the 5370B so it is kind of not that important > anyway... > > Dan > > > Dan Achieving 0.1C accuracy with a mercury in glass thermometer can be tricky even with a calibrated one reading to 0.1C. Some of the problems are: 1) Thermometer calibration accuracy 2) Immersion length correction - the indicated temperature depends on the temperature distribution over the entire length of the glass column. The thermometer may or may not have been calibrated fully immersed 3) Glass column hystereisis - correction depends on thermal history and is smaller for some glass types than others. 4) Ensuring that the thermistor and the thermometer are at the same temperature - perhaps the most important as internal dissipation in the thermistor will raise its temperature above its ambient. Using a metal block immersed in a liquid with both the thermometer and the thermistor installed in wells within the metal block is one of the better ways. In many ways its easier to use a themometer with an electrical output such as a calibrated RTD, PRT or SPRT. Commonly available RTD s are capable of maintaining calibration to much better than 0.1C for very long periods if they aren't thermally abused. Another possibility is t use a noise thermometer as all one needs to do is measure the resistance and the resultant Johnson noise. No calibration is required other than determining the equivalent noise bandwidth of the measurement system. Bruce From bruce.griffiths at xtra.co.nz Fri Jan 23 00:10:06 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 13:10:06 +1300 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <0735942778504E58ACC4F224DF54D6F1@pc52> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52> Message-ID: <49790ADE.2050809@xtra.co.nz> Tom Van Baak wrote: >> One point of confusion is that AVAR(tau) should not be directly >> interpreted as Allan Variance in general, it is actually already defined >> and reserved to mean a chosen Allan Variance estimator. This is an >> > > Sorry if I'm jumping into this thread late, but this statement > confuses me. Since when is "AVAR" not simply short-hand > for "Allan Variance"? > > Next you'll tell me SDEV isn't Standard Deviation because some > self-important standards organization decided otherwise. > > /tvb > > > Tom Perhaps the real confusion is between the actual definition of the Allan variance etc, and the various estimators of the Allan variance etc. For example: The so called classical Allan variance is nothing more than an estimator of the Allan variance. The so called overlapped Allan variance is a better (more accurate) estimator of the Allan variance. Bruce From magnus at rubidium.dyndns.org Fri Jan 23 00:35:59 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 01:35:59 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <0735942778504E58ACC4F224DF54D6F1@pc52> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52> Message-ID: <497910EF.10505@rubidium.dyndns.org> Tom Van Baak skrev: >> One point of confusion is that AVAR(tau) should not be directly >> interpreted as Allan Variance in general, it is actually already defined >> and reserved to mean a chosen Allan Variance estimator. This is an > > Sorry if I'm jumping into this thread late, but this statement > confuses me. Feel free to join in... > Since when is "AVAR" not simply short-hand > for "Allan Variance"? Good question. My point being that yes... AVAR is a handy short-hand for Allan Deviation, but it is also actually a standardised quantity and several standards actually define it consistently as a particular estimator. It's a good estimator for being of the Allan Variance family and CPU-cycles should not prohibit us from using it. Recall that they are all estimators. I think this is a crutial point to learn really. Once one has accepted that fact, then taking a look at which estimator serves me the best becomes the issue of interest, not "which is the right one?" which is actually an incorrect question in this context. So, feel free to short-hand Allan Variance as AVAR, but there are context in which this is going to be interpreted as being the overlapping Allan variance estimator and not any other estimator, and hence using that short-hand can be ambiguous. If we want an unambiguous use of AVAR, do not use AVAR as short-hand for Allan Variance when using other estimators than the overlapping one. Do as you please, but now you are aware of the issue. Also, look at the NIST SP 1065 for instance, where it is clearly indicated that the "original" is being superseded in most practical use for the benefit of the overlapping, giving improved confidence intervals. Also, Modified Allan Variance and Theo should be considered as better alternatives. The SP 1065 should be a good read for many, as it gives a modern overview and also addresses several practical implementational issues such as software test-sequences etc. The TN 1337 is a more classic view and collection of articles. So... we could argue all we want about "which is the correct Allan Variance" but it doesn't really help. The original estimator is flawed. the overlapping estimator improves confidence and the Theo family should provide even better results. > Next you'll tell me SDEV isn't Standard Deviation because some > self-important standards organization decided otherwise. I could probably find a standard defining it to something completely different and totally out of context which would not help. But the reaction is natural, but one must realize that there is not real "right" here, so sometimes putting down the foot and say "this is what we define it to be" is needed so that everyone at least do it according to the same procedures and with known errors... until you realize that you need something better and move over to some other measurement which you define in a similar fashion. It's like say the meter standard. "This is the meter... until we say something different". Cheers, Magnus From richard at karlquist.com Fri Jan 23 00:37:29 2009 From: richard at karlquist.com (Rick Karlquist) Date: Thu, 22 Jan 2009 16:37:29 -0800 (PST) Subject: [time-nuts] -hp- 10811 repair (Thermistor) In-Reply-To: <4978FF78.80104@xtra.co.nz> References: <4978F3EF.1090603@verizon.net> <4978F7D4.9020900@xtra.co.nz> <50087b0a1d14bfbdb50213a4b60a339a.squirrel@webmail.sonic.net> <4978FF78.80104@xtra.co.nz> Message-ID: <88aaaa3ca68bc18249e0c56c50f8ac39.squirrel@webmail.sonic.net> Bruce Griffiths wrote: >> One concern is: > How accurate does one' thermometer which one uses to calibrate the > thermistor bridge setpoint have to be? > > Bruce The thermistors HP used were quite accurate, so you didn't need a thermometer. You just calculated the correct resistor value for the temperature you wanted. The characterization of the crystals themselves was done in an oil bath with fairly precise thermometers, however, the accuracy only needed to be on the order of a degree C or so. This is because of the very broad peak, or plateau. It was easy to get the crystal temperature set correctly so that the electronics dominated. The fact that the electronics were not so great helped. Rick From VK3FGJM at commtelns.com Fri Jan 23 00:50:21 2009 From: VK3FGJM at commtelns.com (VK3FGJM) Date: Fri, 23 Jan 2009 11:50:21 +1100 Subject: [time-nuts] Tbolt monitor software In-Reply-To: <9d05cc6a-1bf1-4298-9423-805343d4e7b6@fis-hts-01.cranecoelectronics.com> References: <50D403A38069BF4196F41887738C03EE03350C@companyweb> <9d05cc6a-1bf1-4298-9423-805343d4e7b6@fis-hts-01.cranecoelectronics.com> Message-ID: <50D403A38069BF4196F41887738C03EE078307@companyweb> Hi Didier and others, Thanks for the feedback. Others Thunderbolt owners may want to check there soldering also. Prior to this error I has not opened the unit, did not see a need, although my symptom did not pop it's head up at first, to took some 4-5 months to manifest. As previously mentioned, it's now running perfect, but it required me to completely remove the MAX232, clean all pins and reflow. Regards Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Didier Juges Sent: Friday, 23 January 2009 8:45 AM To: 'Discussion of precise time and frequency measurement' Subject: Re: [time-nuts] Tbolt monitor software I had the same problem here, and as it has been indicated, in my case it was also the unidirectional connection (commands from the PC never made it to the TB, so some data that is not automatically put out never got to the PC). I had a bad pin on the serial port connector. Check your wiring and signal levels, from the PC to the TB. Didier KO4BB -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of VK3FGJM Sent: Wednesday, January 21, 2009 2:32 PM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Hi, Yes, I can see alarm status and changes when unplugging antenna etc. As mentioned the unit actually works, just no data certain displayed. Regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of n3izn at aol.com Sent: Thursday, 22 January 2009 3:55 AM To: time-nuts at febo.com Subject: Re: [time-nuts] Tbolt monitor software Did you select the right comm port? I power mine off a lot and it has always come back. -----Original Message----- From: VK3FGJM To: time-nuts at febo.com Sent: Wed, 21 Jan 2009 5:29 am Subject: [time-nuts] Tbolt monitor software Hi group, A strange situation has led me to ask a question about the Tbolt GPSDO and the Trimble Thunderbolt monitor s/w version 2.6. While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned off. After turning the unit on and letting it settle some 2 hour, I connected the monitor program and found the following that I can not explain and correct:- * All SV and AMU have question marks * Product info has questions marks * the ability to see tracking status is blank. When last used, some 2 months ago to show a friend, the relevant display data came up, no issues. Further more, position, critical and minor alarms are green, disciplining status section such as DAC voltage DAC value mode and even it's 10MHz out etc etc is fine compared to my trusty Rubidium standard. Has any one seen this before and is there a setting that may have inhibited this feature? I have a screen shot, however it may be to large to attach, so let me know if this will help, I will be glad to forward it to some one with much more knowledge. Thank you in advance. Regards, Gerald VK3FGJM _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From hmurray at megapathdsl.net Fri Jan 23 00:52:14 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 22 Jan 2009 16:52:14 -0800 Subject: [time-nuts] GPS Time to Year? In-Reply-To: Message from "Tom Van Baak" of "Thu, 22 Jan 2009 13:06:43 PST." Message-ID: <20090123005215.6FF23BCD8@ip-64-139-1-69.sjc.megapath.net> A nice list. Thanks. > One may even know the date&time well before the first GPS signal lock. Be careful with that one. Time is used for all sorts of things, some critical and some mostly a convenience. Time is often central in network security. That often turns into an interesting tangle. How do you securely set the time when your security stuff doesn't work yet because you don't know the time? Anyway, setting the time depending on the time that you already "know" has similar problems. It's probably a good approach, but may not be good enough. Where did you get that time from? Somebody has to think about the big picture and the costs/risks of getting it wrong. Another place where you can get a sanity check on the time is from the file system. If you are running an embedded application out of ROM/Flash or off a CD, that's the time of manufacturer. If you are running on an OS, it's probably the time some file was recently written, but that assumes the system time was correct. -- These are my opinions, not necessarily my employer's. I hate spam. From bruce.griffiths at xtra.co.nz Fri Jan 23 01:03:08 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 14:03:08 +1300 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <497910EF.10505@rubidium.dyndns.org> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52> <497910EF.10505@rubidium.dyndns.org> Message-ID: <4979174C.9050004@xtra.co.nz> Magnus Danielson wrote: > Tom Van Baak skrev: > >>> One point of confusion is that AVAR(tau) should not be directly >>> interpreted as Allan Variance in general, it is actually already defined >>> and reserved to mean a chosen Allan Variance estimator. This is an >>> >> Sorry if I'm jumping into this thread late, but this statement >> confuses me. >> > > Feel free to join in... > > >> Since when is "AVAR" not simply short-hand >> for "Allan Variance"? >> > > Good question. My point being that yes... AVAR is a handy short-hand for > Allan Deviation, but it is also actually a standardised quantity and > several standards actually define it consistently as a particular > estimator. It's a good estimator for being of the Allan Variance family > and CPU-cycles should not prohibit us from using it. > > Recall that they are all estimators. I think this is a crutial point to > learn really. Once one has accepted that fact, then taking a look at > which estimator serves me the best becomes the issue of interest, not > "which is the right one?" which is actually an incorrect question in > this context. > > So, feel free to short-hand Allan Variance as AVAR, but there are > context in which this is going to be interpreted as being the > overlapping Allan variance estimator and not any other estimator, and > hence using that short-hand can be ambiguous. If we want an unambiguous > use of AVAR, do not use AVAR as short-hand for Allan Variance when using > other estimators than the overlapping one. Do as you please, but now you > are aware of the issue. > > Also, look at the NIST SP 1065 for instance, where it is clearly > indicated that the "original" is being superseded in most practical use > for the benefit of the overlapping, giving improved confidence > intervals. Also, Modified Allan Variance and Theo should be considered > as better alternatives. > > The SP 1065 should be a good read for many, as it gives a modern > overview and also addresses several practical implementational issues > such as software test-sequences etc. The TN 1337 is a more classic view > and collection of articles. > > So... we could argue all we want about "which is the correct Allan > Variance" but it doesn't really help. The original estimator is flawed. > the overlapping estimator improves confidence and the Theo family should > provide even better results. > > >> Next you'll tell me SDEV isn't Standard Deviation because some >> self-important standards organization decided otherwise. >> > > I could probably find a standard defining it to something completely > different and totally out of context which would not help. > > But the reaction is natural, but one must realize that there is not real > "right" here, so sometimes putting down the foot and say "this is what > we define it to be" is needed so that everyone at least do it according > to the same procedures and with known errors... until you realize that > you need something better and move over to some other measurement which > you define in a similar fashion. It's like say the meter standard. "This > is the meter... until we say something different". > > Cheers, > Magnus > > Hej Magnus The major failing of SP1065 is that it doesn't explicitly make it clear that all the quantities for which its gives formulae are merely estimators of an underlying statistical property of the frequency source. For example using the terminology of SP1065: Classical AVAR Overlapped AVAR TOTVAR MTOT are all estimators of the Allan variance. They all have the same Expectation value but the confidence limits for each of these estimators are different. MVAR MTOT are both estimators of the Modified Allan variance. They both have the same Expectation value but the confidence limits for each of these estimators are different. Bruce From magnus at rubidium.dyndns.org Fri Jan 23 01:39:06 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 02:39:06 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <4979174C.9050004@xtra.co.nz> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52> <497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> Message-ID: <49791FBA.2050604@rubidium.dyndns.org> Hej Bruce, > Hej Magnus > > The major failing of SP1065 is that it doesn't explicitly make it clear > that all the quantities for which its gives formulae are merely > estimators of an underlying statistical property of the frequency source. I agree. Other sources is much more careful on this point. SP1065 gives a great overview, but should not be mistaken as a definite reference in all aspects. Bregni for instance presents the definitions in one place (Chapter 5) and estimators in another (Chapter 7). G.810 does the same for instance. It should be clear that the definition of Allan variance is actually not on two samples of frequency, they are measures of two average frequency measures, which implies an tau-long integral over v(t) for two end-to-end ranges. Using samples of frequency or samples of time is doing an estimation or approximation to the actual definition. I don't recall which paper wrote it, but it was pointed out that the average line over the y is often missed, but it you look in early papers these are found and uses, such as the tn121 paper i TN1337. It takes the reading of alot of papers and books to really make the picture stand out as subtle points is pointed out here and there. I just learned that J. J. Snyder is to take credit for the improved overlapped Allan variance estimator and that this became an inspiration for the modified Allan variation. > For example using the terminology of SP1065: > > Classical AVAR > Overlapped AVAR > TOTVAR > MTOT > > are all estimators of the Allan variance. You missed Theo1, just read the beginning of 5.2.15 and the info-box there. Then the followup is TheoH in 5.2.16. > They all have the same Expectation value but the confidence limits for > each of these estimators are different. > > MVAR > MTOT > > are both estimators of the Modified Allan variance. > They both have the same Expectation value but the confidence limits for > each of these estimators are different. Agree. In the end, while I have only very quickly browsed through the material and picked up some new, I feel it is time to read it through properly again. I think I have learned a few finer points in the last days and when seeing it with fresh eyes I think I will appreciate many of the comments better. Cheers, Magnus From tvb at LeapSecond.com Fri Jan 23 01:44:55 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Thu, 22 Jan 2009 17:44:55 -0800 Subject: [time-nuts] ADEV vs. OADEV References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52><497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> Message-ID: <32037539C46D47F4BF1C61D4996BC6F8@pc52> Yes, it is interesting that SP1065 uses words like: "original Allan" (page 2, 3, 14) "classic Allan variance" (page 11) "normal Allan variance" (page 16) as a way to distinguish the non- from the overlapping version. We could throw in "traditional", "simple", "back-to-back", "plain". I agree with the author (W.Riley) that these days ADEV is moving towards being interpreted, and more frequently implemented, as the overlapping variety, but that might take a generation to sink in. I mean, even his own Stable32 program calls the default 2-sample variance "Allan" and if you want the overlapped version you have to click on "Overlapping Allan". So you see why that Allan tool of mine labels the columns adev and oadev? At least there's no ambiguity that way. I should also point out that not all systems can calculate overlapping Allan statistics. Some realtime analyzers, even the fancy TSC boxes for example, cannot do full overlapping (because you need access to the entire data set for that). So plain adev is not dead yet. /tvb From bruce.griffiths at xtra.co.nz Fri Jan 23 01:46:08 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 14:46:08 +1300 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <4979174C.9050004@xtra.co.nz> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52> <497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> Message-ID: <49792160.5060807@xtra.co.nz> Bruce Griffiths wrote: > Magnus Danielson wrote: > >> Tom Van Baak skrev: >> >> >>>> One point of confusion is that AVAR(tau) should not be directly >>>> interpreted as Allan Variance in general, it is actually already defined >>>> and reserved to mean a chosen Allan Variance estimator. This is an >>>> >>>> >>> Sorry if I'm jumping into this thread late, but this statement >>> confuses me. >>> >>> >> Feel free to join in... >> >> >> >>> Since when is "AVAR" not simply short-hand >>> for "Allan Variance"? >>> >>> >> Good question. My point being that yes... AVAR is a handy short-hand for >> Allan Deviation, but it is also actually a standardised quantity and >> several standards actually define it consistently as a particular >> estimator. It's a good estimator for being of the Allan Variance family >> and CPU-cycles should not prohibit us from using it. >> >> Recall that they are all estimators. I think this is a crutial point to >> learn really. Once one has accepted that fact, then taking a look at >> which estimator serves me the best becomes the issue of interest, not >> "which is the right one?" which is actually an incorrect question in >> this context. >> >> So, feel free to short-hand Allan Variance as AVAR, but there are >> context in which this is going to be interpreted as being the >> overlapping Allan variance estimator and not any other estimator, and >> hence using that short-hand can be ambiguous. If we want an unambiguous >> use of AVAR, do not use AVAR as short-hand for Allan Variance when using >> other estimators than the overlapping one. Do as you please, but now you >> are aware of the issue. >> >> Also, look at the NIST SP 1065 for instance, where it is clearly >> indicated that the "original" is being superseded in most practical use >> for the benefit of the overlapping, giving improved confidence >> intervals. Also, Modified Allan Variance and Theo should be considered >> as better alternatives. >> >> The SP 1065 should be a good read for many, as it gives a modern >> overview and also addresses several practical implementational issues >> such as software test-sequences etc. The TN 1337 is a more classic view >> and collection of articles. >> >> So... we could argue all we want about "which is the correct Allan >> Variance" but it doesn't really help. The original estimator is flawed. >> the overlapping estimator improves confidence and the Theo family should >> provide even better results. >> >> >> >>> Next you'll tell me SDEV isn't Standard Deviation because some >>> self-important standards organization decided otherwise. >>> >>> >> I could probably find a standard defining it to something completely >> different and totally out of context which would not help. >> >> But the reaction is natural, but one must realize that there is not real >> "right" here, so sometimes putting down the foot and say "this is what >> we define it to be" is needed so that everyone at least do it according >> to the same procedures and with known errors... until you realize that >> you need something better and move over to some other measurement which >> you define in a similar fashion. It's like say the meter standard. "This >> is the meter... until we say something different". >> >> Cheers, >> Magnus >> >> >> > Hej Magnus > > The major failing of SP1065 is that it doesn't explicitly make it clear > that all the quantities for which its gives formulae are merely > estimators of an underlying statistical property of the frequency source. > > For example using the terminology of SP1065: > > Classical AVAR > Overlapped AVAR > TOTVAR > MTOT > > are all estimators of the Allan variance. > They all have the same Expectation value but the confidence limits for > each of these estimators are different. > > MVAR > MTOT > > are both estimators of the Modified Allan variance. > They both have the same Expectation value but the confidence limits for > each of these estimators are different. > > Bruce > > Addendum: There would appear to be only 3 underlying frequency stability statistics of interest in this paper: 1) Allan variance 2) Modified Allan variance 3) Hadamard variance Each of which has a different phase transfer function. All other statistical quantities related to frequency stability in this paper are actually estimators of one of the above underlying statistics Each estimator has different confidence limits and a different bias function which may depend on phase noise type. Correction for the underlying bias of each estimator is desirable before plotting the results. Confidence limits are also useful. Bruce From bruce.griffiths at xtra.co.nz Fri Jan 23 02:04:02 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 23 Jan 2009 15:04:02 +1300 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <32037539C46D47F4BF1C61D4996BC6F8@pc52> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52><497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> <32037539C46D47F4BF1C61D4996BC6F8@pc52> Message-ID: <49792592.8040806@xtra.co.nz> Tom Van Baak wrote: > Yes, it is interesting that SP1065 uses words like: > "original Allan" (page 2, 3, 14) > "classic Allan variance" (page 11) > "normal Allan variance" (page 16) > as a way to distinguish the non- from the overlapping version. > We could throw in "traditional", "simple", "back-to-back", "plain". > > I agree with the author (W.Riley) that these days ADEV is > moving towards being interpreted, and more frequently > implemented, as the overlapping variety, but that might take > a generation to sink in. > > I mean, even his own Stable32 program calls the default > 2-sample variance "Allan" and if you want the overlapped > version you have to click on "Overlapping Allan". > > So you see why that Allan tool of mine labels the columns > adev and oadev? At least there's no ambiguity that way. > > I should also point out that not all systems can calculate > overlapping Allan statistics. Some realtime analyzers, even > the fancy TSC boxes for example, cannot do full overlapping > (because you need access to the entire data set for that). > So plain adev is not dead yet. > > /tvb > > > Tom Its important to realise these calculated statistics are all estimators of the underlying Allan variance. Thus it is important to assign unique unambiguous names to each of them so that some idea of their region of reasonable accuracy and perhaps their confidence limits can be estimated. Thus for example: AVAR doesn't actually denote the underlying Allan variance but rather a particular algorithm used to estimate it from the data. OAVAR denotes another algorithm for estimating the underlying Allan variance from the data TOTVAR, THEO1 and THEOH denote other algorithms that can be used to estimate the underlying Allan variance from the data. Some of these algorithms produce biased estimates of the underlying Allan variance so correction for such bias is usually necessary. Bruce From magnus at rubidium.dyndns.org Fri Jan 23 02:18:38 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 03:18:38 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <32037539C46D47F4BF1C61D4996BC6F8@pc52> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52><497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> <32037539C46D47F4BF1C61D4996BC6F8@pc52> Message-ID: <497928FE.5000601@rubidium.dyndns.org> Tom Van Baak skrev: > Yes, it is interesting that SP1065 uses words like: > "original Allan" (page 2, 3, 14) > "classic Allan variance" (page 11) > "normal Allan variance" (page 16) > as a way to distinguish the non- from the overlapping version. > We could throw in "traditional", "simple", "back-to-back", "plain". Depending on the context of course. > I agree with the author (W.Riley) that these days ADEV is > moving towards being interpreted, and more frequently > implemented, as the overlapping variety, but that might take > a generation to sink in. Maybe. The J.J. Snyder article is from 1980 where as the Allan deviation is from 1966. It's only about half-a-generation. Maybe about the age difference of us two... > I mean, even his own Stable32 program calls the default > 2-sample variance "Allan" and if you want the overlapped > version you have to click on "Overlapping Allan". This could indicate where he is on the issue, but does not really resolve the question. > So you see why that Allan tool of mine labels the columns > adev and oadev? At least there's no ambiguity that way. That I agree with, in your context you certainly avoided ambiguity. > I should also point out that not all systems can calculate > overlapping Allan statistics. Some realtime analyzers, even > the fancy TSC boxes for example, cannot do full overlapping > (because you need access to the entire data set for that). > So plain adev is not dead yet. Actually... no. I have looked at this problem and you can calculate the overlapping Allan variance in real time with only the 2m tau of historic x values in memory. It is fairly trivial to implement out of the definition. You don't need the full data-set. However, you would need multiple accumulators for different choices of m. I can see how this might not is imminently apparent, but given the clues given I think it will become visible. The trickier part is to do drift rate compensation without having access to the full dataset. For Allan variance this is possible with a few tricks out of the statistics book. Using such an approach, you could see your AVAR/ADEV develop as the time series is consumed and be able to see how it stabilizes as you measure more and more. I think it is a rather pleasing approach. What I really need to learn is to calculate the confidence intervals. It keep nagging me all the time. Cheers, Magnus From magnus at rubidium.dyndns.org Fri Jan 23 02:26:49 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 03:26:49 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <49792592.8040806@xtra.co.nz> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52><497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> <32037539C46D47F4BF1C61D4996BC6F8@pc52> <49792592.8040806@xtra.co.nz> Message-ID: <49792AE9.6030505@rubidium.dyndns.org> Bruce, > Tom > > Its important to realise these calculated statistics are all estimators > of the underlying Allan variance. > Thus it is important to assign unique unambiguous names to each of them > so that some idea of their region of reasonable accuracy and perhaps > their confidence limits can be estimated. It should be recalled that AVAR is actually not necessarilly a name as such but short-hand. To help making the issue complex, AVAR has been given as a name to denote a particular algorithm, just as MADEV, TDEV etc. Even if one can argue that they have these meanings within a specific context, the ambiguity problem is there as it makes it harder to compare results. > Thus for example: > AVAR doesn't actually denote the underlying Allan variance but rather a > particular algorithm used to estimate it from the data. > > OAVAR denotes another algorithm for estimating the underlying Allan > variance from the data Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others have already denoted AVAR, thus causing ambiguity. > TOTVAR, THEO1 and THEOH denote other algorithms that can be used to > estimate the underlying Allan variance from the data. > > Some of these algorithms produce biased estimates of the underlying > Allan variance so correction for such bias is usually necessary. The way the confidence interval closes on the estimate should be of a concern. We can calculate whatever we want, but as we try to judge the results of such estimates we should also view the indicators of its precision if available. Cheers, Magnus From magnus at rubidium.dyndns.org Fri Jan 23 02:28:19 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 03:28:19 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <49792160.5060807@xtra.co.nz> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52> <497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> <49792160.5060807@xtra.co.nz> Message-ID: <49792B43.1010009@rubidium.dyndns.org> Bruce, Bruce Griffiths skrev: > Addendum: > > There would appear to be only 3 underlying frequency stability > statistics of interest in this paper: > > 1) Allan variance > > 2) Modified Allan variance > > 3) Hadamard variance > > Each of which has a different phase transfer function. > > All other statistical quantities related to frequency stability in this > paper are actually estimators of one of the above underlying statistics > Each estimator has different confidence limits and a different bias > function which may depend on phase noise type. > Correction for the underlying bias of each estimator is desirable before > plotting the results. > Confidence limits are also useful. I agree... very good points. Cheers, Magnus From tomknox at nist.gov Fri Jan 23 04:00:04 2009 From: tomknox at nist.gov (tomknox at nist.gov) Date: Thu, 22 Jan 2009 23:00:04 -0500 Subject: [time-nuts] Agilent 53132A Needs Help In-Reply-To: <1197596620.20090120204229@ostry.ru> References: <94B59D31CF9A49978777EB497CE354DE@RICK> <1197596620.20090120204229@ostry.ru> Message-ID: <20090122230004.10395e4xbu1m3a9w@webmail.nist.gov> Hi Yuri; I am late to this thread, but if you have not tried this, reseating the 4 or 2 eproms which are socketed near the rear may solve the problem. I am currently having the same problem with one of mine and in the past this have solved the problem on other units. Good Luck; Thomas Knox NIST 4475 Whitney Place Boulder Colorado 80305 1-303-554-0307 tomknox at nist.gov Quoting "Yuri Ostry" : > Hello, > > Tuesday, January 20, 2009, 17:26:00, Richard M. Hambly wrote: > > R> One of my 53132As, an Agilent unit, s/n KR01202209 fail the power-on self > R> test with a FAIL:ROM error message. > > Cannot say anything about your particular counter, but very often such > error is due to 'leaked' EPROM chip, that change value of some memory > cells over time. Last years I seen such problems 5 or 6 times with 15+ > years old equipment, and in most times original EPROM image still can > be read out if you have a EPROM programmer that allow to set arbitrary > Vcc for a chip in programming socket. > > Some background: Erased EPROM cell (actually small piece of > metallization between two layers of silicon oxide, acting both as a > capacitor and as a gate of MOSFET transistor on underlying layers) > reads as logical "one". When it is charged during programming, it > start read as "zero". > > If some cell have small defects in insulating oxide, or just got a hit > of some high energy particle, part of charge can be lost and > "programmed" bit that should read as "zero" starting to read as "one" > under normal conditions (nominal Vcc). > > There is a chance (very good chance, according to my own experience) > that you can find such "partially discharged" bits by lowering > (gradually) Vcc and saving read images to disk for further comparsion. > > Usually I start from 5.0V, make 10-20 reads, saving each one to > separate file in a 5V0 directory, then switch to 4.9V, and do the > same, saving to 4V9 directory, and so on... Usually it is enough to go > below to 4V0... > > When you analyze saved images later, first compare all files in each > directory to each other, you can find some bits that reads unstable at > given voltage. Then compare images between nearby voltages and if > there is any changes, it may be your "lost" zero bits. > > If you go too low, some EPROMS that was written before and then erased > to program current image may show you some of former programmed bits > as zeros - you need to be careful. There was some "erased" EPROM chips > that read as blank under 5V but read out their previous content (and > CRC perfectly match) when read out at Vcc little below 3.8V (not all > brands of EPROM operational at that voltage, though)... > > If there is a CRC on a EPROM label, it may be very useful in > determining that your recovered image is really good. Some devices do > CRC check on startup and you can feel yourself safe enough if checksum > error is gone. > > Always keep your original EPROM chip intact and do not expose it to a > UV or sunlight (if there is no label that cover their window) until > you are completely sure that you have correct image on hand. Use spare > EPROM of same type for experiments. > > > BTW: Looks like it is a good idea to have images of EPROMS and > calibration EEPROMs (if any) for all equipment in a safe place. > > -- > Best regards, > Yuri, UA3ATQ/KI7XJ mailto:yuri at ostry.ru > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From tvb at LeapSecond.com Fri Jan 23 05:23:47 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Thu, 22 Jan 2009 21:23:47 -0800 Subject: [time-nuts] ADEV vs. OADEV References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52><497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> <32037539C46D47F4BF1C61D4996BC6F8@pc52> <49792592.8040806@xtra.co.nz> <49792AE9.6030505@rubidium.dyndns.org> Message-ID: <345EE3843A0B4EE7A42394141E801E16@pc52> > Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others > have already denoted AVAR, thus causing ambiguity. One can equally say the algorithm you now want to call simply "AVAR" others long before you chose to call "overlapping AVAR" in order to clearly distinguish it from the pre-existing label that you no longer even want to call "AVAR". Personally I prefer to call it AVAR/ADEV when the implementation isn't relevant; and in those cases when it is, I specifically qualify the name with something like "normal" vs. "overlapping". That removes the ambiguity regardless of historical interpretation. We've beat this to death now and all understand the issues, yes? /tvb From df6jb at ulrich-bangert.de Fri Jan 23 09:03:06 2009 From: df6jb at ulrich-bangert.de (Ulrich Bangert) Date: Fri, 23 Jan 2009 10:03:06 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <497910EF.10505@rubidium.dyndns.org> Message-ID: Magnus, > So, feel free to short-hand Allan Variance as AVAR, but there are > context in which this is going to be interpreted as being the > overlapping Allan variance estimator and not any other estimator, and > hence using that short-hand can be ambiguous. Thanks for your insight! And to avoid this ambiguity a single char in front of AVAR like OAVAR and MAVAR serves pretty well. Best regards Ulrich > -----Ursprungliche Nachricht----- > Von: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] Im Auftrag von Magnus Danielson > Gesendet: Freitag, 23. Januar 2009 01:36 > An: Tom Van Baak; Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] ADEV vs. OADEV > > > Tom Van Baak skrev: > >> One point of confusion is that AVAR(tau) should not be directly > >> interpreted as Allan Variance in general, it is actually > already defined > >> and reserved to mean a chosen Allan Variance estimator. This is an > > > > Sorry if I'm jumping into this thread late, but this statement > > confuses me. > > Feel free to join in... > > > Since when is "AVAR" not simply short-hand > > for "Allan Variance"? > > Good question. My point being that yes... AVAR is a handy > short-hand for > Allan Deviation, but it is also actually a standardised quantity and > several standards actually define it consistently as a particular > estimator. It's a good estimator for being of the Allan > Variance family > and CPU-cycles should not prohibit us from using it. > > Recall that they are all estimators. I think this is a > crutial point to > learn really. Once one has accepted that fact, then taking a look at > which estimator serves me the best becomes the issue of interest, not > "which is the right one?" which is actually an incorrect question in > this context. > > So, feel free to short-hand Allan Variance as AVAR, but there are > context in which this is going to be interpreted as being the > overlapping Allan variance estimator and not any other estimator, and > hence using that short-hand can be ambiguous. If we want an > unambiguous > use of AVAR, do not use AVAR as short-hand for Allan Variance > when using > other estimators than the overlapping one. Do as you please, > but now you > are aware of the issue. > > Also, look at the NIST SP 1065 for instance, where it is clearly > indicated that the "original" is being superseded in most > practical use > for the benefit of the overlapping, giving improved confidence > intervals. Also, Modified Allan Variance and Theo should be > considered > as better alternatives. > > The SP 1065 should be a good read for many, as it gives a modern > overview and also addresses several practical implementational issues > such as software test-sequences etc. The TN 1337 is a more > classic view > and collection of articles. > > So... we could argue all we want about "which is the correct Allan > Variance" but it doesn't really help. The original estimator > is flawed. > the overlapping estimator improves confidence and the Theo > family should > provide even better results. > > > Next you'll tell me SDEV isn't Standard Deviation because some > > self-important standards organization decided otherwise. > > I could probably find a standard defining it to something completely > different and totally out of context which would not help. > > But the reaction is natural, but one must realize that there > is not real > "right" here, so sometimes putting down the foot and say > "this is what > we define it to be" is needed so that everyone at least do it > according > to the same procedures and with known errors... until you > realize that > you need something better and move over to some other > measurement which > you define in a similar fashion. It's like say the meter > standard. "This > is the meter... until we say something different". > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > and > follow the instructions there. > From magnus at rubidium.dyndns.org Fri Jan 23 09:03:57 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 23 Jan 2009 10:03:57 +0100 Subject: [time-nuts] ADEV vs. OADEV In-Reply-To: <345EE3843A0B4EE7A42394141E801E16@pc52> References: <7C99E10E08554C78A1C35ABC619934AF@athlon> <49790151.3010005@rubidium.dyndns.org> <0735942778504E58ACC4F224DF54D6F1@pc52><497910EF.10505@rubidium.dyndns.org> <4979174C.9050004@xtra.co.nz> <32037539C46D47F4BF1C61D4996BC6F8@pc52> <49792592.8040806@xtra.co.nz> <49792AE9.6030505@rubidium.dyndns.org> <345EE3843A0B4EE7A42394141E801E16@pc52> Message-ID: <497987FD.7060701@rubidium.dyndns.org> Tom Van Baak skrev: >> Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others >> have already denoted AVAR, thus causing ambiguity. > > One can equally say the algorithm you now want to call simply > "AVAR" others long before you chose to call "overlapping AVAR" > in order to clearly distinguish it from the pre-existing label that > you no longer even want to call "AVAR". I think you missed my point... I didn't want to call it that. I notice that it is already called AVAR. > Personally I prefer to call it AVAR/ADEV when the implementation > isn't relevant; and in those cases when it is, I specifically qualify > the name with something like "normal" vs. "overlapping". That > removes the ambiguity regardless of historical interpretation. This is a good resolution. I would rather prefer "normal" being replaced with "original" or something as the context would select which is the "normal" one, which is a subjective matter. The definition actually does not result in a particular algorithm (which popular beleif seems to imply), so one has to be carefull in putting judgement or preference in the prefix. > We've beat this to death now and all understand the issues, yes? I think this particular issue is beaten pretty dead by now. I at least picked up a few important lessons. I hope others did too. Cheers, Magnus From df6jb at ulrich-bangert.de Fri Jan 23 15:21:10 2009 From: df6jb at ulrich-bangert.de (Ulrich Bangert) Date: Fri, 23 Jan 2009 16:21:10 +0100 Subject: [time-nuts] What is the real source of the TBOLT's PPS output? Message-ID: <0DCD90C6C5E64F69A0B10043C3341038@athlon> Gents, considered an OCXO with an OAVAR of or better say 1.0E-11 @ 1 s (as used in the TBOLT) and a divider chain to generate an 1PPS from the 10 Mhz oscillator signal. What OAVAR @ 1 s would we expect if we compare the 10 MHz to the PPS derived from it? I know, the answer is not given easily, but: If the divider chain is engineered correctly (i.e. a synchronous and not a ripple divider) then we are basically comparing the 10 Mhz with a delayed version of itself. The delay will be the typical clock-to-output propagation delay of a d-flipflop of the dividers chain's semiconductor family. Since we are basically measuring the propagtion delay of a semiconductor I would expect to measure an OAVAR that is almost independend from the OAVAR of the 10 MHz clock and which is dominated by the jitter that is typical for this semiconductor family. In other words: I would rather expect to measure a LOWER OAVAR than to measure an OAVAR that is higher than that of the 10 MHz clock. Would I measure a SIGNIFICANT HIGHER OAVAR than that of the 10 MHz clock, this were an indication that the divider chain (beneath the delay introduced by it) would contribute a significant amount of instability to the PPS. I encourage you to perform such an comparing measurement on your TBOLT. Use the PPS output to start a TIC and the 10 MHz output to stop the TIC and record the results. I did so and received the results to be seen in TBOLT_External.PDF. @ 1 s the OAVAR is 3.3E-10 which is an almost unbelieveable bad value when one takes the 1.0E-11 @ 1 s of the 10 MHz clock into account. If THIS PPS were derived from the 10 MHz then Trimble's engineers had done a very bad job on the TBOLT. Which is not what I believe! But then: If it is NOT derived from the OCXO, where does it come from then? Is it perhaps the PPS coming from the receiver ??????? Well, considered that a high-grade implementation of an GPSDO with a M12+ may be able to produce a GPS PPS with an stability of 2.0E-9 @ 1 s (inclusive SAW-correction), then 3.3E-10 @ 1s were an incredible GOOD value for the TBOLT's receiver. Can that be????? This encouraged me to have a look again to the measurements that have been discussed in another thead: TBOLT-internal measurments as reported with the TBOLT monitor program. TBOLT_Internal.PDF shows the results of such an internal measurement while the TBOLT was in the disciplined state. @ 1 s we notice an OAVAR of 2.1E-10 which is even a tick better than the external measured 3.3E-10. This similarity makes me believe that what comes from the PPS output of the TBOLT is basically the GPS PPS and NOT ONE DERIVED FROM THE 10 MHZ. Unfortunately the manual makes no absolute clear statement about this question but there is one clue of which I believe it seconds my opinion. The manual says about the PPS: BNC Connector TTL levels into 50 ohm 10 microseconds-wide pulse with the leading edge synchronized to GPS or UTC within 20 nanoseconds (one sigma) in static, time-only mode. That is: The synchronisation of the PPS to GPS/UTS is dependend ONLY from the receiver's time-only working mode, nothing else, especially NOT from the state of the PLL controlling loop. If the PPS were derived from the 10 MHz, then everything described about the regulation loop, i.e. the whole PPS pulse shifting action to start with an low offset of +/- 50 ns with and the disciplining starting after that would lead IMHO at least SOMETIMES to effects that the internally generated PPS may be far without the window specified. If Trimble can specify this, it MUST be the true GPS PPS! On the other hand, if this were true we could turn off all our GPS receivers and instead supply every GPS-PPS that we need from the TBOLT, which should be better an factor of almost 10! Your opinions on that topic are welcome as always! Best regards Ulrich Bangert www.ulrich-bangert.de Ortholzer Weg 1 27243 Gross Ippener -------------- next part -------------- A non-text attachment was scrubbed... Name: TBOLT_External.pdf Type: application/pdf Size: 22562 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090123/5726ab0a/attachment-0002.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: TBOLT_Internal.pdf Type: application/pdf Size: 23058 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090123/5726ab0a/attachment-0003.pdf From bruce.griffiths at xtra.co.nz Fri Jan 23 21:37:21 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 24 Jan 2009 08:37:21 +1100 (EST) Subject: [time-nuts] What is the real source of the TBOLT's PPS output? References: <0DCD90C6C5E64F69A0B10043C3341038@athlon> Message-ID: <37461.76910.qm@web96115.mail.aue.yahoo.com> Ulrich The Thunderbolt manual makes it clear that the PPS output is divided down from the 10MHz OCXO output via the CPU and its support circuitry... If the CPU has an internal PLL and no external resynchronising flipflop, then it is possible that the rms PPS jitter may be as high as 300ps or so... A gate array with insufficient ground and Vcc pins could also have a similar output jitter. The jitter produced by whatever circuitry is used to shape the OCXO output into a logic level square wave can also contribute significant jitter if the signal amplitude is relatively low at the input to the shaper. The solution for your purposes is to use a resynchronising flipflop to remove this jitter before making your phase error measurements within your external OCXO discipling circuitry. Bruce ________________________________ From: Ulrich Bangert To: Time nuts Sent: Saturday, 24 January, 2009 4:21:10 AM Subject: [time-nuts] What is the real source of the TBOLT's PPS output? Gents, considered an OCXO with an OAVAR of or better say 1.0E-11 @ 1 s (as used in the TBOLT) and a divider chain to generate an 1PPS from the 10 Mhz oscillator signal. What OAVAR @ 1 s would we expect if we compare the 10 MHz to the PPS derived from it? I know, the answer is not given easily, but: If the divider chain is engineered correctly (i.e. a synchronous and not a ripple divider) then we are basically comparing the 10 Mhz with a delayed version of itself. The delay will be the typical clock-to-output propagation delay of a d-flipflop of the dividers chain's semiconductor family. Since we are basically measuring the propagtion delay of a semiconductor I would expect to measure an OAVAR that is almost independend from the OAVAR of the 10 MHz clock and which is dominated by the jitter that is typical for this semiconductor family. In other words: I would rather expect to measure a LOWER OAVAR than to measure an OAVAR that is higher than that of the 10 MHz clock. Would I measure a SIGNIFICANT HIGHER OAVAR than that of the 10 MHz clock, this were an indication that the divider chain (beneath the delay introduced by it) would contribute a significant amount of instability to the PPS. I encourage you to perform such an comparing measurement on your TBOLT. Use the PPS output to start a TIC and the 10 MHz output to stop the TIC and record the results. I did so and received the results to be seen in TBOLT_External.PDF. @ 1 s the OAVAR is 3.3E-10 which is an almost unbelieveable bad value when one takes the 1.0E-11 @ 1 s of the 10 MHz clock into account. If THIS PPS were derived from the 10 MHz then Trimble's engineers had done a very bad job on the TBOLT. Which is not what I believe! But then: If it is NOT derived from the OCXO, where does it come from then? Is it perhaps the PPS coming from the receiver ??????? Well, considered that a high-grade implementation of an GPSDO with a M12+ may be able to produce a GPS PPS with an stability of 2.0E-9 @ 1 s (inclusive SAW-correction), then 3.3E-10 @ 1s were an incredible GOOD value for the TBOLT's receiver. Can that be????? This encouraged me to have a look again to the measurements that have been discussed in another thead: TBOLT-internal measurments as reported with the TBOLT monitor program. TBOLT_Internal.PDF shows the results of such an internal measurement while the TBOLT was in the disciplined state. @ 1 s we notice an OAVAR of 2.1E-10 which is even a tick better than the external measured 3.3E-10. This similarity makes me believe that what comes from the PPS output of the TBOLT is basically the GPS PPS and NOT ONE DERIVED FROM THE 10 MHZ. Unfortunately the manual makes no absolute clear statement about this question but there is one clue of which I believe it seconds my opinion. The manual says about the PPS: BNC Connector TTL levels into 50 ohm 10 microseconds-wide pulse with the leading edge synchronized to GPS or UTC within 20 nanoseconds (one sigma) in static, time-only mode. That is: The synchronisation of the PPS to GPS/UTS is dependend ONLY from the receiver's time-only working mode, nothing else, especially NOT from the state of the PLL controlling loop. If the PPS were derived from the 10 MHz, then everything described about the regulation loop, i.e. the whole PPS pulse shifting action to start with an low offset of +/- 50 ns with and the disciplining starting after that would lead IMHO at least SOMETIMES to effects that the internally generated PPS may be far without the window specified. If Trimble can specify this, it MUST be the true GPS PPS! On the other hand, if this were true we could turn off all our GPS receivers and instead supply every GPS-PPS that we need from the TBOLT, which should be better an factor of almost 10! Your opinions on that topic are welcome as always! Best regards Ulrich Bangert www.ulrich-bangert.de Ortholzer Weg 1 27243 Gross Ippener From bruce.griffiths at xtra.co.nz Fri Jan 23 22:13:43 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 24 Jan 2009 11:13:43 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. Message-ID: <497A4117.9050705@xtra.co.nz> Tom Van Baak wrote: > Has anyone hacked a TBolt yet to find which internal pin has > a raw 1PPS from the GPS engine (as opposed to the 1PPS > divided down from the OCXO)? > > /tvb > > Tom The Thunderbolt manual (Page 1-1) makes it clear that there is no PPS output pin from the GPS receiver itself. There is also no internal TIC. The phase and frequency errors are derived from the sampled GPS signals without requiring an explicitly generated receiver PPS output. Bruce From bruce.griffiths at xtra.co.nz Sat Jan 24 00:26:45 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 24 Jan 2009 13:26:45 +1300 Subject: [time-nuts] What is the real source of the TBOLT's PPS output? In-Reply-To: <37461.76910.qm@web96115.mail.aue.yahoo.com> References: <0DCD90C6C5E64F69A0B10043C3341038@athlon> <37461.76910.qm@web96115.mail.aue.yahoo.com> Message-ID: <497A6045.9000907@xtra.co.nz> Bruce Griffiths wrote: > Ulrich > > The Thunderbolt manual makes it clear that the PPS output is divided down from the 10MHz OCXO output via the CPU and its support circuitry... > If the CPU has an internal PLL and no external resynchronising flipflop, then it is possible that the rms PPS jitter may be as high as 300ps or so... A gate array with insufficient ground and Vcc pins could also have a similar output jitter. The jitter produced by whatever circuitry is used to shape the OCXO output into a logic level square wave can also contribute significant jitter if the signal amplitude is relatively low at the input to the shaper. > > The solution for your purposes is to use a resynchronising flipflop to remove this jitter before making your phase error measurements within your external OCXO discipling circuitry. > > Bruce > > > Addendum: Are you using linear or switching power supplies to power the Thunderbolt? If you are using switching supplies, can you power it with linear supplies and measure the ADEV /jitter characteristics (PPS vs 10MHz)? Bruce > > ________________________________ > From: Ulrich Bangert > To: Time nuts > Sent: Saturday, 24 January, 2009 4:21:10 AM > Subject: [time-nuts] What is the real source of the TBOLT's PPS output? > > Gents, > > considered an OCXO with an OAVAR of or better say 1.0E-11 @ 1 s (as used > in the TBOLT) and a divider chain to generate an 1PPS from the 10 Mhz > oscillator signal. What OAVAR @ 1 s would we expect if we compare the 10 > MHz to the PPS derived from it? > > I know, the answer is not given easily, but: If the divider chain is > engineered correctly (i.e. a synchronous and not a ripple divider) then > we are basically comparing the 10 Mhz with a delayed version of itself. > The delay will be the typical clock-to-output propagation delay of a > d-flipflop of the dividers chain's semiconductor family. > > Since we are basically measuring the propagtion delay of a semiconductor > I would expect to measure an OAVAR that is almost independend from the > OAVAR of the 10 MHz clock and which is dominated by the jitter that is > typical for this semiconductor family. In other words: I would rather > expect to measure a LOWER OAVAR than to measure an OAVAR that is higher > than that of the 10 MHz clock. > > Would I measure a SIGNIFICANT HIGHER OAVAR than that of the 10 MHz > clock, this were an indication that the divider chain (beneath the delay > introduced by it) would contribute a significant amount of instability > to the PPS. I encourage you to perform such an comparing measurement on > your TBOLT. Use the PPS output to start a TIC and the 10 MHz output to > stop the TIC and record the results. > > I did so and received the results to be seen in TBOLT_External.PDF. @ 1 > s the OAVAR is 3.3E-10 which is an almost unbelieveable bad value when > one takes the 1.0E-11 @ 1 s of the 10 MHz clock into account. If THIS > PPS were derived from the 10 MHz then Trimble's engineers had done a > very bad job on the TBOLT. Which is not what I believe! But then: If it > is NOT derived from the OCXO, where does it come from then? > > Is it perhaps the PPS coming from the receiver ??????? Well, considered > that a high-grade implementation of an GPSDO with a M12+ may be able to > produce a GPS PPS with an stability of 2.0E-9 @ 1 s (inclusive > SAW-correction), then 3.3E-10 @ 1s were an incredible GOOD value for the > TBOLT's receiver. Can that be????? This encouraged me to have a look > again to the measurements that have been discussed in another thead: > TBOLT-internal measurments as reported with the TBOLT monitor program. > TBOLT_Internal.PDF shows the results of such an internal measurement > while the TBOLT was in the disciplined state. @ 1 s we notice an OAVAR > of 2.1E-10 which is even a tick better than the external measured > 3.3E-10. > > This similarity makes me believe that what comes from the PPS output of > the TBOLT is basically the GPS PPS and NOT ONE DERIVED FROM THE 10 MHZ. > Unfortunately the manual makes no absolute clear statement about this > question but there is one clue of which I believe it seconds my opinion. > > The manual says about the PPS: > > BNC Connector TTL levels into 50 ohm 10 microseconds-wide > pulse with the leading edge synchronized to GPS or UTC within > 20 nanoseconds (one sigma) in static, time-only mode. > > That is: The synchronisation of the PPS to GPS/UTS is dependend ONLY > from the receiver's time-only working mode, nothing else, especially NOT > from the state of the PLL controlling loop. If the PPS were derived from > the 10 MHz, then everything described about the regulation loop, i.e. > the whole PPS pulse shifting action to start with an low offset of +/- > 50 ns with and the disciplining starting after that would lead IMHO at > least SOMETIMES to effects that the internally generated PPS may be far > without the window specified. If Trimble can specify this, it MUST be > the true GPS PPS! > > On the other hand, if this were true we could turn off all our GPS > receivers and instead supply every GPS-PPS that we need from the TBOLT, > which should be better an factor of almost 10! > > Your opinions on that topic are welcome as always! > > Best regards > > Ulrich Bangert > www.ulrich-bangert.de > Ortholzer Weg 1 > 27243 Gross Ippener > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From magnus at rubidium.dyndns.org Sat Jan 24 01:56:05 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 24 Jan 2009 02:56:05 +0100 Subject: [time-nuts] What is the real source of the TBOLT's PPS output? In-Reply-To: <37461.76910.qm@web96115.mail.aue.yahoo.com> References: <0DCD90C6C5E64F69A0B10043C3341038@athlon> <37461.76910.qm@web96115.mail.aue.yahoo.com> Message-ID: <497A7535.4030807@rubidium.dyndns.org> Bruce Griffiths skrev: > Ulrich > > The Thunderbolt manual makes it clear that the PPS output is divided > down from the 10MHz OCXO output via the CPU and its support circuitry... The XC5202 is probably where the 10 MHz to PPS division takes place. I suspect it is also involved in the D/A conversion. Even a naive PWM-like approach to achieve 16 bit would give far higher sample rates than needed. > If the CPU has an internal PLL and no external resynchronising flipflop, > then it is possible that the rms PPS jitter may be as high as 300ps or so... > A gate array with insufficient ground and Vcc pins could also have a > similar output jitter. The jitter produced by whatever circuitry is used > to shape the OCXO output into a logic level square wave can also > contribute significant jitter if the signal amplitude is relatively low > at the input to the shaper. I did some probing around... The transistors sitting under the OCXO amplifies it and a logic gate converts it into CMOS levels. The CPU and correlator-chip has a 18,432 MHz clock which is locked to the 3,6864 MHz oscillator. It could be the same correlator chip used in the Lassen receiver or somewhat earlier. It is not clear from the material I have, but it kind of looks the same at least. It surely has a PPS on one of the pins which could be usefull to bootstrap the 10 MHz derived PPS. Anyway, the 18,432 MHz is a logical frequency as the 85th multiple will mix down to 8,7 MHz which is then probably sampled by 3,6864 to produce a sampled intermediary frequency of 1,332 MHz which is just what you want to hit the digital channels in a C/A correlator chip. This is the clock also being compared to the GPS. It could be that the 10 MHz is used to lock up the 3,6864 MHz clock. Not entierly impossible, but I am skeptic. But wait... the DFF sitting there (74AC174 has a nice little 9765,625 frequency humming about it. This is 10 MHz divided by 1024. However, it does not seems to lock up the 18,35 MHz (which is what I read off it...). > The solution for your purposes is to use a resynchronising flipflop to > remove this jitter before making your phase error measurements within > your external OCXO discipling circuitry. > > Bruce > > > > > ________________________________ > From: Ulrich Bangert > To: Time nuts > Sent: Saturday, 24 January, 2009 4:21:10 AM > Subject: [time-nuts] What is the real source of the TBOLT's PPS output? > > Gents, > > considered an OCXO with an OAVAR of or better say 1.0E-11 @ 1 s (as used > in the TBOLT) and a divider chain to generate an 1PPS from the 10 Mhz > oscillator signal. What OAVAR @ 1 s would we expect if we compare the 10 > MHz to the PPS derived from it? > > I know, the answer is not given easily, but: If the divider chain is > engineered correctly (i.e. a synchronous and not a ripple divider) then > we are basically comparing the 10 Mhz with a delayed version of itself. > The delay will be the typical clock-to-output propagation delay of a > d-flipflop of the dividers chain's semiconductor family. The DFFs available (74AC174) are clocked with the 10 MHz clock and I have a pair of 9765,625 Hz signals there. I need to dig around more. The Xilinx XC5202 has the 10 MHz on its clock input and outputs the divided down variant 9765,625 Hz and I suspect also the PPS even if it has not been located. The 74AC174 sits just next to it, so it is not impossible it is there for clean-up tasks. Cheers, Magnus From magnus at rubidium.dyndns.org Sat Jan 24 02:00:29 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 24 Jan 2009 03:00:29 +0100 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <497A4117.9050705@xtra.co.nz> References: <497A4117.9050705@xtra.co.nz> Message-ID: <497A763D.2080109@rubidium.dyndns.org> Bruce Griffiths skrev: > Tom Van Baak wrote: >> Has anyone hacked a TBolt yet to find which internal pin has >> a raw 1PPS from the GPS engine (as opposed to the 1PPS >> divided down from the OCXO)? >> >> /tvb >> >> > Tom > > The Thunderbolt manual (Page 1-1) makes it clear that there is no PPS > output pin from the GPS receiver itself. > There is also no internal TIC. > The phase and frequency errors are derived from the sampled GPS signals > without requiring an explicitly generated receiver PPS output. The Lassen LP receiver *seems* to be using the same correlator and processor chip and lacks the PPS, so it kind of make sense. The divided down signal does not seem to lock up the GPS chains oscillators (at least not when not seeing birds) but it could be that the signal is used as a time-reference so that the correlator chips internal timing can be coupled to the PPS state. Cheers, Magnus From bruce.griffiths at xtra.co.nz Sat Jan 24 02:21:27 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sat, 24 Jan 2009 15:21:27 +1300 Subject: [time-nuts] What is the real source of the TBOLT's PPS output? In-Reply-To: <497A7535.4030807@rubidium.dyndns.org> References: <0DCD90C6C5E64F69A0B10043C3341038@athlon> <37461.76910.qm@web96115.mail.aue.yahoo.com> <497A7535.4030807@rubidium.dyndns.org> Message-ID: <497A7B27.5070907@xtra.co.nz> Magnus Magnus Danielson wrote: > Bruce Griffiths skrev: > >> Ulrich >> >> The Thunderbolt manual makes it clear that the PPS output is divided >> down from the 10MHz OCXO output via the CPU and its support circuitry... >> > > The XC5202 is probably where the 10 MHz to PPS division takes place. I > suspect it is also involved in the D/A conversion. Even a naive PWM-like > approach to achieve 16 bit would give far higher sample rates than needed. > > >> If the CPU has an internal PLL and no external resynchronising flipflop, >> then it is possible that the rms PPS jitter may be as high as 300ps or so... >> A gate array with insufficient ground and Vcc pins could also have a >> similar output jitter. The jitter produced by whatever circuitry is used >> to shape the OCXO output into a logic level square wave can also >> contribute significant jitter if the signal amplitude is relatively low >> at the input to the shaper. >> > > I did some probing around... > > The transistors sitting under the OCXO amplifies it and a logic gate > converts it into CMOS levels. > > What is the signal amplitude at the input to this logic gate? If this signal is say 2V pp then as little as few tens of mV rms of supply noise on this logic gate may be enough to produce the observed jitter. I measure about 300ps rms (100 sample average) jitter of the PPS signal wrt the 10MHz signal zero crossing. However my Thunderbolt is powered by a switching power supply. Another potential source of noise is the OCXO power supplies, however this should largely cancel out when measuring the PPS to 10MHz jitter. > The CPU and correlator-chip has a 18,432 MHz clock which is locked to > the 3,6864 MHz oscillator. It could be the same correlator chip used in > the Lassen receiver or somewhat earlier. It is not clear from the > material I have, but it kind of looks the same at least. It surely has a > PPS on one of the pins which could be usefull to bootstrap the 10 MHz > derived PPS. > > Anyway, the 18,432 MHz is a logical frequency as the 85th multiple will > mix down to 8,7 MHz which is then probably sampled by 3,6864 to produce > a sampled intermediary frequency of 1,332 MHz which is just what you > want to hit the digital channels in a C/A correlator chip. > > This is the clock also being compared to the GPS. It could be that the > 10 MHz is used to lock up the 3,6864 MHz clock. Not entierly impossible, > but I am skeptic. But wait... the DFF sitting there (74AC174 has a nice > little 9765,625 frequency humming about it. This is 10 MHz divided by > 1024. However, it does not seems to lock up the 18,35 MHz (which is what > I read off it...). > > >> The solution for your purposes is to use a resynchronising flipflop to >> remove this jitter before making your phase error measurements within >> your external OCXO discipling circuitry. >> >> Bruce >> >> >> >> >> ________________________________ >> From: Ulrich Bangert >> To: Time nuts >> Sent: Saturday, 24 January, 2009 4:21:10 AM >> Subject: [time-nuts] What is the real source of the TBOLT's PPS output? >> >> Gents, >> >> considered an OCXO with an OAVAR of or better say 1.0E-11 @ 1 s (as used >> in the TBOLT) and a divider chain to generate an 1PPS from the 10 Mhz >> oscillator signal. What OAVAR @ 1 s would we expect if we compare the 10 >> MHz to the PPS derived from it? >> >> I know, the answer is not given easily, but: If the divider chain is >> engineered correctly (i.e. a synchronous and not a ripple divider) then >> we are basically comparing the 10 Mhz with a delayed version of itself. >> The delay will be the typical clock-to-output propagation delay of a >> d-flipflop of the dividers chain's semiconductor family. >> > > The DFFs available (74AC174) are clocked with the 10 MHz clock and I > have a pair of 9765,625 Hz signals there. I need to dig around more. > > The Xilinx XC5202 has the 10 MHz on its clock input and outputs the > divided down variant 9765,625 Hz and I suspect also the PPS even if it > has not been located. The 74AC174 sits just next to it, so it is not > impossible it is there for clean-up tasks. > > Cheers, > Magnus > > Bruce From jra at febo.com Sat Jan 24 15:42:22 2009 From: jra at febo.com (John Ackermann N8UR) Date: Sat, 24 Jan 2009 10:42:22 -0500 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? Message-ID: <497B36DE.9060904@febo.com> The temperature probes for the 2804A quartz thermometer seem primarily intended for liquid immersion. I'm looking for practical tips on how to couple the probe to a solid surface (e.g., a PC board) for accurate temperature measurements of the surface. Anyone know the best way to do this? Thanks, John From brooke at pacific.net Sat Jan 24 16:01:15 2009 From: brooke at pacific.net (Brooke Clarke) Date: Sat, 24 Jan 2009 08:01:15 -0800 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B36DE.9060904@febo.com> References: <497B36DE.9060904@febo.com> Message-ID: <497B3B4B.1070002@pacific.net> Hi John: Thermal Grease? Speaking of which, our projection TV had a major convergence problem caused by the failure of the responsible ICs (the ones with the huge heat sink). It(they) may have died because the old style (120) thermal grease degrades with time according to Wakefield. The newer 126 does not have that problem. http://www.prc68.com/I/HaT.shtml#60PP9202 waiting for the ICs to get here. Have Fun, Brooke Clarke http://www.prc68.com John Ackermann N8UR wrote: > The temperature probes for the 2804A quartz thermometer seem primarily > intended for liquid immersion. I'm looking for practical tips on how to > couple the probe to a solid surface (e.g., a PC board) for accurate > temperature measurements of the surface. > > Anyone know the best way to do this? > > Thanks, > > John > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From mfeher at eozinc.com Sat Jan 24 16:15:13 2009 From: mfeher at eozinc.com (Mike Feher) Date: Sat, 24 Jan 2009 11:15:13 -0500 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B36DE.9060904@febo.com> References: <497B36DE.9060904@febo.com> Message-ID: <850CFD67B3F242B5B8EF0E2431E7454E@gsmacdq14es> What type of accuracy are you looking for John? Mike B. Feher, N4FS 89 Arnold Blvd. Howell, NJ, 07731 732-886-5960 -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of John Ackermann N8UR Sent: Saturday, January 24, 2009 10:42 AM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? The temperature probes for the 2804A quartz thermometer seem primarily intended for liquid immersion. I'm looking for practical tips on how to couple the probe to a solid surface (e.g., a PC board) for accurate temperature measurements of the surface. Anyone know the best way to do this? Thanks, John _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From henk.termeer at gmail.com Sat Jan 24 16:16:41 2009 From: henk.termeer at gmail.com (Henk Termeer) Date: Sat, 24 Jan 2009 17:16:41 +0100 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B36DE.9060904@febo.com> References: <497B36DE.9060904@febo.com> Message-ID: <5323a8e30901240816g448cd8bj8ce16680c1b8e5a5@mail.gmail.com> Hello John, A temperature probe measures only it's own temperature, keep this in mint if you are using a probe. What I mean is this if you make contact to a solid warmer object, you will have a small contact surface, and a large prope to heath. Depending on the temperature difference you will get a huge error. Because the probe radiates energy to the enviroment, this gives a gradient on the probe so your quartz cristal will never get the same temperature as the object. This error can be anything between 0,1 and 5 degrees Celcius depending on the object temperature and the enviroment temperature and makes all the digits behind the afther the "," useless To minimize the error you can increase te contact area, lower the thermal resistance between the probe and the object, isolate the probe, etc. For surface temperature measurement, I think your probe is not the best solution, a thermocouple could be a better solution. The best thing is to make an error budget and see what is the best solution for your problem. Best regards, Henk PS maybe you can post a small photo or drawing of the object you want to measure On Sat, Jan 24, 2009 at 4:42 PM, John Ackermann N8UR wrote: > The temperature probes for the 2804A quartz thermometer seem primarily > intended for liquid immersion. I'm looking for practical tips on how to > couple the probe to a solid surface (e.g., a PC board) for accurate > temperature measurements of the surface. > > Anyone know the best way to do this? > > Thanks, > > John > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- ---------------------------------------------------------------------------------------------------- "Je hoeft het niet met elkaar eens te zijn om naar elkaar te luisteren." Ook van Loesje ---------------------------------------------------------------------------------------------------- From jra at febo.com Sat Jan 24 16:39:17 2009 From: jra at febo.com (John Ackermann N8UR) Date: Sat, 24 Jan 2009 11:39:17 -0500 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <850CFD67B3F242B5B8EF0E2431E7454E@gsmacdq14es> References: <497B36DE.9060904@febo.com> <850CFD67B3F242B5B8EF0E2431E7454E@gsmacdq14es> Message-ID: <497B4435.1090006@febo.com> The best I can get. This is time-nuts, after all. :-) I'm certainly not looking for the full millidegree accuracy of the thermometer, but have always been curious about heat transfer issues with thermometer probes and wondered if there were any tricks apart from laying the end of the probe horizontally on the board (maybe with the help of some thermal grease, as Brooke suggested). The challenge is the relatively small contact area between the circular probe and the flat board, and the corresponding fact that the majority of the probe's surface area is in contact with the ambient air rather than the surface of interest. John ---- Mike Feher said the following on 01/24/2009 11:15 AM: > What type of accuracy are you looking for John? > > > > Mike B. Feher, N4FS > 89 Arnold Blvd. > Howell, NJ, 07731 > 732-886-5960 > > > -----Original Message----- > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On > Behalf Of John Ackermann N8UR > Sent: Saturday, January 24, 2009 10:42 AM > To: Discussion of precise time and frequency measurement > Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? > > The temperature probes for the 2804A quartz thermometer seem primarily > intended for liquid immersion. I'm looking for practical tips on how to > couple the probe to a solid surface (e.g., a PC board) for accurate > temperature measurements of the surface. > > Anyone know the best way to do this? > > Thanks, > > John > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From dforbes at dakotacom.net Sat Jan 24 16:43:56 2009 From: dforbes at dakotacom.net (David Forbes) Date: Sat, 24 Jan 2009 09:43:56 -0700 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B36DE.9060904@febo.com> References: <497B36DE.9060904@febo.com> Message-ID: At 10:42 AM -0500 1/24/09, John Ackermann N8UR wrote: >The temperature probes for the 2804A quartz thermometer seem primarily >intended for liquid immersion. I'm looking for practical tips on how to >couple the probe to a solid surface (e.g., a PC board) for accurate >temperature measurements of the surface. > >Anyone know the best way to do this? > >Thanks, > >John John, What aspect of your measurement requires which amazing property of the HP temp probe? As others have said, matching the sensor to the thing to be measured is of prime importance. Therefore, using the HP crystal probe on a PC board is not an optimal solution. I had to do PC board temperature monitoring a few years ago, and found that I could get very good resolution with the Minco RTD sensors that come attached to a small piece of Kapton tape. http://www.minco.com/products/sensors.aspx?id=37 I used a National Instruments data acquisition system. The system was able to measure temperature changes down to about 0.01C with averaging. You would need to calibrate the sensors against a standard if you want accurate temperatures. They recommend an ice bath for that work. -- --David Forbes, Tucson, AZ http://www.cathodecorner.com/ From henk.termeer at gmail.com Sat Jan 24 16:58:11 2009 From: henk.termeer at gmail.com (Henk Termeer) Date: Sat, 24 Jan 2009 17:58:11 +0100 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B4435.1090006@febo.com> References: <497B36DE.9060904@febo.com> <850CFD67B3F242B5B8EF0E2431E7454E@gsmacdq14es> <497B4435.1090006@febo.com> Message-ID: <5323a8e30901240858w6d839c36u577357e929e37269@mail.gmail.com> Hello John, I have been searching for pictures and found this http://www.harlanlabs.com/2804a.jpg if you have a probe like this, no grease will help you. The quartz cristal is some where in the bulp on the end of the probe and is not in direct contact, just like a cristal for a osicillator (because it has to be able to move), so the thermal resistance between the bulp and the cristal is high. If you make contact to a pc board, you will measure something between the enviroment temperature and the board temperature, but you will never know what you measure most. This probe is excelent for calibration in liquits or gas but you have to insert it at least 20 cm. Best regards, Henk On Sat, Jan 24, 2009 at 5:39 PM, John Ackermann N8UR wrote: > The best I can get. This is time-nuts, after all. :-) > > I'm certainly not looking for the full millidegree accuracy of the > thermometer, but have always been curious about heat transfer issues > with thermometer probes and wondered if there were any tricks apart from > laying the end of the probe horizontally on the board (maybe with the > help of some thermal grease, as Brooke suggested). The challenge is the > relatively small contact area between the circular probe and the flat > board, and the corresponding fact that the majority of the probe's > surface area is in contact with the ambient air rather than the surface > of interest. > > John > ---- > > Mike Feher said the following on 01/24/2009 11:15 AM: > > What type of accuracy are you looking for John? > > > > > > > > Mike B. Feher, N4FS > > 89 Arnold Blvd. > > Howell, NJ, 07731 > > 732-886-5960 > > > > > > -----Original Message----- > > From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On > > Behalf Of John Ackermann N8UR > > Sent: Saturday, January 24, 2009 10:42 AM > > To: Discussion of precise time and frequency measurement > > Subject: [time-nuts] Any experienced HP 2804A thermometer users out > there? > > > > The temperature probes for the 2804A quartz thermometer seem primarily > > intended for liquid immersion. I'm looking for practical tips on how to > > couple the probe to a solid surface (e.g., a PC board) for accurate > > temperature measurements of the surface. > > > > Anyone know the best way to do this? > > > > Thanks, > > > > John > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- ---------------------------------------------------------------------------------------------------- "Je hoeft het niet met elkaar eens te zijn om naar elkaar te luisteren." Ook van Loesje ---------------------------------------------------------------------------------------------------- From jra at febo.com Sat Jan 24 17:09:51 2009 From: jra at febo.com (John Ackermann N8UR) Date: Sat, 24 Jan 2009 12:09:51 -0500 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: References: <497B36DE.9060904@febo.com> Message-ID: <497B4B5F.7090503@febo.com> David Forbes said the following on 01/24/2009 11:43 AM: > What aspect of your measurement requires which amazing property of > the HP temp probe? > > As others have said, matching the sensor to the thing to be measured > is of prime importance. Therefore, using the HP crystal probe on a PC > board is not an optimal solution. > > I had to do PC board temperature monitoring a few years ago, and > found that I could get very good resolution with the Minco RTD > sensors that come attached to a small piece of Kapton tape. > > http://www.minco.com/products/sensors.aspx?id=37 Dave, thanks for the pointer. That looks like it might be a good solution. I don't *need* the HP probe accuracy, but being a time-nut was curious to see how it might be used since I have one available (and having the GPIB interface with no voltage-to-temperature conversion required is also convenient). But something tiny that tapes onto the board is probably a much better solution in the real world. Thanks, John From jra at febo.com Sat Jan 24 17:15:21 2009 From: jra at febo.com (John Ackermann N8UR) Date: Sat, 24 Jan 2009 12:15:21 -0500 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <5323a8e30901240858w6d839c36u577357e929e37269@mail.gmail.com> References: <497B36DE.9060904@febo.com> <850CFD67B3F242B5B8EF0E2431E7454E@gsmacdq14es> <497B4435.1090006@febo.com> <5323a8e30901240858w6d839c36u577357e929e37269@mail.gmail.com> Message-ID: <497B4CA9.4030204@febo.com> The immersion depth does make a difference in ultimate accuracy, but 20cm is not required. Per the manual, for the probe I have available, the "immersion error" is 0.001 degree C at 9cm, and 0.01C for 3.5cm insertion. Of course, both are impractical for a surface measurement. This is clearly a case of picking the right tool for the job! John ---- Henk Termeer said the following on 01/24/2009 11:58 AM: > Hello John, > > I have been searching for pictures and found this > http://www.harlanlabs.com/2804a.jpg if you have a probe like this, no grease > will help you. > The quartz cristal is some where in the bulp on the end of the probe and is > not in direct contact, just like a cristal for a osicillator (because it has > to be able to move), so the thermal resistance between the bulp and the > cristal is high. If you make contact to a pc board, you will measure > something between the enviroment temperature and the board temperature, but > you will never know what you measure most. > This probe is excelent for calibration in liquits or gas but you have to > insert it at least 20 cm. > > Best regards, > > Henk > > On Sat, Jan 24, 2009 at 5:39 PM, John Ackermann N8UR wrote: > >> The best I can get. This is time-nuts, after all. :-) >> >> I'm certainly not looking for the full millidegree accuracy of the >> thermometer, but have always been curious about heat transfer issues >> with thermometer probes and wondered if there were any tricks apart from >> laying the end of the probe horizontally on the board (maybe with the >> help of some thermal grease, as Brooke suggested). The challenge is the >> relatively small contact area between the circular probe and the flat >> board, and the corresponding fact that the majority of the probe's >> surface area is in contact with the ambient air rather than the surface >> of interest. >> >> John >> ---- >> >> Mike Feher said the following on 01/24/2009 11:15 AM: >>> What type of accuracy are you looking for John? >>> >>> >>> >>> Mike B. Feher, N4FS >>> 89 Arnold Blvd. >>> Howell, NJ, 07731 >>> 732-886-5960 >>> >>> >>> -----Original Message----- >>> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On >>> Behalf Of John Ackermann N8UR >>> Sent: Saturday, January 24, 2009 10:42 AM >>> To: Discussion of precise time and frequency measurement >>> Subject: [time-nuts] Any experienced HP 2804A thermometer users out >> there? >>> The temperature probes for the 2804A quartz thermometer seem primarily >>> intended for liquid immersion. I'm looking for practical tips on how to >>> couple the probe to a solid surface (e.g., a PC board) for accurate >>> temperature measurements of the surface. >>> >>> Anyone know the best way to do this? >>> >>> Thanks, >>> >>> John >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > > From EWKehren at aol.com Sat Jan 24 17:19:14 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Sat, 24 Jan 2009 12:19:14 EST Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? Message-ID: John, looking at the 2804 manual they clearly only show applications where the probe is in a liquid environment. Reliable results can be expected if the probe is in a gas environment and has the time to stabilize but even than the full accuracy is not attainable because of the conductivity of the cable. The best result is with a physically very small sensor and than transfer the reading to the 2804 A by doing a calibration. I have used a YSI instrument with an analog scale and a analog output into a DVM but do not ask me if I was with in .1 degrees but it was not necessary. Some of the YSI probes have cables that are definitely there to reduce thermal conductivity to the sensor. Bert in Miami **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From phk at phk.freebsd.dk Sat Jan 24 17:37:47 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 24 Jan 2009 17:37:47 +0000 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: Your message of "Sat, 24 Jan 2009 09:43:56 MST." Message-ID: <17711.1232818667@critter.freebsd.dk> In message , David Forbes writes: >I had to do PC board temperature monitoring a few years ago, These days, nothing beat a thermal imager. I have the low-end "Satir Hotfind" camera and it makes it so much easier to spot any kind of thermal problems in electronics. Now, on the other hand, if we are talking about temperature control, then I would envy Johns HP2804A and would probably not bother with trying to measure the PCB temp, but instead plunk the entire thing and the probe into a suitable isolated oilbath :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From brooke at pacific.net Sat Jan 24 18:15:41 2009 From: brooke at pacific.net (Brooke Clarke) Date: Sat, 24 Jan 2009 10:15:41 -0800 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B36DE.9060904@febo.com> References: <497B36DE.9060904@febo.com> Message-ID: <497B5ACD.8020706@pacific.net> Hi John: I really like the Minco sensors that David suggested. They come in RTD, thermistor, thermocouple, etc. Thermistors are very sensitive to temperature changes. http://www.prc68.com/I/Sensors.shtml#Temperature Note that the equation for the resistance as a function of temperature contains exponential terms but the equation to go from resistance to temperature is linear after the natural log of the resistance is taken making it fairly easy to get the temperature. I used these with a computer program to get very accurate temperature readings. HP used to sell calibrated thermistors for about $50 each (good to AFAICR 1 deg c). Have Fun, Brooke Clarke http://www.prc68.com John Ackermann N8UR wrote: > The temperature probes for the 2804A quartz thermometer seem primarily > intended for liquid immersion. I'm looking for practical tips on how to > couple the probe to a solid surface (e.g., a PC board) for accurate > temperature measurements of the surface. > > Anyone know the best way to do this? > > Thanks, > > John > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From brooke at pacific.net Sat Jan 24 18:19:22 2009 From: brooke at pacific.net (Brooke Clarke) Date: Sat, 24 Jan 2009 10:19:22 -0800 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <17711.1232818667@critter.freebsd.dk> References: <17711.1232818667@critter.freebsd.dk> Message-ID: <497B5BAA.2020600@pacific.net> Hi Poul: I used a Barnes IR device that had a very small spot size (worked like a microscope) to try and measure the temperature of components on a board, but the emissivity varied all over the place so could not get temperatures unless everything was painted black. Especially hard to measure were devices in metal packages that were essentially mirrors. Have Fun, Brooke Clarke http://www.prc68.com Poul-Henning Kamp wrote: > In message , David Forbes writes: > >> I had to do PC board temperature monitoring a few years ago, > > These days, nothing beat a thermal imager. > > I have the low-end "Satir Hotfind" camera and it makes it so much > easier to spot any kind of thermal problems in electronics. > > > Now, on the other hand, if we are talking about temperature control, > then I would envy Johns HP2804A and would probably not bother with > trying to measure the PCB temp, but instead plunk the entire thing > and the probe into a suitable isolated oilbath :-) > From robert8rpi at yahoo.co.uk Sat Jan 24 19:05:40 2009 From: robert8rpi at yahoo.co.uk (Robert Atkinson) Date: Sat, 24 Jan 2009 19:05:40 +0000 (GMT) Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B36DE.9060904@febo.com> Message-ID: <783920.39471.qm@web27105.mail.ukl.yahoo.com> Hi John, Never used the 2804A, but agree with the other comments. Weller came up with an interesting probe to check soldering iron tips withot thermal loading. It is basically an iron with two sensors, one near the heater and one near the tip. These form a bridge which is balanced when there is no thermal "flow" into or out of the load. It might be possible to do something similar with the 2804A. Robert G8RPI. --- On Sat, 24/1/09, John Ackermann N8UR wrote: > From: John Ackermann N8UR > Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? > To: "Discussion of precise time and frequency measurement" > Date: Saturday, 24 January, 2009, 3:42 PM > The temperature probes for the 2804A quartz thermometer seem > primarily > intended for liquid immersion. I'm looking for > practical tips on how to > couple the probe to a solid surface (e.g., a PC board) for > accurate > temperature measurements of the surface. > > Anyone know the best way to do this? > > Thanks, > > John > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From cdelect at juno.com Sat Jan 24 19:10:00 2009 From: cdelect at juno.com (Corby Dawson) Date: Sat, 24 Jan 2009 11:10:00 -0800 Subject: [time-nuts] FTS 2000A oscillator pinout Message-ID: <20090124.111000.3280.0.cdelect@juno.com> Looking for the pinout of the FTS 2000A oscillator. I have a data sheet but no pinout. It was removed from an FTS 4050 or 4060. It has a db connector with 10 DC pins and one RF insert in the middle. At one time I had the pinout as I had replaced a 2000A in an FTS cesium with a 10811A. Unfortunately I can't find the data now and have a 2000A I want to checkout. Any help would be appreciated! Corby Dawson ____________________________________________________________ Come clean with a brand new shower. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw1wsglDSuGu7KmIamXMCd1J3bEnYjshp4EZYmzIMfAM8Iysx/ From henk.termeer at gmail.com Sat Jan 24 19:24:17 2009 From: henk.termeer at gmail.com (Henk Termeer) Date: Sat, 24 Jan 2009 20:24:17 +0100 Subject: [time-nuts] FTS 2000A oscillator pinout In-Reply-To: <20090124.111000.3280.0.cdelect@juno.com> References: <20090124.111000.3280.0.cdelect@juno.com> Message-ID: <5323a8e30901241124t97c03cclb0c6109022acdd12@mail.gmail.com> http://www.mail-archive.com/time-nuts at febo.com/msg13666.html On Sat, Jan 24, 2009 at 8:10 PM, Corby Dawson wrote: > Looking for the pinout of the FTS 2000A oscillator. > > I have a data sheet but no pinout. > > It was removed from an FTS 4050 or 4060. > > It has a db connector with 10 DC pins and one RF insert in the middle. > > At one time I had the pinout as I had replaced a 2000A in an FTS cesium > with a 10811A. > > Unfortunately I can't find the data now and have a 2000A I want to > checkout. > > Any help would be appreciated! > > Corby Dawson > ____________________________________________________________ > Come clean with a brand new shower. Click now! > > http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw1wsglDSuGu7KmIamXMCd1J3bEnYjshp4EZYmzIMfAM8Iysx/ > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- ---------------------------------------------------------------------------------------------------- "Je hoeft het niet met elkaar eens te zijn om naar elkaar te luisteren." Ook van Loesje ---------------------------------------------------------------------------------------------------- From didier at cox.net Sat Jan 24 19:34:47 2009 From: didier at cox.net (Didier) Date: Sat, 24 Jan 2009 13:34:47 -0600 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: <497B4B5F.7090503@febo.com> References: <497B36DE.9060904@febo.com> <497B4B5F.7090503@febo.com> Message-ID: John, The HP 3456A bench DMM can directly convert the reading from a specific 5k thermistor (HP 0837-1064) into degree C or F with significant resolution. I have not found the specification of the HP 0837-1064, but I have verified that around 25 degrees, using two 10k thermistors of the type I use in my projects (Murata NTSD1XH103FPB30, available from Digikey) in parallel gave really well matching results. Of course, away from 25 degrees, precision is not so good, even though repeatability and resolution are good, so it may be useful to make comparison or stability measurements. Using the NTSD1XH103FPB30 with a 12 bit ADC and a precision 10k resistor as the other end of the bridge gives you repeatable performance to 0.1 degree C (resolution around 25 C is 0.023 C) against a Fluke lab thermometer. I have not tried with a 5k nominal thermistor in the same series. The NTSD1XH103FPB30 thermistor is fairly small, but for best results, you want to use very small wires, at least for a short distance from the thermistor to reduce heat transfer through the wires. To make a general purpose sensor with the thermistor, I glue it inside the hollow part of a copper solder lug, and simply screw (or glue) the lug to the object to be measured. Didier KO4BB > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of John Ackermann N8UR > Sent: Saturday, January 24, 2009 11:10 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Any experienced HP 2804A thermometer > users outthere? > > David Forbes said the following on 01/24/2009 11:43 AM: > > > What aspect of your measurement requires which amazing > property of the > > HP temp probe? > > > > As others have said, matching the sensor to the thing to be > measured > > is of prime importance. Therefore, using the HP crystal > probe on a PC > > board is not an optimal solution. > > > > I had to do PC board temperature monitoring a few years > ago, and found > > that I could get very good resolution with the Minco RTD > sensors that > > come attached to a small piece of Kapton tape. > > > > http://www.minco.com/products/sensors.aspx?id=37 > > Dave, thanks for the pointer. That looks like it might be a > good solution. > > I don't *need* the HP probe accuracy, but being a time-nut > was curious to see how it might be used since I have one > available (and having the GPIB interface with no > voltage-to-temperature conversion required is also > convenient). But something tiny that tapes onto the board is > probably a much better solution in the real world. > > Thanks, > > John > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com To unsubscribe, > go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From phk at phk.freebsd.dk Sat Jan 24 19:48:14 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 24 Jan 2009 19:48:14 +0000 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: Your message of "Sat, 24 Jan 2009 13:34:47 CST." Message-ID: <19593.1232826494@critter.freebsd.dk> In message , "Didier" writes: For permanent measurement points, I prefer the Dallas DS18B20 1-wire sensors, they interface to a single I/O pin on anything programmable and gives 1/16?C resolution and +/- .5?C precision. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From didier at cox.net Sat Jan 24 21:24:09 2009 From: didier at cox.net (Didier) Date: Sat, 24 Jan 2009 15:24:09 -0600 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: <19593.1232826494@critter.freebsd.dk> References: Your message of "Sat, 24 Jan 2009 13:34:47 CST." <19593.1232826494@critter.freebsd.dk> Message-ID: <9FE35BF1051B413EAE492817D58EC095@didierhp> I have never used the 1-wire sensor, but I have actually used Thermochrons recorders from Dallas Semi, I still have some in equipment, and I have one in my car at the moment :-) But there are cases where there are too big, or they are in a noisy environment, and a thermistor is more flexible. Another advantage of the thermistor is the low overhead to make a reading. On most ucontrollers, the ADC runs under interrupts, so it does not take much resources to make a reading. It's only if you want to convert the reading in degrees that you have to run a linearization routine. For low precision needs, I just use an 8 bit lookup table. That gives precision better than a degree C around 25 C with very little CPU time. It's plenty for things like thermal protection or temperature compensation. The 18B20 is almost as small as a thermistor, but I do not have code for it. Can't be too hard though. Thanks for the pointer, Didier > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Poul-Henning Kamp > Sent: Saturday, January 24, 2009 1:48 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Any experienced HP 2804A thermometer > users outthere? > > In message , > "Didier" writes: > > For permanent measurement points, I prefer the Dallas DS18B20 > 1-wire sensors, they interface to a single I/O pin on > anything programmable and gives 1/160C resolution and +/- > .50C precision. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > > From phk at phk.freebsd.dk Sat Jan 24 21:26:59 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 24 Jan 2009 21:26:59 +0000 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: Your message of "Sat, 24 Jan 2009 15:24:09 CST." <9FE35BF1051B413EAE492817D58EC095@didierhp> Message-ID: <20104.1232832419@critter.freebsd.dk> In message <9FE35BF1051B413EAE492817D58EC095 at didierhp>, "Didier" writes: >But there are cases where there are too big, or they are in a noisy >environment, and a thermistor is more flexible. I seldom find TO-92 too big, in fact, I tend to find things smaller than TO-92 too small :-) >The 18B20 is almost as small as a thermistor, but I do not have code for it. >Can't be too hard though. I have some PIC18F code if you want it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From glennmaillist at bellsouth.net Sat Jan 24 21:42:51 2009 From: glennmaillist at bellsouth.net (Glenn Little WB4UIV) Date: Sat, 24 Jan 2009 16:42:51 -0500 Subject: [time-nuts] Motorola KXN1132AA Message-ID: <6.2.3.4.2.20090124163655.03c01d60@mail.bellsouth.net> Recently there was a post about oscillator stability and I thing drift over time. Was the large Motorola oscillator the one in the subject line? Further markings on the oscillator are source code 9896, Cust No 48R83851N02. This is a 5 MHz operating frequency oscillator. There are 8 lugs to interface the oscillator. Pin 4 is plus and pins 2 and 3 are negative. I think that this oscillator is an OCXO and works on 24VDC. Can this oscillator be disciplined? What are the other pins for? What is the oscillator accuracy? Thanks 73 Glenn WB4UIV From namichie at gmail.com Sat Jan 24 23:20:31 2009 From: namichie at gmail.com (Neville Michie) Date: Sun, 25 Jan 2009 10:20:31 +1100 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <783920.39471.qm@web27105.mail.ukl.yahoo.com> References: <783920.39471.qm@web27105.mail.ukl.yahoo.com> Message-ID: On 25/01/2009, at 6:05 AM, Robert Atkinson wrote: > Hi John, to measure a solid surface I would use a very thin copper/constantin thermo-couple and put the "cold " junction on your thermometer probe in an insulated shield. The "hot" junction goes on the part of the board to be measured. A microvolt DVM is needed to measure the thermocouple, a 1 microvolt difference is about .025 Kelvins. Here you get the lack of self heating of the thermocouple and very small down-lead conduction because of the thin wire, but you get the stability and accuracy of the quartz thermometer underpinning your measurement. There is a neat little quadratic that converts microvolts from the thermocouple to temperature difference. The main difficulty with using thermocouples is the accuracy of the cold junction and your quartz thermometer solves that problem. If you have doubts about your microvoltmeter you reverse the thermocouple connections to get twice the error difference. If you want more bang for your buck wire 5 thermocouples in series, insulate the junctions from each other, and use the composite junction on your board to get a resolution of 0.005 Kelvins,. The reversed polarity trick also works here to remove DVM offset. I know this is not using the quartz thermometer directly but it would be a very good way to measure a board to 1millikelvin. For theoretical reasons a thermocouple can not have a temperature offset. cheers, Neville Michie > --- On Sat, 24/1/09, John Ackermann N8UR wrote: > >> From: John Ackermann N8UR >> Subject: [time-nuts] Any experienced HP 2804A thermometer users >> out there? >> To: "Discussion of precise time and frequency measurement" > nuts at febo.com> >> Date: Saturday, 24 January, 2009, 3:42 PM >> The temperature probes for the 2804A quartz thermometer seem >> primarily >> intended for liquid immersion. I'm looking for >> practical tips on how to >> couple the probe to a solid surface (e.g., a PC board) for >> accurate >> temperature measurements of the surface. >> >> Anyone know the best way to do this? >> >> Thanks, >> >> John >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ > time-nuts > and follow the instructions there. From w1ksz at earthlink.net Sat Jan 24 23:34:41 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Sat, 24 Jan 2009 18:34:41 -0500 (EST) Subject: [time-nuts] Motorola KXN1132AA Message-ID: <6809470.1232840081403.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> If that came from a PURC, see if the GPS receiver is included. It may not as they used one receiver per site and slaved all the HSO's to it. Or, there may be a 14.4 MHz oscillator on board. Hopefully the 5 MHz oscillator was not purloined !! There are also some jumpers that allow you to set the reference input frequency (I think, I am only recalling from memory the MSF5000 HSO, which is similar, I think). 73, Dick, W1KSZ -----Original Message----- >From: Glenn Little WB4UIV >Sent: Jan 24, 2009 4:42 PM >To: Time-Nuts list >Subject: [time-nuts] Motorola KXN1132AA > >Recently there was a post about oscillator stability and I thing >drift over time. > >Was the large Motorola oscillator the one in the subject line? > >Further markings on the oscillator are source code 9896, Cust No 48R83851N02. > >This is a 5 MHz operating frequency oscillator. > >There are 8 lugs to interface the oscillator. Pin 4 is plus and pins >2 and 3 are negative. >I think that this oscillator is an OCXO and works on 24VDC. > >Can this oscillator be disciplined? > >What are the other pins for? >What is the oscillator accuracy? > >Thanks >73 >Glenn >WB4UIV > > > > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From hmurray at megapathdsl.net Sun Jan 25 00:41:28 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 24 Jan 2009 16:41:28 -0800 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: Message from "Poul-Henning Kamp" of "Sat, 24 Jan 2009 19:48:14 GMT." <19593.1232826494@critter.freebsd.dk> Message-ID: <20090125004129.20010BCD8@ip-64-139-1-69.sjc.megapath.net> > For permanent measurement points, I prefer the Dallas DS18B20 1-wire > sensors, they interface to a single I/O pin on anything programmable > and gives 1/16?C resolution and +/- .5?C precision. Thanks for the reminder. I have one of the Dallas/Maxim RS-232 to 1-wire adapters, but my not quite quick attempts to get it working didn't get anywhere. Does anybody have working Linux/*BSD code that I can look at? -- These are my opinions, not necessarily my employer's. I hate spam. From glennmaillist at bellsouth.net Sun Jan 25 00:41:51 2009 From: glennmaillist at bellsouth.net (Glenn Little WB4UIV) Date: Sat, 24 Jan 2009 19:41:51 -0500 Subject: [time-nuts] Motorola KXN1132AA In-Reply-To: <6809470.1232840081403.JavaMail.root@elwamui-cypress.atl.sa .earthlink.net> References: <6809470.1232840081403.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Message-ID: <6.2.3.4.2.20090124193132.0596f0e0@mail.bellsouth.net> The oscillator was bought as part of a scrapped Motorola base station. I was told that it was a PURC. The only leads attached to the oscillator are the power and the BNC output connector. Would this oscillator be able to be disciplined? What would its accuracy be as the basic oscillator? There was no GPS in the parts that I got. The oscillator is large enough to be a double oven OCXO. Thanks for any help 73 Glenn WB4UIV At 06:34 PM 1/24/2009, you wrote: >If that came from a PURC, see if the GPS receiver is included. It may not as >they used one receiver per site and slaved all the HSO's to it. >Or, there may be a 14.4 MHz oscillator on board. >Hopefully the 5 MHz oscillator was not purloined !! >There are also some jumpers that allow you to set the reference >input frequency >(I think, I am only recalling from memory the MSF5000 HSO, which is similar, I >think). > >73, Dick, W1KSZ > >-----Original Message----- > >From: Glenn Little WB4UIV > >Sent: Jan 24, 2009 4:42 PM > >To: Time-Nuts list > >Subject: [time-nuts] Motorola KXN1132AA > > > >Recently there was a post about oscillator stability and I thing > >drift over time. > > > >Was the large Motorola oscillator the one in the subject line? > > > >Further markings on the oscillator are source code 9896, Cust No > 48R83851N02. > > > >This is a 5 MHz operating frequency oscillator. > > > >There are 8 lugs to interface the oscillator. Pin 4 is plus and pins > >2 and 3 are negative. > >I think that this oscillator is an OCXO and works on 24VDC. > > > >Can this oscillator be disciplined? > > > >What are the other pins for? > >What is the oscillator accuracy? > > > >Thanks > >73 > >Glenn > >WB4UIV > > > > > > > > > >_______________________________________________ > >time-nuts mailing list -- time-nuts at febo.com > >To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >and follow the instructions there. > > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From bruce.griffiths at xtra.co.nz Sun Jan 25 01:08:48 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Sun, 25 Jan 2009 14:08:48 +1300 Subject: [time-nuts] Motorola KXN1132AA In-Reply-To: <6.2.3.4.2.20090124193132.0596f0e0@mail.bellsouth.net> References: <6809470.1232840081403.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <6.2.3.4.2.20090124193132.0596f0e0@mail.bellsouth.net> Message-ID: <497BBBA0.4030707@xtra.co.nz> Glenn Other leads may include an EFC input. As long as the oscillator frequency can be adjusted electronically (usually via EFC) it can be disciplined. If the oscillator lacks EFC then you may have to resort to using it in a DDS or equivalent so that the output frequency can be adjusted. The only drawbacks with a DDS are the spurs and elevated phase noise. If you use a DDS the control system output must be digital, however an EFC DAC isn't required. There are techniques available for canceling spurs and/or reducing their amplitudes significantly however these techniques add some complexity. Can you post an image of the oscillator? Bruce Glenn Little WB4UIV wrote: > The oscillator was bought as part of a scrapped Motorola base station. > I was told that it was a PURC. > The only leads attached to the oscillator are the power and the BNC > output connector. > > Would this oscillator be able to be disciplined? > What would its accuracy be as the basic oscillator? > > There was no GPS in the parts that I got. > > The oscillator is large enough to be a double oven OCXO. > > Thanks for any help > 73 > Glenn > WB4UIV > > > At 06:34 PM 1/24/2009, you wrote: > >> If that came from a PURC, see if the GPS receiver is included. It may not as >> they used one receiver per site and slaved all the HSO's to it. >> Or, there may be a 14.4 MHz oscillator on board. >> Hopefully the 5 MHz oscillator was not purloined !! >> There are also some jumpers that allow you to set the reference >> input frequency >> (I think, I am only recalling from memory the MSF5000 HSO, which is similar, I >> think). >> >> 73, Dick, W1KSZ >> >> -----Original Message----- >> >>> From: Glenn Little WB4UIV >>> Sent: Jan 24, 2009 4:42 PM >>> To: Time-Nuts list >>> Subject: [time-nuts] Motorola KXN1132AA >>> >>> Recently there was a post about oscillator stability and I thing >>> drift over time. >>> >>> Was the large Motorola oscillator the one in the subject line? >>> >>> Further markings on the oscillator are source code 9896, Cust No >>> >> 48R83851N02. >> >>> This is a 5 MHz operating frequency oscillator. >>> >>> There are 8 lugs to interface the oscillator. Pin 4 is plus and pins >>> 2 and 3 are negative. >>> I think that this oscillator is an OCXO and works on 24VDC. >>> >>> Can this oscillator be disciplined? >>> >>> What are the other pins for? >>> What is the oscillator accuracy? >>> >>> Thanks >>> 73 >>> Glenn >>> WB4UIV >>> >>> >>> >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts at febo.com >>> To unsubscribe, go to >>> >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> >>> and follow the instructions there. >>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From didier at cox.net Sun Jan 25 02:40:36 2009 From: didier at cox.net (Didier) Date: Sat, 24 Jan 2009 20:40:36 -0600 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: <20104.1232832419@critter.freebsd.dk> References: Your message of "Sat, 24 Jan 2009 15:24:09 CST."<9FE35BF1051B413EAE492817D58EC095@didierhp> <20104.1232832419@critter.freebsd.dk> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Poul-Henning Kamp > Sent: Saturday, January 24, 2009 3:27 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Any experienced HP 2804A thermometer > users outthere? > > In message <9FE35BF1051B413EAE492817D58EC095 at didierhp>, > "Didier" writes: > > >But there are cases where there are too big, or they are in a noisy > >environment, and a thermistor is more flexible. > > I seldom find TO-92 too big, in fact, I tend to find things > smaller than TO-92 too small :-) > Well, we are now officially going to 0402 discretes and SC-70 and its smaller siblings for ICs at work, so yes, TO-92 are humongous :-) > >The 18B20 is almost as small as a thermistor, but I do not > have code for it. > >Can't be too hard though. > > I have some PIC18F code if you want it ? > Sure, it's gotta help compared to starting from scratch, as long as it's C. Now, if it's PIC assembly... (I don't do PICs, nothing personal, but I have enough architectures to mess with already :-) Thanks in advance, Didier > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. Didier From bill at iaxs.net Sun Jan 25 02:53:41 2009 From: bill at iaxs.net (Bill Hawkins) Date: Sat, 24 Jan 2009 20:53:41 -0600 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: <497B36DE.9060904@febo.com> References: <497B36DE.9060904@febo.com> Message-ID: John, The best way to couple a probe to a solid surface is to drill a hole in the solid that is deeper than the probe. Put some thermal compound in the hole that will exclude air and insert the probe. You must eliminate air between the probe and the surface. Sadly, that won't work with the usual thicknesses of circuit board and the size of the 2804 probe. This is a simple exercise in heat flow. There are published figures for thermal conductivities of circuit boards, metals and air. There are formulas remarkably like Ohms law relating series temperature drops, thermal conductivity, contact area, and the temperature difference between the source of heat for the system and the sink (which would be the probe leads and ambient air). The thermal conductivity of an insulator like a PC board lies somewhere between air and metal. When you measure a small area of a PC board, that area must cool off unless it is the ultimate source of heat. The only way to avoid that is to have probe leads that are at the temperature you are trying to measure, sort of like a Guard shield for a microvolt measurement. When I think of time-nuts and temperature, oven temperature comes to mind. With a PC board, I'm OK as long as it doesn't char. Can you be more specific about the application? Yours for less speculation and more useful answers, Bill Hawkins -----Original Message----- From: John Ackermann N8UR Sent: Saturday, January 24, 2009 9:42 AM The temperature probes for the 2804A quartz thermometer seem primarily intended for liquid immersion. I'm looking for practical tips on how to couple the probe to a solid surface (e.g., a PC board) for accurate temperature measurements of the surface. Anyone know the best way to do this? Thanks, John From glennmaillist at bellsouth.net Sun Jan 25 03:25:26 2009 From: glennmaillist at bellsouth.net (Glenn Little WB4UIV) Date: Sat, 24 Jan 2009 22:25:26 -0500 Subject: [time-nuts] Motorola KXN1132AA In-Reply-To: <497BBBA0.4030707@xtra.co.nz> References: <6809470.1232840081403.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <6.2.3.4.2.20090124193132.0596f0e0@mail.bellsouth.net> <497BBBA0.4030707@xtra.co.nz> Message-ID: <6.2.3.4.2.20090124221131.0475d530@mail.bellsouth.net> I will try and locate a digital camera. The oscillator is in a tin plated steel box. The dimensions are 5.25"x3"x3". On one 3x3 side, in the center, is a screw that hides an adjustment screw. On the other 3x3 side is the BNC output connector and a ring of terminals about the diameter of a 9 pin tube. There are 8 terminals. Two are for negative power and one is for positive power. The power source is 24VDC. Also on this side is a screw in the upper right hand corner. This screw is soldered to the case. On one of the 5.25x3 sides (the bottom) is four mounting studs. These are 6-32 and are at the corners of an imaginary 2"x4" rectangle centered on the 5.25x3 side. The side that has the BNC connector and terminals is soldered into the rest of the case. There are two dimples to two sides of the box to stop this piece from going too far into the box. 73 Glenn WB4UIV At 08:08 PM 1/24/2009, you wrote: >Glenn > >Other leads may include an EFC input. > >As long as the oscillator frequency can be adjusted electronically >(usually via EFC) it can be disciplined. >If the oscillator lacks EFC then you may have to resort to using it in a >DDS or equivalent so that the output frequency can be adjusted. >The only drawbacks with a DDS are the spurs and elevated phase noise. >If you use a DDS the control system output must be digital, however an >EFC DAC isn't required. >There are techniques available for canceling spurs and/or reducing their >amplitudes significantly however these techniques add some complexity. > >Can you post an image of the oscillator? > >Bruce > >Glenn Little WB4UIV wrote: > > The oscillator was bought as part of a scrapped Motorola base station. > > I was told that it was a PURC. > > The only leads attached to the oscillator are the power and the BNC > > output connector. > > > > Would this oscillator be able to be disciplined? > > What would its accuracy be as the basic oscillator? > > > > There was no GPS in the parts that I got. > > > > The oscillator is large enough to be a double oven OCXO. > > > > Thanks for any help > > 73 > > Glenn > > WB4UIV > > > > > > At 06:34 PM 1/24/2009, you wrote: > > > >> If that came from a PURC, see if the GPS receiver is included. > It may not as > >> they used one receiver per site and slaved all the HSO's to it. > >> Or, there may be a 14.4 MHz oscillator on board. > >> Hopefully the 5 MHz oscillator was not purloined !! > >> There are also some jumpers that allow you to set the reference > >> input frequency > >> (I think, I am only recalling from memory the MSF5000 HSO, which > is similar, I > >> think). > >> > >> 73, Dick, W1KSZ > >> > >> -----Original Message----- > >> > >>> From: Glenn Little WB4UIV > >>> Sent: Jan 24, 2009 4:42 PM > >>> To: Time-Nuts list > >>> Subject: [time-nuts] Motorola KXN1132AA > >>> > >>> Recently there was a post about oscillator stability and I thing > >>> drift over time. > >>> > >>> Was the large Motorola oscillator the one in the subject line? > >>> > >>> Further markings on the oscillator are source code 9896, Cust No > >>> > >> 48R83851N02. > >> > >>> This is a 5 MHz operating frequency oscillator. > >>> > >>> There are 8 lugs to interface the oscillator. Pin 4 is plus and pins > >>> 2 and 3 are negative. > >>> I think that this oscillator is an OCXO and works on 24VDC. > >>> > >>> Can this oscillator be disciplined? > >>> > >>> What are the other pins for? > >>> What is the oscillator accuracy? > >>> > >>> Thanks > >>> 73 > >>> Glenn > >>> WB4UIV > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> time-nuts mailing list -- time-nuts at febo.com > >>> To unsubscribe, go to > >>> > >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >> > >>> and follow the instructions there. > >>> > >> _______________________________________________ > >> time-nuts mailing list -- time-nuts at febo.com > >> To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >> and follow the instructions there. > >> > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts at febo.com > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > > > > >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From didier at cox.net Sun Jan 25 03:43:45 2009 From: didier at cox.net (Didier) Date: Sat, 24 Jan 2009 21:43:45 -0600 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: References: <497B36DE.9060904@febo.com> Message-ID: <4BB4E69084C746EFB2F1C1CE0E6BE2C7@didierhp> > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Bill Hawkins > Sent: Saturday, January 24, 2009 8:54 PM > To: 'Discussion of precise time and frequency measurement' > Subject: Re: [time-nuts] Any experienced HP 2804A thermometer > users outthere? > > John, > ... > > The thermal conductivity of an insulator like a PC board lies > somewhere between air and metal. When you measure a small > area of a PC board, that area must cool off unless it is the > ultimate source of heat. The only way to avoid that is to > have probe leads that are at the temperature you are trying > to measure, sort of like a Guard shield for a microvolt measurement. > When using thermocouples, we do that by snaking the wire leading to the thermocouple along the PWB and hold it there with small pieces of tape, as opposed to glueing the thermocouple to the board and letting the wires go away from the board immediately. That ensures the last few inches of wire leading to the thermocouple are at or close to the temperature of the PWB, so heat flow to and from the thermocouple itself is minimized. Didier From hmurray at megapathdsl.net Sun Jan 25 05:08:42 2009 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 24 Jan 2009 21:08:42 -0800 Subject: [time-nuts] Any experienced HP 2804A thermometer users out there? In-Reply-To: Message from "Bill Hawkins" of "Sat, 24 Jan 2009 20:53:41 CST." Message-ID: <20090125050843.A6741BCD8@ip-64-139-1-69.sjc.megapath.net> > The thermal conductivity of an insulator like a PC board lies > somewhere between air and metal. Yup, and it depends a lot on how much copper there is on the surface you connect to and/or how many vias connect to other layers with lots of copper and/or if they have thermal reliefs. -- These are my opinions, not necessarily my employer's. I hate spam. From phk at phk.freebsd.dk Sun Jan 25 08:25:11 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 25 Jan 2009 08:25:11 +0000 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: Your message of "Sat, 24 Jan 2009 20:40:36 CST." Message-ID: <23344.1232871911@critter.freebsd.dk> In message , "Didier" writes: >> I have some PIC18F code if you want it ? > >Sure, it's gotta help compared to starting from scratch, as long as it's C. http://phk.freebsd.dk/patch/onewire.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From didier at cox.net Sun Jan 25 13:48:31 2009 From: didier at cox.net (Didier) Date: Sun, 25 Jan 2009 07:48:31 -0600 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: <23344.1232871911@critter.freebsd.dk> References: Your message of "Sat, 24 Jan 2009 20:40:36 CST." <23344.1232871911@critter.freebsd.dk> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Poul-Henning Kamp > Sent: Sunday, January 25, 2009 2:25 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Any experienced HP 2804A thermometer > users outthere? > > In message , > "Didier" writes: > > >> I have some PIC18F code if you want it ? > > > >Sure, it's gotta help compared to starting from scratch, as > long as it's C. > > http://phk.freebsd.dk/patch/onewire.c > Thank you very much, it will get me started. Didier From scifiscifi at sci.fi Sun Jan 25 14:37:09 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Sun, 25 Jan 2009 16:37:09 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: <497C7915.3040409@sci.fi> Hello everyone Has anyone tried to replace Tbolt's OCXO with Efratom LPRO Rubidium oscillator? I just did that it seems to work, but I have no idea is it really better or worse (or same) as original Thunderbolt. No ideas how to measure it. Is it possible to measure allan deviation or such things by using the logs generated by Tboltmon.exe? So it would be nice to know if anyone has tried that before and done some measurement against cesium or such standard to get exact results. I think that it should be a much better (in theory) than OCXO which comes short therm stability (what I'm actually seeking for). It should be much more accurate with long holdovers also. This is very simple modification by the way. Infact my original plan was to use the 1PPS to synchronize the LPRO C-field with separate control electronics (based own design with PIC and 24-bit DAC). But then I noticed with spectrum analyzer measurements that the Tbolt's OCXO has almost exactly same output level than LPRO: about +7 dBm and of course they both have 10 MHz output frequency. So it would be possible to replace OCXO with LPRO without any level matching or so... Also, with changing the disciplining settings (DAC voltages) even the control voltage of OCXO can be fed directly to LPRO's C-field without any extra electronics. This enables to use Tbolt's advanced steering algorithms for C-field control without any own programming work here. About the settings: Ko (Hz/V) for LPRO is about 0.006 Hz/V (if calculated correctly from datasheet values) and minimum value what Thunderbolt accepts for this is 0.01. However even 0.1 seems to work (may be even better, causes smaller changes of DAC voltage). Min voltage must be set to 0.0V, because it's not allowed to feed any negative voltages to LPRO's C-field. However the LPRO manual says that it will not break with negative voltages under 8V. Initial DAC Voltage should be set somewhere about 2.5 volts, I run it some time with GPS lock and noticed that good initial voltage with my LPRO was 2.56. Loop Dynamics is big mystery. I'd like to think that very slow loop should be good for rubidium. So I tried 1000 secs as a test. But if anyone has tried this before could give some advice about loop dynamics? There are even places for SMA-connectors of Thunderbolt PCB. One is the 10 MHz and another is the control voltage. After doing the modification it may be a good idea to start with factory settings to reset any "learned" data for OCXO and right after that reset change the DAC voltage settings. So... it seems to work. But it's quite difficult to tell anything of it's performance. I just logged it for couple of hours (started after it has been couple of hours up). Within that very short test time it seems that at least the PPS offset value stays now inside same ns value at longer times than with OCXO. With OCXO it changed many ns between readings, quite randomly - but with rubidium the change is usually couple of hundred picoseconds. Could this be a sign of better short therm drift / random walk performance? Here's a link for the log: http://www.amigazone.fi/files/gpsdo/tbolt-lpro-test.log (Log format: TOW, PPS offset, DAC voltage, Disciplining mode & activity) The log was created with following settings: Time Constant: 1000 Damping factor: 1.2 Ko: 0.01 Initial DAC volt: 2.558V -- 73's Esa OH4KJU From tvb at LeapSecond.com Sun Jan 25 17:03:02 2009 From: tvb at LeapSecond.com (Tom Van Baak) Date: Sun, 25 Jan 2009 09:03:02 -0800 Subject: [time-nuts] Home made GPS disciplined atomic clock References: <497C7915.3040409@sci.fi> Message-ID: <27FEC61EB60E446B9C20943123DCDEA6@pc52> > I think that it should be a much better (in theory) than OCXO which > comes short therm stability (what I'm actually seeking for). It should > be much more accurate with long holdovers also. Right, it all depends on what stability you're after. The OCXO will have much better short-term stability than the LPRO -- the LPRO is close to ten times worse. So do not replace the TBolt OCXO with a LPRO if short-term stability is your goal. See: TBolt OCXO plots: http://www.leapsecond.com/pages/gpsdo/ http://www.leapsecond.com/pages/tbolt-tc/ LPRO plots: http://www.leapsecond.com/museum/lpro/ However, if long-term, GPS-unlocked, holdover performance is the goal, then using a Rb would make a good choice. > This is very simple modification by the way. Infact my original plan was > to use the 1PPS to synchronize the LPRO C-field with separate control > ... See John Miles work to replace the Thunderbolt OCXO: http://www.thegleam.com/ke5fx/tbolt.htm /tvb > Here's a link for the log: > http://www.amigazone.fi/files/gpsdo/tbolt-lpro-test.log > (Log format: TOW, PPS offset, DAC voltage, Disciplining mode & activity) I'll have a look at this; but it's not accessible for some reason. /tvb From frledda at verizon.net Sun Jan 25 17:43:08 2009 From: frledda at verizon.net (Francesco Ledda) Date: Sun, 25 Jan 2009 11:43:08 -0600 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <27FEC61EB60E446B9C20943123DCDEA6@pc52> Message-ID: The challenge is to detect a failure of the GPS source (LOS) before the DPLL moves the OCXO. I used to design Stratum clocks for a large telecom company, and I used several trick do detect a phase ramp on the digital phase detector; this was used to declare a probable bad source. At that point, we halted the movement of the DPLL and observed the phase detector activity. We had two DPLLs, and if both detected a phase ramp, we declared the source bad. -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On Behalf Of Tom Van Baak Sent: Sunday, January 25, 2009 11:03 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Home made GPS disciplined atomic clock > I think that it should be a much better (in theory) than OCXO which > comes short therm stability (what I'm actually seeking for). It should > be much more accurate with long holdovers also. Right, it all depends on what stability you're after. The OCXO will have much better short-term stability than the LPRO -- the LPRO is close to ten times worse. So do not replace the TBolt OCXO with a LPRO if short-term stability is your goal. See: TBolt OCXO plots: http://www.leapsecond.com/pages/gpsdo/ http://www.leapsecond.com/pages/tbolt-tc/ LPRO plots: http://www.leapsecond.com/museum/lpro/ However, if long-term, GPS-unlocked, holdover performance is the goal, then using a Rb would make a good choice. > This is very simple modification by the way. Infact my original plan was > to use the 1PPS to synchronize the LPRO C-field with separate control > ... See John Miles work to replace the Thunderbolt OCXO: http://www.thegleam.com/ke5fx/tbolt.htm /tvb > Here's a link for the log: > http://www.amigazone.fi/files/gpsdo/tbolt-lpro-test.log > (Log format: TOW, PPS offset, DAC voltage, Disciplining mode & activity) I'll have a look at this; but it's not accessible for some reason. /tvb _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From EWKehren at aol.com Sun Jan 25 17:44:48 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Sun, 25 Jan 2009 12:44:48 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: I think it is a bad idea except if holdover due to loss of GPS is an issue. For all practical purposes disciplined oscillators make rubidium obsolete because the majority use lower performance cheaper oscillators in their systems. Looking at Corby Dawson's data on oscillators and HP 5065 shows that it does outperform even the best oscillators but there is no comparison between a HP 5065 and what is on the market today. Look at the specs of Rubidium standards and look at their 100 sec. data. If you want improvement take the output of a Thunderbolt and lock it to something like a FTS 1000, 1200 or 2000 adjusting the loop constant to the specification of the external oscillator. As an example the 100 sec.spec on the FE 5600 is 4 X -12 versus 1 X-12 on the FTS series oscillators. And I consider the FE 5600 one of the better Rubidium's! I have not personally characterized Thunderbolt and Rubidium oscillators but I doubt that there is very much difference in performance. Bert WB5MZJ **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From scifiscifi at sci.fi Sun Jan 25 18:08:36 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Sun, 25 Jan 2009 20:08:36 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <27FEC61EB60E446B9C20943123DCDEA6@pc52> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> Message-ID: <497CAAA4.8050506@sci.fi> > Right, it all depends on what stability you're after. The OCXO > will have much better short-term stability than the LPRO -- the > LPRO is close to ten times worse. Basicly I'm seeking an accurate frequency standard for RF lab. It should be always as accurate as possible, regardless the state of GPS receiving etc. Before doing this modification I did some test runs Trimble versus LPRO with phase comparator circuit. I noticed that Trimble is accurate as long as it gets the GPS signal and phase change between LPRO and Trimble was changing evenly. It is even accurate after the GPS drops (holdover mode) but after the signal comes back the things start to go badly wrong. It starts to roll it's phase / 1 PPS back to alignment woth GPS time and this caused very badly looking phase activity when compared to LPRO. Another bad issue was that if there's a change in satellite receiving (satellite hopping or some) it causes rapid change the PPS offset and OCXO frequency starts to roll to get the 1 PPS back to alignment. So it seems that Trimble's main principle is 10000000 pulses per PPS, with no exceptions and when the PPS goes off the 10 MHz must also go off to get the 1 PPS back to aligment. So there's no constant 10 MHz frequency either. That's not acceptable because in normal use I should be always aware of GPS receiving states - I'd just like to trust that I'm getting accurate 10 MHz - any time! So I become to think that may be very slow loop dynamics will solve that problem (if the DAC value isn't changed at every little change at satellite reception). And for that purpose the rubidium sound better than OCXO. I also got misunderstanding from this: http://www.ptsyst.com/GPS10RB-B.pdf It claims that rubidiums will have good short therm drift. My problem here is that there's no way to measure the different setups because my only rb is now part of the experiment. All I can do is the log them and look the change between PPS timing offset readings. When doing the GPS vs. LPRO phase comparison told before I noticed that the changes of PPS offsets are correlated the phase changes between LPRO and Tbolt output, when observed quite short time. So it seems that the PPS offset is somehow accurate measurement of oscillator stability as well. I also done some noise measurements with spectrum analyzer between LRPO and Trimble outputs. LPRO had lower noise floor around fundamental. > See John Miles work to replace the Thunderbolt OCXO: > http://www.thegleam.com/ke5fx/tbolt.htm Hmm. May be the OCXO on my tbolt is then somehow bad if the LPRO should be even worse? It has Trimble label on and the unit is manufactured on 2005, in China. Is there any logs available with that better OCXO? It would be nice to see the PPS offsets variance between readings with that oscillator. >> http://www.amigazone.fi/files/gpsdo/tbolt-lpro-test.log > I'll have a look at this; but it's not accessible for some reason. Oops.. Now you should get it. -- 73s! Esa OH4KJU From EWKehren at aol.com Sun Jan 25 18:24:40 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Sun, 25 Jan 2009 13:24:40 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: Do not forget the Trimble was never intended to be a frequency standard. Bert **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From bruce.griffiths at xtra.co.nz Sun Jan 25 18:42:59 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 26 Jan 2009 07:42:59 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <497CB2B3.8040900@xtra.co.nz> EWKehren at aol.com wrote: > Do not forget the Trimble was never intended to be a frequency standard. Bert > > Bert Why do you believe that? Bruce From EWKehren at aol.com Sun Jan 25 18:49:18 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Sun, 25 Jan 2009 13:49:18 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: Its main purpose was time synchronization. Bert **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From bruce.griffiths at xtra.co.nz Sun Jan 25 19:01:29 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 26 Jan 2009 08:01:29 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <497CB709.5060501@xtra.co.nz> EWKehren at aol.com wrote: > Its main purpose was time synchronization. Bert > > Bert But time and frequency are dual aspects of the same phenomenon. The only real concern is the behaviour of the Thunderbolt when recovering from holdover. There will be transient time (phase ) and frequency excursions. One can either allow a jam sync for fast correction of any accumulated time error or disable it and accept the potentially larger frequency excursions as the disciplining loop locks the PPS output to GPS time. Performance during holdover depends on whether the Kalman filter has accumulated sufficient information to correct for drift tempco and other predictable errors during holdover. Bruce From holrum at hotmail.com Sun Jan 25 05:19:22 2009 From: holrum at hotmail.com (Mark Sims) Date: Sun, 25 Jan 2009 05:19:22 +0000 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: References: Message-ID: My favorite temperature measuring system is the AD537 voltage to frequency converter. It has an on-chip temp sensor or it can be used with an external thermistor. The chip is usually found in a TO5 can, so the on-chip sensor has a fairly high thermal mass. Thermistors can provide a near instantaneous response if you use a small enough device (you can get thermistors that are nearly microscopic in size). You can easily get microdegree resolution with hardware any time nut has. The biggest problem is calibrating it if you need absolute accuracy. You could do a comparison with the 2804A. Or a three point calibration at the triple points of ice and gallium along with boiling water (compensated for air prerssure, etc)... but then triple point cells are not in most pepole's bag 'o tricks... _________________________________________________________________ Windows Live?: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009 From frledda at verizon.net Sun Jan 25 19:08:04 2009 From: frledda at verizon.net (Francesco Ledda) Date: Sun, 25 Jan 2009 13:08:04 -0600 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497CB709.5060501@xtra.co.nz> Message-ID: There are techniques to remove/eliminate the phase error when the GPS source comes back on line. If the holdover is entered appropriately, the frequency error should be small and dependent on the stability of the OCXO. -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On Behalf Of Bruce Griffiths Sent: Sunday, January 25, 2009 1:01 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Home made GPS disciplined atomic clock EWKehren at aol.com wrote: > Its main purpose was time synchronization. Bert > > Bert But time and frequency are dual aspects of the same phenomenon. The only real concern is the behaviour of the Thunderbolt when recovering from holdover. There will be transient time (phase ) and frequency excursions. One can either allow a jam sync for fast correction of any accumulated time error or disable it and accept the potentially larger frequency excursions as the disciplining loop locks the PPS output to GPS time. Performance during holdover depends on whether the Kalman filter has accumulated sufficient information to correct for drift tempco and other predictable errors during holdover. Bruce _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From scifiscifi at sci.fi Sun Jan 25 19:10:57 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Sun, 25 Jan 2009 21:10:57 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <497CB941.6060802@sci.fi> > Do not forget the Trimble was never intended to be a frequency standard. Ok, then it might be a better idea to use only it's 1 PPS output to count the frequency of the some other oscillator and build own steering electronics for that. Infact my original plan was to do right that. If the count/steering period is set long enough there should be any problem caused the satellite hopping or such things anymore. Let's say that if I make 24 hours running average for 10 MHz using Trimble's 1 PPS as a reference to determine the oscillator control then I would get the better results, right? But if LPRO is useless, which oscillator should I seek for main output? With low short therm drift and good phase noise characteristics etc? Also the goal is to build the reference with surplus (etc) parts as a hobby project, no interest to invest thousands for that. -- 73s! Esa OH4KJU From bruce.griffiths at xtra.co.nz Sun Jan 25 19:13:51 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 26 Jan 2009 08:13:51 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497CAAA4.8050506@sci.fi> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> <497CAAA4.8050506@sci.fi> Message-ID: <497CB9EF.50006@xtra.co.nz> Esa You can change the Thunderbolt recovery mode from holdover. One test you can perform that should give an indication of the location of the Allan intercept is to: 1) connect the receiver to an antenna. 2) let it run for a few days so the Kalman filter learns the drift, tempco and other parameters. 3) manually disable the disciplining leaving the thunderbolt connected to the antenna. 4) Log the Thunderbolt PPS offset (plus time stamp) for a day or more. 5) Analyse the resultant data to determine the relative Allan deviation between the receiver and the 10MHz source. Ulrich's Plotter is good for this (use the overlapping ADEV algorithm - although TOTDEV and Theo1 are even better estimators of the Allan deviation) All going well, you will see a minimum in the Allan deviation versus tau plot. In most cases the value of tau at the minimum will be relatively close to the value of tau at the Allan intercept. However to do this successfully your antenna will need a good view of the sky. For short tau the GPS receiver noise will dominate. For long tau the 10MHz source noise and drift will dominate. Bruce Esa Heikkinen wrote: >> Right, it all depends on what stability you're after. The OCXO >> will have much better short-term stability than the LPRO -- the >> LPRO is close to ten times worse. >> > > Basicly I'm seeking an accurate frequency standard for RF lab. It should > be always as accurate as possible, regardless the state of GPS receiving > etc. > > Before doing this modification I did some test runs Trimble versus LPRO > with phase comparator circuit. I noticed that Trimble is accurate as > long as it gets the GPS signal and phase change between LPRO and Trimble > was changing evenly. It is even accurate after the GPS drops (holdover > mode) but after the signal comes back the things start to go badly > wrong. It starts to roll it's phase / 1 PPS back to alignment woth GPS > time and this caused very badly looking phase activity when compared to > LPRO. > > Another bad issue was that if there's a change in satellite receiving > (satellite hopping or some) it causes rapid change the PPS offset and > OCXO frequency starts to roll to get the 1 PPS back to alignment. So it > seems that Trimble's main principle is 10000000 pulses per PPS, with no > exceptions and when the PPS goes off the 10 MHz must also go off to get > the 1 PPS back to aligment. So there's no constant 10 MHz frequency > either. That's not acceptable because in normal use I should be always > aware of GPS receiving states - I'd just like to trust that I'm getting > accurate 10 MHz - any time! > > So I become to think that may be very slow loop dynamics will solve that > problem (if the DAC value isn't changed at every little change at > satellite reception). And for that purpose the rubidium sound better > than OCXO. > > I also got misunderstanding from this: > http://www.ptsyst.com/GPS10RB-B.pdf > It claims that rubidiums will have good short therm drift. > > My problem here is that there's no way to measure the different setups > because my only rb is now part of the experiment. All I can do is the > log them and look the change between PPS timing offset readings. > > When doing the GPS vs. LPRO phase comparison told before I noticed that > the changes of PPS offsets are correlated the phase changes between LPRO > and Tbolt output, when observed quite short time. So it seems that the > PPS offset is somehow accurate measurement of oscillator stability as well. > > I also done some noise measurements with spectrum analyzer between LRPO > and Trimble outputs. LPRO had lower noise floor around fundamental. > > >> See John Miles work to replace the Thunderbolt OCXO: >> http://www.thegleam.com/ke5fx/tbolt.htm >> > > Hmm. May be the OCXO on my tbolt is then somehow bad if the LPRO should > be even worse? It has Trimble label on and the unit is manufactured on > 2005, in China. > > Is there any logs available with that better OCXO? It would be nice to > see the PPS offsets variance between readings with that oscillator. > > >>> http://www.amigazone.fi/files/gpsdo/tbolt-lpro-test.log >>> >> I'll have a look at this; but it's not accessible for some reason. >> > > Oops.. Now you should get it. > > From bruce.griffiths at xtra.co.nz Sun Jan 25 19:23:17 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 26 Jan 2009 08:23:17 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497CB941.6060802@sci.fi> References: <497CB941.6060802@sci.fi> Message-ID: <497CBC25.90306@xtra.co.nz> Esa Heikkinen wrote: >> Do not forget the Trimble was never intended to be a frequency standard. >> > > Ok, then it might be a better idea to use only it's 1 PPS output to > count the frequency of the some other oscillator and build own steering > electronics for that. Infact my original plan was to do right that. > > If the count/steering period is set long enough there should be any > problem caused the satellite hopping or such things anymore. Let's say > that if I make 24 hours running average for 10 MHz using Trimble's 1 PPS > as a reference to determine the oscillator control then I would get the > better results, right? > > But if LPRO is useless, which oscillator should I seek for main output? > With low short therm drift and good phase noise characteristics etc? > > Also the goal is to build the reference with surplus (etc) parts as a > hobby project, no interest to invest thousands for that. > > Esa Given the large PPS output jitter wrt to the OCXO output frequency, this is probably a bad idea. There's nothing wrong with the idea of using a rubidium standard, you just need to cleanup its output first by phase locking a low noise OCXO with a suitable loop time constant to the rubidium output first. Use the cleaned up output as the 10MHz signal for the Thunderbolt and lock the rubidium standard to GPS using the thunderbolt with a suitably long loop time constant. This should result in low phase noise and drift during holdover. Bruce From bruce.griffiths at xtra.co.nz Sun Jan 25 19:29:45 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 26 Jan 2009 08:29:45 +1300 Subject: [time-nuts] Any experienced HP 2804A thermometer users outthere? In-Reply-To: References: Message-ID: <497CBDA9.4090605@xtra.co.nz> Mark Sims wrote: > My favorite temperature measuring system is the AD537 voltage to frequency converter. It has an on-chip temp sensor or it can be used with an external thermistor. The chip is usually found in a TO5 can, so the on-chip sensor has a fairly high thermal mass. Thermistors can provide a near instantaneous response if you use a small enough device (you can get thermistors that are nearly microscopic in size). You can easily get microdegree resolution with hardware any time nut has. > > The biggest problem is calibrating it if you need absolute accuracy. You could do a comparison with the 2804A. Or a three point calibration at the triple points of ice and gallium along with boiling water (compensated for air prerssure, etc)... but then triple point cells are not in most pepole's bag 'o tricks... > > You could always compare it with a Johnson noise thermometer. No triple point cells etc are required, just a large thermal mass the temperature of which can be varied with good short term temperature stability. Thermistors are highly nonlinear and it is advisable to use more than just a pair of accurately known temperatures to calibrate them. Bruce From SAIDJACK at aol.com Sun Jan 25 19:31:38 2009 From: SAIDJACK at aol.com (SAIDJACK at aol.com) Date: Sun, 25 Jan 2009 14:31:38 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: Hi Bruce, since the LPRO has significantly worse STS (according to this thread) than the Tapr Tbolt itself, then using the LPRO would only make sense if GPS is not available, and the unit is in holdover. This is similar to what you mentioned with the long time-constant. One would not want the LPRO to make the Tbolt worse than it is when perfectly locked to GPS. Our Fury and FireFly-II units allow an external 1PPS input to be connected, and the switchover will automatically happen if the internal GPS goes into holdover. Using the LPRO on the external 1PPS, and selecting auto-switchover would give the best of both worlds: the excellent ADEV over all measurement intervals when GPS is available, and the Rubidium stability when GPS is out for longer time periods. Another advantage of this is that when the Fury/FireFly-II is using the LPRO 1PPS it will act as a cleanup-filter for the LPRO, and one would not lose the better STS of the Fury/FireFly OCXO. I am not sure if the Tbolt has an external 1PPS fail-safe backup input, I could not see one on the PCB. bye, Said In a message dated 1/25/2009 11:23:53 Pacific Standard Time, bruce.griffiths at xtra.co.nz writes: Given the large PPS output jitter wrt to the OCXO output frequency, this is probably a bad idea. There's nothing wrong with the idea of using a rubidium standard, you just need to cleanup its output first by phase locking a low noise OCXO with a suitable loop time constant to the rubidium output first. Use the cleaned up output as the 10MHz signal for the Thunderbolt and lock the rubidium standard to GPS using the thunderbolt with a suitably long loop time constant. This should result in low phase noise and drift during holdover. Bruce From EWKehren at aol.com Sun Jan 25 19:33:05 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Sun, 25 Jan 2009 14:33:05 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: Sorry, I offended you Bruce. True time and frequency are definitely inter related, but as you and Esa pointed out the Trimble has an output that does change under certain circumstances. And the reason Esa is pursuing his approach is that for his need as a frequency standard the unit is not doing the job. Bert **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From scifiscifi at sci.fi Sun Jan 25 19:41:01 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Sun, 25 Jan 2009 21:41:01 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497CB9EF.50006@xtra.co.nz> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> <497CAAA4.8050506@sci.fi> <497CB9EF.50006@xtra.co.nz> Message-ID: <497CC04D.9060002@sci.fi> > One test you can perform that should give an indication of the location > of the Allan intercept is to: Ok, thanks for your clear instructions! My test periods have been much too short, if the Kalman filter learning takes even days! But with these instructions I'lll get better data for OCXO vs. LPRO comparison and maybe also the OCXO health. > Ulrich's Plotter is good for this Hmm. Is that software available somewhere? No luck with quick Google tour... > However to do this successfully your antenna will need a good view of > the sky. And that's also one of my problems here. Many trees in the yard. No problems with normal "hand GPS" reception but when it comes to these timing systems this could be one explanation of these strange timing changes at satellite "hops" already noted. However the antenna sees most of the sky clearly but not so close to horizon. Will the Northen position (Lat 62.33302) also cause inaccuracy to GPS? -- 73s! Esa OH4KJU From normn3ykf at stny.rr.com Sun Jan 25 19:57:50 2009 From: normn3ykf at stny.rr.com (Norman J McSweyn) Date: Sun, 25 Jan 2009 14:57:50 -0500 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497CC04D.9060002@sci.fi> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> <497CAAA4.8050506@sci.fi> <497CB9EF.50006@xtra.co.nz> <497CC04D.9060002@sci.fi> Message-ID: <497CC43E.9000200@stny.rr.com> Google df6jb plotter. It's great! 73 de Norm n3ykf From Brucekareen at aol.com Sun Jan 25 20:05:01 2009 From: Brucekareen at aol.com (Brucekareen at aol.com) Date: Sun, 25 Jan 2009 15:05:01 EST Subject: [time-nuts] Upgrade for LPRO 10 MHz Oscillator? Message-ID: Has anyone upgraded the LPRO oscillator by out-boarding a suitable OCXO unit? Bruce Hunter **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From yuri at ostry.ru Sun Jan 25 20:09:38 2009 From: yuri at ostry.ru (Yuri Ostry) Date: Sun, 25 Jan 2009 23:09:38 +0300 Subject: [time-nuts] Upgrade for LPRO 10 MHz Oscillator? In-Reply-To: References: Message-ID: <1954796982.20090125230938@ostry.ru> Hello? Sunday, January 25, 2009, 23:05:01, Bruce Hunter wrote: B> Has anyone upgraded the LPRO oscillator by out-boarding a suitable OCXO unit? Why not just lock external oscillator to LPRO output with long enough time constant? Is there any real difference? -- Best regards, Yuri mailto:yuri at ostry.ru From bruce.griffiths at xtra.co.nz Sun Jan 25 20:10:56 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 26 Jan 2009 09:10:56 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497CC04D.9060002@sci.fi> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> <497CAAA4.8050506@sci.fi> <497CB9EF.50006@xtra.co.nz> <497CC04D.9060002@sci.fi> Message-ID: <497CC750.3090601@xtra.co.nz> Esa Heikkinen wrote: >> One test you can perform that should give an indication of the location >> of the Allan intercept is to: >> > > Ok, thanks for your clear instructions! > > My test periods have been much too short, if the Kalman filter learning > takes even days! But with these instructions I'lll get better data for > OCXO vs. LPRO comparison and maybe also the OCXO health. > > >> Ulrich's Plotter is good for this >> > > Hmm. Is that software available somewhere? > No luck with quick Google tour... > > >> However to do this successfully your antenna will need a good view of >> the sky. >> > > And that's also one of my problems here. Many trees in the yard. No > problems with normal "hand GPS" reception but when it comes to these > timing systems this could be one explanation of these strange timing > changes at satellite "hops" already noted. However the antenna sees most > of the sky clearly but not so close to horizon. Will the Northen > position (Lat 62.33302) also cause inaccuracy to GPS? > > Esa You'll need a good view of the sky to the south where the GPS SVs will be located. You'll also need to set the elevation mask appropriately. Multipath will be more problematic with low elevation SVs. It would also be helpful if you plot the SV tracks across the sky (as seen by a GPS receiver) as this will show if and where obstructions are significant. There's a lot of software out there for doing this. Bruce From EWKehren at aol.com Sun Jan 25 20:28:45 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Sun, 25 Jan 2009 15:28:45 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: Esa, I would do a clean up using an oscillator like a HP 10811 and use the rubidium to check if you do have an improvement. Right now you have no way of knowing what you are getting. It allows you to play with the time constant and there is enough data available to figure out what the optimum time constant is. Corby as we speak has some of my 1200's 2000, 1000 and others to gather data but also to select two units, using one with a Shera board and one with a FE 5602 replacing the internal oscillator also locked with a Shera board and than do a comparison. Ten years ago I did play with time and frequency and have had all the time an Austron Loran running and a HP 10811 with the Shera board and at one time six Cesium but did loose interest, now back in the game. It will take time to catch up and have capability that allows me to do some more meaningful tests. Still have five HP 5061A but am working on modifying a HP 5062 to a FTS tube. Bert in Miami **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From bruce.griffiths at xtra.co.nz Sun Jan 25 21:15:51 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Mon, 26 Jan 2009 10:15:51 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <497CD687.10703@xtra.co.nz> EWKehren at aol.com wrote: > Sorry, I offended you Bruce. True time and frequency are definitely inter > related, but as you and Esa pointed out the Trimble has an output that does > change under certain circumstances. And the reason Esa is pursuing his approach > is that for his need as a frequency standard the unit is not doing the job. > Bert > Bert Since the Thunderbolt produces the PPS output by dividing down the 10MHz, except during jam sync the 2 signals should have similar noise. Since its more complex to lock to a PPS signal than lock to a 10MHz signal, its perhaps simpler to lock to the 10MHz output with a suitably large loop time constant. Low noise analog phase detectors can then be used. Bruce From holrum at hotmail.com Sun Jan 25 22:14:03 2009 From: holrum at hotmail.com (Mark Sims) Date: Sun, 25 Jan 2009 22:14:03 +0000 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: If you have an older PC/laptop that can run DOS or WIN98 and has a VESA compatible video BIOS then you might want to try Lady Heather's Disciplined Oscillator Controller Program (downloadable from the archives). It has bulilt in support for calculating and graphing the ADEV/OADEV of the PPS and OSC parameters. Also graphs the PPS and OSC values along with the DAC and TEMP parameters and the satellite count. Constellation changes are also marked. The source code is there if you want to modify it for a more modern system. The distributed version was compiled with Quick C and set up for a 1024x768 screen. ----------------------------- > One test you can perform that should give an indication of the location > of the Allan intercept is to: Ok, thanks for your clear instructions! My test periods have been much too short, if the Kalman filter learning takes even days! But with these instructions I'lll get better data for OCXO vs. LPRO comparison and maybe also the OCXO health. > Ulrich's Plotter is good for this Hmm. Is that software available somewhere? No luck with quick Google tour... _________________________________________________________________ Windows Live? Hotmail?:?more than just e-mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009 From scifiscifi at sci.fi Mon Jan 26 10:36:18 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Mon, 26 Jan 2009 12:36:18 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <497D9222.1070207@sci.fi> > If you have an older PC/laptop that can run DOS or WIN98 and has a VESA compatible video BIOS > then you might want to try Lady Heather's Disciplined Oscillator Controller Program (downloadable > from the archives). It has bulilt in support for calculating and graphing the ADEV/OADEV of the > PPS and OSC parameters. Also graphs the PPS and OSC values along with the DAC and TEMP > parameters and the satellite count. Constellation changes are also marked. Thanks again. Just tested that (runs also with XP DOS mode) and it's great! Have to set some older laptop for this. It even shows me that the Kalman filter was still OFF, that information seems to be missing in tboltmon. -- 73s! Esa OH4KJU From stijena at tapko.de Mon Jan 26 11:04:21 2009 From: stijena at tapko.de (Predrag Dukic) Date: Mon, 26 Jan 2009 12:04:21 +0100 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <7.0.1.0.1.20090126120330.01e95dd8@tapko.de> Hi Mark, Where from could I download this program (Lady Heather....) Thanks Predrag Dukic At 23:14 25.1.2009, you wrote: >If you have an older PC/laptop that can run DOS >or WIN98 and has a VESA compatible video >BIOS then you might want to try Lady Heather's >Disciplined Oscillator Controller Program >(downloadable from the archives). It has bulilt >in support for calculating and graphing the >ADEV/OADEV of the PPS and OSC parameters. Also >graphs the PPS and OSC values along with the DAC >and TEMP parameters and the satellite >count. Constellation changes are also >marked. The source code is there if you want to >modify it for a more modern system. The >distributed version was compiled with Quick C and set up for a 1024x768 screen. > > >----------------------------- > > > One test you can perform that should give an indication of the location > > of the Allan intercept is to: > >Ok, thanks for your clear instructions! > >My test periods have been much too short, if the Kalman filter learning >takes even days! But with these instructions I'lll get better data for >OCXO vs. LPRO comparison and maybe also the OCXO health. > > > Ulrich's Plotter is good for this > >Hmm. Is that software available somewhere? >No luck with quick Google tour... >_________________________________________________________________ >Windows Live? Hotmail?: more than just e-mail. >http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009 >_______________________________________________ >time-nuts mailing list -- time-nuts at febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. From t_list_1_only at braw.co.uk Mon Jan 26 11:14:54 2009 From: t_list_1_only at braw.co.uk (David ) Date: Mon, 26 Jan 2009 11:14:54 -0000 Subject: [time-nuts] Agilent 53132A Needs Help Message-ID: > Date: Thu, 22 Jan 2009 23:00:04 -0500 > From: tomknox at nist.gov > Subject: Re: [time-nuts] Agilent 53132A Needs Help > To: "Yuri Ostry" , "Discussion of precise time and > frequency measurement" > Message-ID: <20090122230004.10395e4xbu1m3a9w at webmail.nist.gov> > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > > Hi Yuri; > I am late to this thread, but if you have not tried this, reseating > the 4 or 2 eproms which are socketed near the rear may solve the > problem. I am currently having the same problem with one of mine and > in the past this have solved the problem on other units. > Good Luck; > Thomas Knox > NIST > 4475 Whitney Place > Boulder Colorado 80305 > 1-303-554-0307 > tomknox at nist.gov > I think I've seen seven Agilent 54132A counters and three of units flagged a ROM fault after Power On Self Test. They had all been well looked after, sitting in racks in a very high end environment, I suspect they were switched on continuously all year. The last statement may be a clue of course. I did have a very brief play with the 'faulty' ones and things seemed to work after the fault message was acknowledged, I could not see any symptoms other than the self test error message. A nice counter but I'm getting ever more nervous about the ability of current test equipment to survive 5 to 10 years. David From scifiscifi at sci.fi Mon Jan 26 11:26:29 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Mon, 26 Jan 2009 13:26:29 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <7.0.1.0.1.20090126120330.01e95dd8@tapko.de> References: <7.0.1.0.1.20090126120330.01e95dd8@tapko.de> Message-ID: <497D9DE5.4080302@sci.fi> I found a link from message archives: http://www.febo.com/pipermail/time-nuts/attachments/20081224/4a474e8d/attachment-0001.zip -- 73s! Esa OH4KJU From henk.termeer at gmail.com Mon Jan 26 12:21:17 2009 From: henk.termeer at gmail.com (Henk Termeer) Date: Mon, 26 Jan 2009 13:21:17 +0100 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497D9DE5.4080302@sci.fi> References: <7.0.1.0.1.20090126120330.01e95dd8@tapko.de> <497D9DE5.4080302@sci.fi> Message-ID: <5323a8e30901260421x59aa6edbp443fbb1cf5a3acc7@mail.gmail.com> Hallo Folkert, Ik zag C, gps en source dus misschien iets voor jou On Mon, Jan 26, 2009 at 12:26 PM, Esa Heikkinen wrote: > I found a link from message archives: > > http://www.febo.com/pipermail/time-nuts/attachments/20081224/4a474e8d/attachment-0001.zip > > > -- > 73s! > Esa > OH4KJU > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- ---------------------------------------------------------------------------------------------------- "Je hoeft het niet met elkaar eens te zijn om naar elkaar te luisteren." Ook van Loesje ---------------------------------------------------------------------------------------------------- From scifiscifi at sci.fi Mon Jan 26 12:46:21 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Mon, 26 Jan 2009 14:46:21 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <5323a8e30901260421x59aa6edbp443fbb1cf5a3acc7@mail.gmail.com> References: <7.0.1.0.1.20090126120330.01e95dd8@tapko.de> <497D9DE5.4080302@sci.fi> <5323a8e30901260421x59aa6edbp443fbb1cf5a3acc7@mail.gmail.com> Message-ID: <497DB09D.6080600@sci.fi> > Hallo Folkert, > Ik zag C, gps en source dus misschien iets voor jou Anteeksi mutta en ymm?rr? kielt?... :-) In english: Sorry, I do not understand that language. -- 73s! Esa OH4KJU From henk.termeer at gmail.com Mon Jan 26 12:49:50 2009 From: henk.termeer at gmail.com (Henk Termeer) Date: Mon, 26 Jan 2009 13:49:50 +0100 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497DB09D.6080600@sci.fi> References: <7.0.1.0.1.20090126120330.01e95dd8@tapko.de> <497D9DE5.4080302@sci.fi> <5323a8e30901260421x59aa6edbp443fbb1cf5a3acc7@mail.gmail.com> <497DB09D.6080600@sci.fi> Message-ID: <5323a8e30901260449w2ab7dd23tf314a02014047c0c@mail.gmail.com> Sorry, I hit the wrong button, Henk On Mon, Jan 26, 2009 at 1:46 PM, Esa Heikkinen wrote: > > Hallo Folkert, > > Ik zag C, gps en source dus misschien iets voor jou > > Anteeksi mutta en ymm?rr? kielt?... :-) > > In english: Sorry, I do not understand that language. > > -- > 73s! > Esa > OH4KJU > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- ---------------------------------------------------------------------------------------------------- "Je hoeft het niet met elkaar eens te zijn om naar elkaar te luisteren." Ook van Loesje ---------------------------------------------------------------------------------------------------- From bruce at w1bw.org Mon Jan 26 15:07:04 2009 From: bruce at w1bw.org (Bruce Walker) Date: Mon, 26 Jan 2009 10:07:04 -0500 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <497682B5.2080501@xtra.co.nz> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> Message-ID: I ran the same test as Bruce Griffiths on my tbolt; that is, I turned off osc disciplining altogether and created an OADEV plot from the internal phase measurements taken from its GPS solution. The plot is attached. It has a minimum of about 1e-11 at tau=800, and it has the sane general shape as Griffiths'. The next experiment I plan to do is to repeat the same thing using manual holdover mode rather than "Disable disciplining". That should continue to try to compensate for temperature and long-term drift (just not steered by GPS), whereas the data taken last night use a fixed DAC. --bruce W1BW -------------- next part -------------- A non-text attachment was scrubbed... Name: tbolt-no-discipline.png Type: image/png Size: 27247 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090126/2738da27/attachment-0001.png From yuri at ostry.ru Mon Jan 26 15:43:47 2009 From: yuri at ostry.ru (Yuri Ostry) Date: Mon, 26 Jan 2009 18:43:47 +0300 Subject: [time-nuts] Agilent 53132A Needs Help In-Reply-To: References: Message-ID: <12410362064.20090126184347@ostry.ru> Hello, Monday, January 26, 2009, 14:14:54, David wrote: D> I think I've seen seven Agilent 54132A counters and three of units flagged a D> ROM fault after Power On Self Test. They had all been well looked after, D> sitting in racks in a very high end environment, I suspect they were D> switched on continuously all year. The last statement may be a clue of D> course. When I worked with older CNC equipment (Fanuc, Bosch), after any occurence of checksum error we do a total refresh of all EPROMs in a unit. And the same was scheduled to each other routine yearly maintenance (i.e. we reprogrammed all EPROMs each 2 years just to be completely sure). Needless to say, that we had images of any and all EPROM chip archived. D> I did have a very brief play with the 'faulty' ones and things seemed to D> work after the fault message was acknowledged, I could not see any symptoms D> other than the self test error message. A nice counter but I'm D> getting ever more nervous about the ability of current test D> equipment to survive 5 to 10 years. I always try to keep known good images of all programmable chips from equipment I own, if it is possible.. It is already saved me from troubles with my Marconi 2955, where calibration EEPROM (Xicor X2816) failed one day... At the same time, I'm little nervous, too, about more modern equipment that have both firmware and calibration data on a single SMT flash chip. Or, that is even worse, on a some 1.8" HDD... A friend of mine already have Rohde & Schwarz cell phone tester with failed HDD, so internal harddrives is also on my "must be backed up" list now. OS/Firmware usually may be copied from similar unit, but calibration data is something unique and may be very expensive thing to recover. I already saved few various units with leaked EPROMs or parallel EEPROMs using method that I described earlier in this list, but I'm not so sure that it will work equally well with flash chips, so looks like it is better to have a full image on disk. -- Best regards, Yuri mailto:yuri at ostry.ru From bruce.griffiths at xtra.co.nz Mon Jan 26 19:05:30 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 27 Jan 2009 08:05:30 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> Message-ID: <497E097A.4070609@xtra.co.nz> Some idea of the shift in the minimum can be gleaned by plotting the Hadamard deviation vs tau. Bruce Walker wrote: > I ran the same test as Bruce Griffiths on my tbolt; that is, I turned off > osc disciplining altogether and created an OADEV plot from the internal > phase measurements taken from its GPS solution. The plot is attached. It > has a minimum of about 1e-11 at tau=800, and it has the sane general shape > as Griffiths'. > > The next experiment I plan to do is to repeat the same thing using manual > holdover mode rather than "Disable disciplining". That should continue to > try to compensate for temperature and long-term drift (just not steered by > GPS), whereas the data taken last night use a fixed DAC. > > --bruce W1BW > > From stanley_reynolds at yahoo.com Mon Jan 26 19:53:29 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Mon, 26 Jan 2009 11:53:29 -0800 (PST) Subject: [time-nuts] Datum 1000B OXCO Message-ID: <370301.40687.qm@web30308.mail.mud.yahoo.com> After several dissemble assemble cycles the oven heater started working, it is very slow reaching a stable frequency, about 12 hours. So maybe only one of the two transistors is working but this allows me to move on for now. The frequency was closer but I changed a 33 PF capacitor to about 20 Pf across the crystal to get to the 5+ Mhz. My hope is I can restore the original cap when the heater is repaired. My FTS 4040 is now ramping the frequency but not locking, I have hope as it starts with a wide range and closes in on the correct frequency +- a few counts so maybe the tube is very weak and not dead. Will wait and hope it repairs itself:-) Stanley From stanley_reynolds at yahoo.com Mon Jan 26 20:16:20 2009 From: stanley_reynolds at yahoo.com (Stanley Reynolds) Date: Mon, 26 Jan 2009 12:16:20 -0800 (PST) Subject: [time-nuts] Datum 1000B OXCO Message-ID: <666398.56187.qm@web30303.mail.mud.yahoo.com> After several dissemble assemble cycles the oven heater started working, it is very slow reaching a stable frequency, about 12 hours. So maybe only one of the two transistors is working but this allows me to move on for now. The frequency was closer but I changed a 33 PF capacitor to about 20 Pf across the crystal to get to the 5+ Mhz. My hope is I can restore the original cap when the heater is repaired. My FTS 4040 is now ramping the frequency but not locking, I have hope as it starts with a wide range and closes in on the correct frequency +- a few counts so maybe the tube is very weak and not dead. Will wait and hope it repairs itself:-) Stanley From bruce at w1bw.org Mon Jan 26 20:24:08 2009 From: bruce at w1bw.org (Bruce Walker) Date: Mon, 26 Jan 2009 15:24:08 -0500 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <497E097A.4070609@xtra.co.nz> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <497E097A.4070609@xtra.co.nz> Message-ID: Thanks for the suggestion. Here is a composite plot with Allan and Hadamard deviations for my tbolt run last night with disciplining disabled. I think I computed Hadamard correctly. OADEV (blue) has a minimum of 9.6e-12 around tau=790 OHDEV (red) has a minimum of 4.9e-12 around tau=1660 --bruce W1BW On Mon, Jan 26, 2009 at 2:05 PM, Bruce Griffiths wrote: > > Some idea of the shift in the minimum can be gleaned by plotting the > Hadamard deviation vs tau. > > Bruce Walker wrote: > > I ran the same test as Bruce Griffiths on my tbolt; that is, I turned off > > osc disciplining altogether and created an OADEV plot from the internal > > phase measurements taken from its GPS solution. The plot is attached. > It > > has a minimum of about 1e-11 at tau=800, and it has the sane general > shape > > as Griffiths'. > > > > The next experiment I plan to do is to repeat the same thing using manual > > holdover mode rather than "Disable disciplining". That should continue > to > > try to compensate for temperature and long-term drift (just not steered > by > > GPS), whereas the data taken last night use a fixed DAC. > > > > --bruce W1BW > > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -------------- next part -------------- A non-text attachment was scrubbed... Name: tbolt-allan-hadamard.png Type: image/png Size: 26995 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090126/9d89b965/attachment-0001.png From bruce.griffiths at xtra.co.nz Mon Jan 26 20:36:43 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 27 Jan 2009 09:36:43 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <497E097A.4070609@xtra.co.nz> Message-ID: <497E1EDB.2070903@xtra.co.nz> Bruce What was the record length? TOTDEV and TOTHadamard should give more reliable estimates over a greater tau range. Bias corrected Theo_1 and the Hadamard equivalent should be even better at longer tau. Bruce Bruce Walker wrote: > Thanks for the suggestion. Here is a composite plot with Allan and Hadamard > deviations for my tbolt run last night with disciplining disabled. I think > I computed Hadamard correctly. > > OADEV (blue) has a minimum of 9.6e-12 around tau=790 > OHDEV (red) has a minimum of 4.9e-12 around tau=1660 > > --bruce W1BW > > > On Mon, Jan 26, 2009 at 2:05 PM, Bruce Griffiths >> wrote: >> > > >> Some idea of the shift in the minimum can be gleaned by plotting the >> Hadamard deviation vs tau. >> >> Bruce Walker wrote: >> >>> I ran the same test as Bruce Griffiths on my tbolt; that is, I turned off >>> osc disciplining altogether and created an OADEV plot from the internal >>> phase measurements taken from its GPS solution. The plot is attached. >>> >> It >> >>> has a minimum of about 1e-11 at tau=800, and it has the sane general >>> >> shape >> >>> as Griffiths'. >>> >>> The next experiment I plan to do is to repeat the same thing using manual >>> holdover mode rather than "Disable disciplining". That should continue >>> >> to >> >>> try to compensate for temperature and long-term drift (just not steered >>> >> by >> >>> GPS), whereas the data taken last night use a fixed DAC. >>> >>> --bruce W1BW >>> >>> >>> From bruce at w1bw.org Mon Jan 26 21:31:08 2009 From: bruce at w1bw.org (Bruce Walker) Date: Mon, 26 Jan 2009 16:31:08 -0500 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: <497E1EDB.2070903@xtra.co.nz> References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <497E097A.4070609@xtra.co.nz> <497E1EDB.2070903@xtra.co.nz> Message-ID: The data I posted came from a 10 hour run collecting data every second. I could certainly set up other longer experiments. We quickly arrive at the limits of my experience...I had never looked at Hadamard deviation before. I was curious to see what I could learn about the Tbolt without having anything better to measure it against. For the time being, this is my "lab" reference. Let me see whether I understand what I've measured. The Allan intercept for my tbolt's undisciplined oscillator as measured by the onboard GPS solution is on order tau=800s. The Hadamard intercept under the same conditions appears to be more like 1600s. Does that tell me that if the disciplining model includes a drift compensation, the optimal disciplining time constant is close to the Hadamard intercept tau, but if there were no drift model, the Allan intercept would be more appropriate? And a primer or reference to the other statistical measures you mentioned (Theo_1, etc.) would be appreciated. --bruce W1BW On Mon, Jan 26, 2009 at 3:36 PM, Bruce Griffiths wrote: > > Bruce > > What was the record length? > > TOTDEV and TOTHadamard should give more reliable estimates over a > greater tau range. > > Bias corrected Theo_1 and the Hadamard equivalent should be even better > at longer tau. > > Bruce > > Bruce Walker wrote: > > Thanks for the suggestion. Here is a composite plot with Allan and Hadamard > > deviations for my tbolt run last night with disciplining disabled. I think > > I computed Hadamard correctly. > > > > OADEV (blue) has a minimum of 9.6e-12 around tau=790 > > OHDEV (red) has a minimum of 4.9e-12 around tau=1660 > > > > --bruce W1BW > > > > > > On Mon, Jan 26, 2009 at 2:05 PM, Bruce Griffiths > > >> wrote: > >> > > > > > >> Some idea of the shift in the minimum can be gleaned by plotting the > >> Hadamard deviation vs tau. > >> > >> Bruce Walker wrote: > >> > >>> I ran the same test as Bruce Griffiths on my tbolt; that is, I turned off > >>> osc disciplining altogether and created an OADEV plot from the internal > >>> phase measurements taken from its GPS solution. The plot is attached. > >>> > >> It > >> > >>> has a minimum of about 1e-11 at tau=800, and it has the sane general > >>> > >> shape > >> > >>> as Griffiths'. > >>> > >>> The next experiment I plan to do is to repeat the same thing using manual > >>> holdover mode rather than "Disable disciplining". That should continue > >>> > >> to > >> > >>> try to compensate for temperature and long-term drift (just not steered > >>> > >> by > >> > >>> GPS), whereas the data taken last night use a fixed DAC. > >>> > >>> --bruce W1BW > >>> > >>> > >>> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From holrum at hotmail.com Mon Jan 26 16:57:35 2009 From: holrum at hotmail.com (Mark Sims) Date: Mon, 26 Jan 2009 16:57:35 +0000 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: I think that the KALMAN setting of the filter is not actually available in the Thunderbolt. It is only supported in the Thunderbolt-E. ------------------ Thanks again. Just tested that (runs also with XP DOS mode) and it's great! Have to set some older laptop for this. It even shows me that the Kalman filter was still OFF, that information seems to be missing in tboltmon. _________________________________________________________________ Windows Live? Hotmail?:?more than just e-mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009 From holrum at hotmail.com Mon Jan 26 21:35:55 2009 From: holrum at hotmail.com (Mark Sims) Date: Mon, 26 Jan 2009 21:35:55 +0000 Subject: [time-nuts] Precision voltage to current conversion In-Reply-To: References: Message-ID: I recently picked up a Fluke 515A meter calibrator. It puts out 0-10V AC/DC (and 100V fixed) suitable for 4.5 - 5.5 digit meters. The DC voltage source impedance is around 300 ohms. I would like to build a (reasonably simple) converter to allow current ranges to be calibrated to around the same level of accuracy. A simple single op-amp floating load converter might do for low currents (I have some 0.001% 1K resistors that would make a nice 1ma/V converter). Can anybody recommend any other circuits? Also circuits for higher load currents? _________________________________________________________________ Windows Live?: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009 From bruce.griffiths at xtra.co.nz Mon Jan 26 22:01:17 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 27 Jan 2009 11:01:17 +1300 Subject: [time-nuts] Setting loop TC using thunderbolt internal data. In-Reply-To: References: <20090120.123535.3172.1.cdelect@juno.com> <43E9D43AA8B54962A2C444A87C935136@pc52> <497682B5.2080501@xtra.co.nz> <497E097A.4070609@xtra.co.nz> <497E1EDB.2070903@xtra.co.nz> Message-ID: <497E32AD.7060403@xtra.co.nz> Bruce If the Allan deviation plot is symmetric about the minimum then the Allan intercept and the minimum have the same value of tau. If the plot is asymmetric about the minimum then the Allan intercept and the minimum dont share the same value of tau. The shift is usually around 24% or less with the Allan intercept tau shifted to the steeper slope side of the minimum. The Hadamard deviation is insensitive to linear frequency drift, however it has a different phase noise transfer function than the Allan deviation. Thus the Hadamard minimum is at best indicative of the Allan intercept location when linear frequency drift is corrected. NIST SP1065 (http://tf.nist.gov/timefreq/general/pdf/2220.pdf) is a good starting point as it includes a comprehensive set of references. However one should bear in mind that ADEV, OADEV, TOTDEV, Theo_1 etc are merely estimators for the Allan deviation. ADEV is not the Allan deviation it is merely a poor estimator for it. The other estimators make progressively more effective use of the data. Bruce Bruce Walker wrote: > The data I posted came from a 10 hour run collecting data every > second. I could certainly set up other longer experiments. > > We quickly arrive at the limits of my experience...I had never looked > at Hadamard deviation before. I was curious to see what I could learn > about the Tbolt without having anything better to measure it against. > For the time being, this is my "lab" reference. > > Let me see whether I understand what I've measured. The Allan > intercept for my tbolt's undisciplined oscillator as measured by the > onboard GPS solution is on order tau=800s. The Hadamard intercept > under the same conditions appears to be more like 1600s. Does that > tell me that if the disciplining model includes a drift compensation, > the optimal disciplining time constant is close to the Hadamard > intercept tau, but if there were no drift model, the Allan intercept > would be more appropriate? > > And a primer or reference to the other statistical measures you > mentioned (Theo_1, etc.) would be appreciated. > > --bruce W1BW > > On Mon, Jan 26, 2009 at 3:36 PM, Bruce Griffiths > wrote: > >> Bruce >> >> What was the record length? >> >> TOTDEV and TOTHadamard should give more reliable estimates over a >> greater tau range. >> >> Bias corrected Theo_1 and the Hadamard equivalent should be even better >> at longer tau. >> >> Bruce >> >> Bruce Walker wrote: >> >>> Thanks for the suggestion. Here is a composite plot with Allan and Hadamard >>> deviations for my tbolt run last night with disciplining disabled. I think >>> I computed Hadamard correctly. >>> >>> OADEV (blue) has a minimum of 9.6e-12 around tau=790 >>> OHDEV (red) has a minimum of 4.9e-12 around tau=1660 >>> >>> --bruce W1BW >>> >>> >>> On Mon, Jan 26, 2009 at 2:05 PM, Bruce Griffiths >> >>> >>>> wrote: >>>> >>>> >>> >>>> Some idea of the shift in the minimum can be gleaned by plotting the >>>> Hadamard deviation vs tau. >>>> >>>> Bruce Walker wrote: >>>> >>>> >>>>> I ran the same test as Bruce Griffiths on my tbolt; that is, I turned off >>>>> osc disciplining altogether and created an OADEV plot from the internal >>>>> phase measurements taken from its GPS solution. The plot is attached. >>>>> >>>>> >>>> It >>>> >>>> >>>>> has a minimum of about 1e-11 at tau=800, and it has the sane general >>>>> >>>>> >>>> shape >>>> >>>> >>>>> as Griffiths'. >>>>> >>>>> The next experiment I plan to do is to repeat the same thing using manual >>>>> holdover mode rather than "Disable disciplining". That should continue >>>>> >>>>> >>>> to >>>> >>>> >>>>> try to compensate for temperature and long-term drift (just not steered >>>>> >>>>> >>>> by >>>> >>>> >>>>> GPS), whereas the data taken last night use a fixed DAC. >>>>> >>>>> --bruce W1BW >>>>> >>>>> >>>>> >>>>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From bruce.griffiths at xtra.co.nz Mon Jan 26 22:10:48 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 27 Jan 2009 11:10:48 +1300 Subject: [time-nuts] Precision voltage to current conversion In-Reply-To: References: Message-ID: <497E34E8.4020207@xtra.co.nz> Mark Sims wrote: > I recently picked up a Fluke 515A meter calibrator. It puts out 0-10V AC/DC (and 100V fixed) suitable for 4.5 - 5.5 digit meters. The DC voltage source impedance is around 300 ohms. I would like to build a (reasonably simple) converter to allow current ranges to be calibrated to around the same level of accuracy. A simple single op-amp floating load converter might do for low currents (I have some 0.001% 1K resistors that would make a nice 1ma/V converter). > > Can anybody recommend any other circuits? Also circuits for higher load currents? > Mark I presume you mean that the floating load constitutes the feedback impedance in an opamp inverter with the presision resistor forming the input resistor? If a floating load is OK, one can use a non inverting opamp with the precision shunt connected between the load and common. The other end of the load is driven by the opamp output (can include a high current output booster within the loop) and the inverting opamp input is connected to the upper sense terminal of the precision resistor. The source is connected to the opamp non inverting input. An inverting equivalent is also possible (may be more practical with a high voltage booster connected to the opamp output). Cancellation of the loading of the feedback resistor on the current sensing resistor is possible if an additional pamp is used. Bruce From bruce.griffiths at xtra.co.nz Mon Jan 26 22:14:12 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Tue, 27 Jan 2009 11:14:12 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <497E35B4.2070508@xtra.co.nz> Mark So why does the Thunderbolt distinguish between a fixed DAC voltage (as when the disciplining is turned off) and a corrected value (as in manual holdover). How does it learn the drift correction parameters without using a Kalman filter or its equivalent. Are you perhaps suggesting that the Tunderblt doesnt allow the Kalman filter to be manually enabled or disabled? Bruce Mark Sims wrote: > I think that the KALMAN setting of the filter is not actually available in the Thunderbolt. It is only supported in the Thunderbolt-E. > > > > ------------------ > > Thanks again. Just tested that (runs also with XP DOS mode) and it's > great! Have to set some older laptop for this. It even shows me that the > Kalman filter was still OFF, that information seems to be missing in > tboltmon. > > > _________________________________________________________________ > Windows Live? Hotmail?:?more than just e-mail. > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009 > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From philip at fliptronics.com Tue Jan 27 02:44:15 2009 From: philip at fliptronics.com (Philip Freidin) Date: Mon, 26 Jan 2009 18:44:15 -0800 Subject: [time-nuts] Looking for PDF of Getting Started Guide for HP 5372A In-Reply-To: References: Message-ID: As the title says, I greatly desire a copy of the Getting Started Guide for HP 5372A HP document number is 05372-90010 I've looked in the normal sites, including Agilent, but no luck so far. I found one at a pay site, but am hoping to find a free copy. I currently have these PDF files (from Agilent site): 05372-90016 Service manual 4/1990 453 pages 05372-90016 Service manual update 1/1993 145 pages 05372-90032 Opt 40 jitter spectrum 8/1991 194 pages 05372-90035 Operating manual 5/1995 687 pages 05372-90036 Programming manual 10/1992 485 pages 5952-8012 Condensed reference and spec 10/1989 102 pages Thanks for any help, Philip From ed_palmer at sasktel.net Tue Jan 27 03:41:56 2009 From: ed_palmer at sasktel.net (Ed Palmer) Date: Mon, 26 Jan 2009 21:41:56 -0600 Subject: [time-nuts] Looking for PDF of Getting Started Guide for HP 5372A In-Reply-To: References: Message-ID: <497E8284.50503@sasktel.net> Philip, you beat me to it. I was about to make the same request. FYI, earlier posts suggested emailing manuals at agilent.com . I did this some months ago with no response. According to the Condensed Reference & Specification Guide, the part number for the Getting Started Guide is 5952-8009. Doesn't really matter. I couldn't find either number. :-) Ed Philip Freidin wrote: > As the title says, I greatly desire a copy of the > Getting Started Guide for HP 5372A > > HP document number is 05372-90010 > > I've looked in the normal sites, including Agilent, but no > luck so far. > > I found one at a pay site, but am hoping to find a free copy. > > I currently have these PDF files (from Agilent site): > > 05372-90016 Service manual 4/1990 453 pages > 05372-90016 Service manual update 1/1993 145 pages > 05372-90032 Opt 40 jitter spectrum 8/1991 194 pages > 05372-90035 Operating manual 5/1995 687 pages > 05372-90036 Programming manual 10/1992 485 pages > 5952-8012 Condensed reference and spec 10/1989 102 pages > > Thanks for any help, > Philip > > > > > > ------------------------------ > > _______________________________________________ > time-nuts mailing list > time-nuts at febo.com > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > End of time-nuts Digest, Vol 54, Issue 107 > ****************************************** > From scifiscifi at sci.fi Tue Jan 27 16:33:30 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Tue, 27 Jan 2009 18:33:30 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <27FEC61EB60E446B9C20943123DCDEA6@pc52> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> Message-ID: <497F375A.80904@sci.fi> Hello again... > Right, it all depends on what stability you're after. The OCXO > will have much better short-term stability than the LPRO -- the > LPRO is close to ten times worse. So do not replace the TBolt > OCXO with a LPRO if short-term stability is your goal. See: I'm wondering what could be the cause of this. According to operating manual LPRO's output should be crystal oscillator (VCXO) generated signal, which is synchronized to rubidium. So why it is so much worse than any other crystal oscillator (or other Rd oscillators). Are there any schematics for LPRO available anywhere? I cannot see the any phase noise difference between Trimble's OCXO and LPRO with spectrum analyser. Measured with different spans from 500 kHz to 200 Hz, using resolution bandwiths 300 Hz to 6 Hz. So the noise which is causing bad short term drift must be very close to fundamental. It seems that only way to see this noise is to use phase detector circuit but my problem with that is that I haven't got any good reference for it and this kind of equipments are quite hard to find here in Finland. It would be nice to see what kind of noise there are, to design the filter bandwith for external OCXO lock circuit. Other idea to bring that noise visible could be multiplying it with some kind of comb generator circuit (might be hard to build one). Then it would be possible to measure it's harmonics. Not sure if there's enough level present anymore at GHz frequencies... What kind of test setup did you use when getting this result: > LPRO plots: > http://www.leapsecond.com/museum/lpro/ -- 73s! Esa OH4KJU From phill.r1 at btinternet.com Tue Jan 27 16:47:31 2009 From: phill.r1 at btinternet.com (Roy Phillips) Date: Tue, 27 Jan 2009 16:47:31 -0000 Subject: [time-nuts] Looking for PDF of Getting Started Guide for HP 5372A In-Reply-To: References: Message-ID: Philip You will also find the 05372-90001 is on offer at the Agilent site - has this been added since your last visit ? Roy ----- Original Message ----- From: "Philip Freidin" To: Sent: Tuesday, January 27, 2009 2:44 AM Subject: [time-nuts] Looking for PDF of Getting Started Guide for HP 5372A > > As the title says, I greatly desire a copy of the > Getting Started Guide for HP 5372A > > HP document number is 05372-90010 > > I've looked in the normal sites, including Agilent, but no > luck so far. > > I found one at a pay site, but am hoping to find a free copy. > > I currently have these PDF files (from Agilent site): > > 05372-90016 Service manual 4/1990 453 pages > 05372-90016 Service manual update 1/1993 145 pages > 05372-90032 Opt 40 jitter spectrum 8/1991 194 pages > 05372-90035 Operating manual 5/1995 687 pages > 05372-90036 Programming manual 10/1992 485 pages > 5952-8012 Condensed reference and spec 10/1989 102 pages > > Thanks for any help, > Philip > > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From philipadavies2004 at tiscali.co.uk Tue Jan 27 18:04:07 2009 From: philipadavies2004 at tiscali.co.uk (Philip Davies) Date: Tue, 27 Jan 2009 18:04:07 -0000 Subject: [time-nuts] Dear Sir you are looking for Manuals for the HP 5372A In-Reply-To: References: Message-ID: <6B350E49D62F459C8824C088894A4FC9@PhilipLaptop> Dear Sir You are looking for a manual for the HP 5372A Try this link http://www.home.agilent.com/agilent/facet.jspx?t=80039.k.1&ki[0]=5372A&cc=US &lc=eng&sm=g Best Regards Philip Davies Today's Topics: 1. Re: Looking for PDF of Getting Started Guide for HP 5372A (Ed Palmer) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Jan 2009 21:41:56 -0600 From: Ed Palmer Subject: Re: [time-nuts] Looking for PDF of Getting Started Guide for HP 5372A To: time-nuts at febo.com Message-ID: <497E8284.50503 at sasktel.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Philip, you beat me to it. I was about to make the same request. FYI, earlier posts suggested emailing manuals at agilent.com . I did this some months ago with no response. According to the Condensed Reference & Specification Guide, the part number for the Getting Started Guide is 5952-8009. Doesn't really matter. I couldn't find either number. :-) Ed Philip Freidin wrote: > As the title says, I greatly desire a copy of the > Getting Started Guide for HP 5372A > > HP document number is 05372-90010 > > I've looked in the normal sites, including Agilent, but no > luck so far. > > I found one at a pay site, but am hoping to find a free copy. > > I currently have these PDF files (from Agilent site): > > 05372-90016 Service manual 4/1990 453 pages > 05372-90016 Service manual update 1/1993 145 pages > 05372-90032 Opt 40 jitter spectrum 8/1991 194 pages > 05372-90035 Operating manual 5/1995 687 pages > 05372-90036 Programming manual 10/1992 485 pages > 5952-8012 Condensed reference and spec 10/1989 102 pages > > Thanks for any help, > Philip > > > > > > ------------------------------ > > _______________________________________________ > time-nuts mailing list > time-nuts at febo.com > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > End of time-nuts Digest, Vol 54, Issue 107 > ****************************************** > ------------------------------ _______________________________________________ time-nuts mailing list time-nuts at febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts End of time-nuts Digest, Vol 54, Issue 108 ****************************************** From holrum at hotmail.com Mon Jan 26 18:27:00 2009 From: holrum at hotmail.com (Mark Sims) Date: Mon, 26 Jan 2009 18:27:00 +0000 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: One thing you may be able to do if you can find and old, klunky, bulky enough laptop is to install the Thunderbolt in the laptop CDROM bay. A friend of mine did this and it worked out great. Since he powers the tbolt off of the laptop internal power, the tbolt is automatically battery backed up. If you are a noise fiend, you may want to install some additional filtering to the tbolt power. If your laptop is too modern, there is probably not enough space to install the tbolt internally. You could then mount the tbolt to the laptop case and run the power out to it. Even more modern laptops may not have a strong enough 12V supply to warm up the tbolt oven. ------------------- Thanks again. Just tested that (runs also with XP DOS mode) and it's great! Have to set some older laptop for this. It even shows me that the Kalman filter was still OFF, that information seems to be missing in tboltmon. _________________________________________________________________ Hotmail? goes where you go. On a PC, on the Web, on your phone. http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208 From holrum at hotmail.com Tue Jan 27 03:21:37 2009 From: holrum at hotmail.com (Mark Sims) Date: Tue, 27 Jan 2009 03:21:37 +0000 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: Hello Bruce, The Thunderbolt documents four filters that you can enable (PV, ALTITUDE, STATIC, and KALMAN). The KALMAN setting is not documented for the regular Thunderbolt. The Thunderbolt-E lists it as being available. Lady Heather gray's out the option unless you have a -E (but does let you try and set it if you have a normal Thunderbolt, no telling if it actually does anything). I think these filters are for receiver dynamics and not oscillator disciplining. Mark _________________________________________________________________ Hotmail? goes where you go. On a PC, on the Web, on your phone. http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208 From bruce.griffiths at xtra.co.nz Tue Jan 27 20:09:12 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 28 Jan 2009 09:09:12 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497F375A.80904@sci.fi> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> <497F375A.80904@sci.fi> Message-ID: <497F69E8.6070403@xtra.co.nz> Esa Wenzel has a introduction to low cost phase noise measurement at: http://www.wenzel.com/documents/measuringphasenoise.htm Its relatively easy to assemble such a system. A PC sound card can be used as a spectrum analyser for measuring phase noise to within a few Hz of the carrier. There are low noise amplifiers with lower flicker noise than Wenzel's low noise FET input audio amplifier . It is also possible to build a variant of Wenzel's amplifier that doesnt require selection of JFETs. If one wishes to measure the Allan variance of an oscillator, the 3 cornered hat technique can be used with 3 oscillators having similar performance. For longer tau (1000sec or more depending on the OCXO being characterised) the PPS output of a good gps timing receiver can be used as a reference. However a clear view of the southern sky is required, Bruce Esa Heikkinen wrote: > Hello again... > > >> Right, it all depends on what stability you're after. The OCXO >> will have much better short-term stability than the LPRO -- the >> LPRO is close to ten times worse. So do not replace the TBolt >> OCXO with a LPRO if short-term stability is your goal. See: >> > > I'm wondering what could be the cause of this. According to operating > manual LPRO's output should be crystal oscillator (VCXO) generated > signal, which is synchronized to rubidium. So why it is so much worse > than any other crystal oscillator (or other Rd oscillators). Are there > any schematics for LPRO available anywhere? > > I cannot see the any phase noise difference between Trimble's OCXO and > LPRO with spectrum analyser. Measured with different spans from 500 kHz > to 200 Hz, using resolution bandwiths 300 Hz to 6 Hz. So the noise which > is causing bad short term drift must be very close to fundamental. > > It seems that only way to see this noise is to use phase detector > circuit but my problem with that is that I haven't got any good > reference for it and this kind of equipments are quite hard to find here > in Finland. It would be nice to see what kind of noise there are, to > design the filter bandwith for external OCXO lock circuit. > > Other idea to bring that noise visible could be multiplying it with some > kind of comb generator circuit (might be hard to build one). Then it > would be possible to measure it's harmonics. Not sure if there's enough > level present anymore at GHz frequencies... > > What kind of test setup did you use when getting this result: > > LPRO plots: > > http://www.leapsecond.com/museum/lpro/ > > From bruce.griffiths at xtra.co.nz Tue Jan 27 20:16:35 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Wed, 28 Jan 2009 09:16:35 +1300 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <497F6BA3.1080006@xtra.co.nz> Mark Sims wrote: > Hello Bruce, > The Thunderbolt documents four filters that you can enable (PV, ALTITUDE, STATIC, and KALMAN). The KALMAN setting is not documented for the regular Thunderbolt. The Thunderbolt-E lists it as being available. Lady Heather gray's out the option unless you have a -E (but does let you try and set it if you have a normal Thunderbolt, no telling if it actually does anything). I think these filters are for receiver dynamics and not oscillator disciplining. > Mark > Mark A Kalman filter is built in to the Thunderbolt, you just cant directly turn it on or off or set its parameters. A Kalman filter is used to measure and store the frequency drift and temperature drift characteristics of the OCXO and use them to improve the holdover performance. The altitude filter allows the GPS receiver to ignore GPS SVs whose altitude is too low. The static mode is for fixed position operation where either a manually entered or an auto surveyed fixed position is used by the GPS receiver. This allows timing information to be derived from a single visible GPS SV. When more SVs are usable more accurate timing information can be derived. Bruce From scifiscifi at sci.fi Tue Jan 27 22:45:41 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Wed, 28 Jan 2009 00:45:41 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497F69E8.6070403@xtra.co.nz> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> <497F375A.80904@sci.fi> <497F69E8.6070403@xtra.co.nz> Message-ID: <497F8E95.6020008@sci.fi> > Its relatively easy to assemble such a system. > A PC sound card can be used as a spectrum analyser for measuring phase > noise to within a few Hz of the carrier. I still need some high quality reference oscillator. Do you have any clue how much those Wenzel oscillators cost? There wasn't any prices on website, may be the only way is to ask? There seems to be interesting alternatives for the output oscillator too (to clean the LPRO signal). One of those was even named "timekeeper". Maybe it could be wise to buy one and use it for phase noise measurement first and then put it in permament use as the output oscillator of the reference, when the desired loop bandwith is known. But of course if those units has price tag with four figures or so then this is only daydreaming... :-) -- 73s! Esa OH4KJU From james.p.lux at jpl.nasa.gov Tue Jan 27 22:58:26 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Tue, 27 Jan 2009 14:58:26 -0800 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497F8E95.6020008@sci.fi> References: <497C7915.3040409@sci.fi> <27FEC61EB60E446B9C20943123DCDEA6@pc52> <497F375A.80904@sci.fi> <497F69E8.6070403@xtra.co.nz> <497F8E95.6020008@sci.fi> Message-ID: > -----Original Message----- > From: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] On Behalf Of Esa Heikkinen > Sent: Tuesday, January 27, 2009 2:46 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Home made GPS disciplined atomic clock > > > Its relatively easy to assemble such a system. > > A PC sound card can be used as a spectrum analyser for > measuring phase > > noise to within a few Hz of the carrier. > > I still need some high quality reference oscillator. Do you > have any clue how much those Wenzel oscillators cost? There > wasn't any prices on website, may be the only way is to ask? The run of the mill Wenzel "Streamline" series runs about $250 each. http://www.wenzel.com/pdffiles1/Oscillators/STR_4_to_30.pdf > > There seems to be interesting alternatives for the output > oscillator too (to clean the LPRO signal). One of those was > even named "timekeeper". Wenzel sells "cleanup loops" as a packaged device for a variety of frequencies. > > Maybe it could be wise to buy one and use it for phase noise > measurement first and then put it in permament use as the > output oscillator of the reference, when the desired loop > bandwith is known. > > But of course if those units has price tag with four figures > or so then this is only daydreaming... :-) I would imagine a packaged cleanup loop (oscillator and PLL) is right around $1K. I can't recall what we paid for our 10MHz widgets a few years back, but that seems about right. Clearly, one can build it yourself for less (e.g. you could use a $250 oscillator and use a PLL eval board of some sort to drive the EFC input, for instance) , but that's only if your time is free. Send Wenzel an email and ask.. From sar10538 at gmail.com Wed Jan 28 04:46:09 2009 From: sar10538 at gmail.com (Steve Rooke) Date: Wed, 28 Jan 2009 17:46:09 +1300 Subject: [time-nuts] Info needed for Toyocom ocxo Message-ID: <1231b6a80901272046o5ec39b53pea8ece6136af02f1@mail.gmail.com> Does anyone have a datasheet for a: Toyocom Crystal Osc. TCO-600 Spec. No. MPS-Q-202B Serial No. K 2390 Date June/82 Freq. 29.052000MHz please? 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet From df6jb at ulrich-bangert.de Wed Jan 28 08:16:59 2009 From: df6jb at ulrich-bangert.de (Ulrich Bangert) Date: Wed, 28 Jan 2009 09:16:59 +0100 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: <497F375A.80904@sci.fi> Message-ID: Esa, > I'm wondering what could be the cause of this. According to operating > manual LPRO's output should be crystal oscillator (VCXO) generated > signal, which is synchronized to rubidium. So it is! But the detection process of the "atomic lock" is "noisy" itself. That makes it necessary to have low pass filters in this pll that make the overall noise dependend from the xtal oscillator's noise at short observation times. If you consider that a typical "normal" xtal oscillator (no oven, no temperature compensation) has an Allan deviation of 5E-8 @ 1 s then you see that 1E-11 @ 1 s IS ALREADY a BIG improvement above the "normal" case. 1E-12 @ 1 s is near the best that amateur money can buy. A lot of high grade OCXOs will be >1E-12 and <1E-11 @ 1 s and VERY FEW will be <1E-12 @ 1 s 73s Ulrich, DF6JB > -----Ursprungliche Nachricht----- > Von: time-nuts-bounces at febo.com > [mailto:time-nuts-bounces at febo.com] Im Auftrag von Esa Heikkinen > Gesendet: Dienstag, 27. Januar 2009 17:34 > An: Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] Home made GPS disciplined atomic clock > > > Hello again... > > > Right, it all depends on what stability you're after. The OCXO will > > have much better short-term stability than the LPRO -- the LPRO is > > close to ten times worse. So do not replace the TBolt OCXO > with a LPRO > > if short-term stability is your goal. See: > > I'm wondering what could be the cause of this. According to operating > manual LPRO's output should be crystal oscillator (VCXO) generated > signal, which is synchronized to rubidium. So why it is so much worse > than any other crystal oscillator (or other Rd oscillators). > Are there > any schematics for LPRO available anywhere? > > I cannot see the any phase noise difference between Trimble's > OCXO and > LPRO with spectrum analyser. Measured with different spans > from 500 kHz > to 200 Hz, using resolution bandwiths 300 Hz to 6 Hz. So the > noise which > is causing bad short term drift must be very close to fundamental. > > It seems that only way to see this noise is to use phase detector > circuit but my problem with that is that I haven't got any good > reference for it and this kind of equipments are quite hard > to find here > in Finland. It would be nice to see what kind of noise there are, to > design the filter bandwith for external OCXO lock circuit. > > Other idea to bring that noise visible could be multiplying > it with some > kind of comb generator circuit (might be hard to build one). Then it > would be possible to measure it's harmonics. Not sure if > there's enough > level present anymore at GHz frequencies... > > What kind of test setup did you use when getting this result: > > LPRO plots: > > http://www.leapsecond.com/museum/lpro/ > > -- > 73s! > Esa > OH4KJU > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > and > follow the instructions there. > From EWKehren at aol.com Wed Jan 28 11:30:19 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Wed, 28 Jan 2009 06:30:19 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: Esa, the answer to your problem is, as I said before, to clean up the signal, use a high quality oscillator locked to your system with a PLL that has the appropriate time constant. The time constant will smooth out the jumps you see right now. The question is only which oscillator. A Wenzel was suggested but in my opinion it is not what you need. I have used a Wenzel because I wanted the low phase noise when multiplied to 10 Ghz. You would pay for something you do not need. I have not seen Allan variance data on them. There are plenty of oscillators out there at a reasonable price starting with the HP 10544. Yes, the 10544 will clean up your present setup and will be at least a 10X improvement over the LPRO solution. But the most widely available unit is the HP 10811 which will do a great job. Depending on how much you want to spend the FTS 1200, 1000 or 2000 are an option. Bert WB5MZJ **************A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100000075x1215855013x1201028747/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=De cemailfooterNO62) From scifiscifi at sci.fi Wed Jan 28 13:06:31 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Wed, 28 Jan 2009 15:06:31 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <49805857.5000406@sci.fi> > Esa, the answer to your problem is, as I said before, to clean up the > signal, use a high quality oscillator locked to your system with a PLL that has > the appropriate time constant. Yes. My problem is to find time constants, with measurements and that's currently under work with GPS, later with LPRO. I've done some HW and SW planning also. It could be like this: - Tbolt is used to synchronize LPRO with own designed steering system. - LPRO steering time constant will be long, let's say 24h or something, to cancel out any day/night variations (if any) on GPS reception. - The goal for LPRO synchronization is to have constant frequency, not exact time. This will ease the LPRO steering algorithm and there's no need to catch up the exact time by changing the output frequency (like tbolt always does). - Own steering electronics will constantly monitor the state of tbolt with serial port. If holdover is detected then the LRPO steering will also be stopped and averaging loop will be reset. DAC remains as it was. - When the holdover is over the running averaging will be started again but C-field DAC will remain as it was until there's enough data for last 24h to do some C-field corrections. - It might be a good idea to reset the steering also if the frequency error (ppt value) of Tbolt's 10 MHz output is detected to be too high. - Steering MCU uses LPRO as it's clock because it will count it. MCU's HW peripherals like counters and capture unit is used to handle the 10 MHz count, the software just reads out the counter values occassionally. - The counters are read only every n'th:s PPS so that mHz resolution can be achieved without using external frequency multipliers etc. Also the PPS drift will be averaged this way. The n could be at least 3600. - These counted values are used as input data to running avg having a long time constant such as 24h or even more. - So the period for DAC changes will depend how long counts (in seconds) is done at first stage. It's sure that the DAC won't be changed here in about every second like Tbolt does! - Then LPRO's output is cleaned with Wenzel or some other OCXO, with suitable time constant which has to be find out. Phase detector and good reference OCXO is needed for that. May be it's wise to buy only one OCXO and use it for measurements frist and then as output oscillator for final setup. - Finally there will be some kind of distribution amplifier for 10 MHz. So it will be slow to settle but should be good enough for stable 10 MHz source. I think it will have good long term stability due GPS, good holdover performance and if the final OCXO cleanup works as excepted there will it should also have good short term stability. Much work to do but for now this is only a hobby project. > The time constant will smooth out the jumps you > see right now. The question is only which oscillator. A Wenzel was suggested > but in my opinion it is not what you need. The output phase noise may be not so bad issue as it sounds like. It seems that some RF instruments (like my spectrum analyzer) have their own clean up loops for external ref. Only problem is that their time constants are unknown. But it's in there - at least in spectrum analyzer; checked that from service manual yesterday. > I have used a Wenzel because I wanted the low phase noise when multiplied > to 10 Ghz. In these days my maximum needed frequency in about 5.2 GHz so any error on 10 MHz ref will be multiplied by 520. For that reason I also want CONSTANT frequency, it's not so bad if it's off ?1 mHz at some day but it's very bad if it has different frequency error between measurements done on same day. So I'd like to drive that DAC as rarely as possible and as little steps as possible. May be even only one correction per day, done at nighttime when there are no measurements on going.. There will be LCD screen for status so it could also told the actual frequency difference to averaged GPS reference but without any DAC changes if they are not desired that time. > plenty of oscillators out there at a reasonable price starting with > the HP 10544. Yes, the 10544 will clean up your present setup and > will be at least > a 10X improvement over the LPRO solution. But > the most widely available unit is the HP 10811 which will do > a great job. Haven't seen those available here in Finland. We have much too fanatic "recycling" on going on Finland and so even fully working electronics are doomed to be destroyed (shredded to get the metals out of them). One friend has seen his own eyes the destroying of only couple of years old servers etc. Madness! And any plastic material remained for this process is dumped as huge lumps for next generations. Saves nature indeed! All thanks to this goes to one company which just want to "recycle" metal and export it to china. So there's no such "treasures" here which you guys have in US (according the stories on your websites). Also it's quite expensive to order things outside EU unless there are some friend who could handle the purchase locally and then send the items as a "gift". Some surplus stuff is of course available here but the sellers are asking quite high prices. For example, old used LPRO's will cost about 200 euros each, Tbolt will cost about same amount, and so on. 1 eur = 1.32 US dollar. > Depending on how much you want to spend > the FTS 1200, 1000 or 2000 are an option. I think that the money is not so big problem that as the poor availibilty of this kind of stuff here in Finland. -- 73s! Esa OH4KJU From jra at febo.com Wed Jan 28 13:17:17 2009 From: jra at febo.com (John Ackermann N8UR) Date: Wed, 28 Jan 2009 08:17:17 -0500 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <49805ADD.5000907@febo.com> Except at very short tau (measurement interval), the Wenzel oscillator ADEV (at least the Ultra Low Noise versions) is nothing to write home about compared to something like a surplus 10811A. Designing for absolute phase noise isn't necessarily consistent with designing for longer term stability. John ---- EWKehren at aol.com said the following on 01/28/2009 06:30 AM: > Esa, the answer to your problem is, as I said before, to clean up the > signal, use a high quality oscillator locked to your system with a PLL that has > the appropriate time constant. The time constant will smooth out the jumps you > see right now. The question is only which oscillator. A Wenzel was suggested > but in my opinion it is not what you need. I have used a Wenzel because I > wanted the low phase noise when multiplied to 10 Ghz. You would pay for something > you do not need. I have not seen Allan variance data on them. There are > plenty of oscillators out there at a reasonable price starting with the HP 10544. > Yes, the 10544 will clean up your present setup and will be at least a 10X > improvement over the LPRO solution. But the most widely available unit is the > HP 10811 which will do a great job. Depending on how much you want to spend > the FTS 1200, 1000 or 2000 are an option. > Bert WB5MZJ > **************A Good Credit Score is 700 or Above. See yours in just 2 easy > steps! > (http://pr.atwola.com/promoclk/100000075x1215855013x1201028747/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=De > cemailfooterNO62) > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From EWKehren at aol.com Wed Jan 28 13:41:45 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Wed, 28 Jan 2009 08:41:45 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: Esa, once you have a finite plan I am sure we can get it to you. I have regular visitors coming from Germany and I could ask them to take it back and ship it from Germany. My cousins son is here till Febr. 18 and could take it. Miami is in the winter a very popular place. Today it will be 25 C. Bert **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From scifiscifi at sci.fi Wed Jan 28 14:15:06 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Wed, 28 Jan 2009 16:15:06 +0200 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: <4980686A.9040404@sci.fi> > Esa, once you have a finite plan I am sure we can get it to you. Hard to say nothing yet... but time tells if it works or not.. :) It's just a plan. > regular visitors coming from Germany and I could ask them to take it back and > ship it from Germany. Yes that's inside EU so that makes things a lot easier! I think the HP 10544 you mentioned about would fullfill my needs as cleanup osc, if I only will get a change to buy one... > My cousins son is here till Febr. 18 and could take it. Because this is a hobby project there are no hurry with schedule. So this is fine. > Miami is in the winter a very popular place. Today it will be 25 C. Oh yes! Here it's so cold and dark right now... -3.85 C In weather forecasts the say that it'll be -16...-20 at weekend! But one thing that you can enjoy there is skiing... :-) -- 73s! Esa OH4KJU From EWKehren at aol.com Wed Jan 28 14:34:06 2009 From: EWKehren at aol.com (EWKehren at aol.com) Date: Wed, 28 Jan 2009 09:34:06 EST Subject: [time-nuts] Home made GPS disciplined atomic clock Message-ID: I know what that is all about I did spend my young days in Halmstad Sweden. I will get a 10544 and we can communicate direct. My Email is _Ewkehren at AOL.com_ (mailto:Ewkehren at AOL.com) Bert **************Know Your Numbers: Get tips and tools to help you improve your credit score. (http://www.walletpop.com/credit/credit-reports?ncid=emlcntuswall00000002) From marc at msys.ch Wed Jan 28 14:38:28 2009 From: marc at msys.ch (Marc Balmer) Date: Wed, 28 Jan 2009 15:38:28 +0100 Subject: [time-nuts] TELMAT RMS 162 Message-ID: <20090128143828.GC29670@mail.msys.ch> Does anyone on this list happen to have any information about the TELMAT RMS 162 receiver that decodes the France Inter signal on 162 kHz? I am interested in hardware manuals as well as in information on the serial protocol. - Marc Balmer -- Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland http://www.msys.ch/ http://www.vnode.ch/ "In God we trust, in C we code." From holrum at hotmail.com Wed Jan 28 17:00:53 2009 From: holrum at hotmail.com (Mark Sims) Date: Wed, 28 Jan 2009 17:00:53 +0000 Subject: [time-nuts] Home made GPS disciplined atomic clock In-Reply-To: References: Message-ID: I bought a couple of those UCT 108663 (aka Oscilloquartz 8663) double oven OCXO cans off of Ebay for $30 each shipped from China. Tiny little devils, easy to use. Short term ADEVs seem to be in the 1E-12 range (spec is 1E-12 and _________________________________________________________________ Windows Live?: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009 From scifiscifi at sci.fi Thu Jan 29 23:35:14 2009 From: scifiscifi at sci.fi (Esa Heikkinen) Date: Fri, 30 Jan 2009 01:35:14 +0200 Subject: [time-nuts] Some results of Tbolt + LPRO case Message-ID: <49823D32.6070002@sci.fi> Hi! Although this will not be my final setup the measurements had already started with "Tbolt OCXO replaced by LPRO" and are now done. I think some of you might be interested of the results. Here's some Lady Heather logfiles and couple of pictures. Unmodified Thunderbolt in my place (many trees at the yard etc): http://www.amigazone.fi/files/gpsdo/tbolt-default.log http://www.amigazone.fi/files/gpsdo/tbolt-normal.jpg (Includes short holdover test at the end) Unmodified Thunderbolt in holdover mode: http://www.amigazone.fi/files/gpsdo/tbolt-holdover.log Unmodified Thunderbolt OCXO performance (disciplining off): http://www.amigazone.fi/files/gpsdo/tbolt-ocxo-freerun.log OCXO now replaced with LPRO, normal run: http://www.amigazone.fi/files/gpsdo/tbolt+lpro.log OCXO replaced with LPRO, disciplining turned off: http://www.amigazone.fi/files/gpsdo/tbolt+lpro-freerun.log http://www.amigazone.fi/files/gpsdo/tbolt+lpro-freerun.jpg This final test simulates my planned setup (without final cleaning loop however). Next thing is to try to get some ADEV charts with Ulrich's Plotter. For some reason it shows only e-1 values for now, the actual shape of the trace looks ok. Have to learn about the settings... -- 73s! Esa OH4KJU From bruce.griffiths at xtra.co.nz Fri Jan 30 00:10:18 2009 From: bruce.griffiths at xtra.co.nz (Bruce Griffiths) Date: Fri, 30 Jan 2009 13:10:18 +1300 Subject: [time-nuts] Some results of Tbolt + LPRO case In-Reply-To: <49823D32.6070002@sci.fi> References: <49823D32.6070002@sci.fi> Message-ID: <4982456A.5000006@xtra.co.nz> Esa Heikkinen wrote: > Hi! > > Although this will not be my final setup the measurements had already > started with "Tbolt OCXO replaced by LPRO" and are now done. I think > some of you might be interested of the results. > > Here's some Lady Heather logfiles and couple of pictures. > > Unmodified Thunderbolt in my place (many trees at the yard etc): > http://www.amigazone.fi/files/gpsdo/tbolt-default.log > http://www.amigazone.fi/files/gpsdo/tbolt-normal.jpg > (Includes short holdover test at the end) > > Unmodified Thunderbolt in holdover mode: > http://www.amigazone.fi/files/gpsdo/tbolt-holdover.log > > Unmodified Thunderbolt OCXO performance (disciplining off): > http://www.amigazone.fi/files/gpsdo/tbolt-ocxo-freerun.log > > OCXO now replaced with LPRO, normal run: > http://www.amigazone.fi/files/gpsdo/tbolt+lpro.log > > OCXO replaced with LPRO, disciplining turned off: > http://www.amigazone.fi/files/gpsdo/tbolt+lpro-freerun.log > http://www.amigazone.fi/files/gpsdo/tbolt+lpro-freerun.jpg > > This final test simulates my planned setup (without final cleaning loop > however). > > Next thing is to try to get some ADEV charts with Ulrich's Plotter. For > some reason it shows only e-1 values for now, the actual shape of the > trace looks ok. Have to learn about the settings... > > Esa The first thing you have to do when using PLOTTER is to scale the phase values (they are in nanoseconds). Simply set the coefficient of y to 1.000E-9 in the scale dialog. With only 20,000 or so phase values the estimator OADEV degrades considerably in accuracy for tau > ~2000 sec or so, TOTDEV is better in this respect. THEO_1 and its variants are even better estimators in that they make more effective use of the available data. Bruce From mctylr at gmail.com Fri Jan 30 00:22:11 2009 From: mctylr at gmail.com (michael taylor) Date: Thu, 29 Jan 2009 19:22:11 -0500 Subject: [time-nuts] Canada's 5,000 year old calendar Message-ID: <25630a120901291622l5cc165ecna06e01cc3de52a39@mail.gmail.com> I'm not sure how "accepted" the claim is, but apparently is made national media in one of two major Canadian national daily newspapers, The Globe and Mail with the article "Canada's Stonehenge" by Bob Weber January 29, 2009. An academic maverick is challenging conventional wisdom on Canada's prehistory by claiming an archeological site in southern Alberta is really a vast, open-air sun temple with a precise 5,000-year-old calendar predating England's Stonehenge and Egypt's pyramids. Mainstream archeologists consider the rock-encircled cairn to be just another medicine wheel left behind by early aboriginals. But a new book by retired University of Alberta professor Gordon Freeman says it is in fact the centre of a 26-square-kilometre stone "lacework" that marks the changing seasons and the phases of the moon with greater accuracy than our current calendar. ... Professor Dr. Gordon Freeman's university web page And a related web site relating to the book mentioned in the article. - _Canada's Stonehenge_ By Gordon Freeman ISBN 978-0-978-4526-1-2 Since we had some discussion about historic calendars earlier this year, I thought it might of interest here. -Michael From imp at bsdimp.com Fri Jan 30 01:03:05 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu, 29 Jan 2009 18:03:05 -0700 (MST) Subject: [time-nuts] Canada's 5,000 year old calendar In-Reply-To: <25630a120901291622l5cc165ecna06e01cc3de52a39@mail.gmail.com> References: <25630a120901291622l5cc165ecna06e01cc3de52a39@mail.gmail.com> Message-ID: <20090129.180305.-142971468.imp@bsdimp.com> In message: <25630a120901291622l5cc165ecna06e01cc3de52a39 at mail.gmail.com> michael taylor writes: : An academic maverick is challenging conventional wisdom on Canada's : prehistory by claiming an archeological site in southern Alberta is : really a vast, open-air sun temple with a precise 5,000-year-old : calendar predating England's Stonehenge and Egypt's pyramids. ... : Since we had some discussion about historic calendars earlier this : year, I thought it might of interest here. I wonder if he has accounted for the progression in the earth's wobble over the past 5k years to make his claims... Warner From magnus at rubidium.dyndns.org Fri Jan 30 01:13:26 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 30 Jan 2009 02:13:26 +0100 Subject: [time-nuts] Canada's 5,000 year old calendar In-Reply-To: <20090129.180305.-142971468.imp@bsdimp.com> References: <25630a120901291622l5cc165ecna06e01cc3de52a39@mail.gmail.com> <20090129.180305.-142971468.imp@bsdimp.com> Message-ID: <49825436.5090606@rubidium.dyndns.org> M. Warner Losh skrev: > In message: <25630a120901291622l5cc165ecna06e01cc3de52a39 at mail.gmail.com> > michael taylor writes: > : An academic maverick is challenging conventional wisdom on Canada's > : prehistory by claiming an archeological site in southern Alberta is > : really a vast, open-air sun temple with a precise 5,000-year-old > : calendar predating England's Stonehenge and Egypt's pyramids. > ... > : Since we had some discussion about historic calendars earlier this > : year, I thought it might of interest here. > > I wonder if he has accounted for the progression in the earth's wobble > over the past 5k years to make his claims... Hmm... never check a story too closely... :) I think to recall that that kind of people use software that can fairly accurately re-play sky-events back in time... considering various of long-term drift effects. Would love to fool around with that kind of stuff... but it is probably unobtainables for mere mortals like me. Cheers, Magnus From imp at bsdimp.com Fri Jan 30 01:18:10 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu, 29 Jan 2009 18:18:10 -0700 (MST) Subject: [time-nuts] Canada's 5,000 year old calendar In-Reply-To: <49825436.5090606@rubidium.dyndns.org> References: <25630a120901291622l5cc165ecna06e01cc3de52a39@mail.gmail.com> <20090129.180305.-142971468.imp@bsdimp.com> <49825436.5090606@rubidium.dyndns.org> Message-ID: <20090129.181810.-1664198477.imp@bsdimp.com> In message: <49825436.5090606 at rubidium.dyndns.org> Magnus Danielson writes: : M. Warner Losh skrev: : > In message: <25630a120901291622l5cc165ecna06e01cc3de52a39 at mail.gmail.com> : > michael taylor writes: : > : An academic maverick is challenging conventional wisdom on Canada's : > : prehistory by claiming an archeological site in southern Alberta is : > : really a vast, open-air sun temple with a precise 5,000-year-old : > : calendar predating England's Stonehenge and Egypt's pyramids. : > ... : > : Since we had some discussion about historic calendars earlier this : > : year, I thought it might of interest here. : > : > I wonder if he has accounted for the progression in the earth's wobble : > over the past 5k years to make his claims... : : Hmm... never check a story too closely... :) : : I think to recall that that kind of people use software that can fairly : accurately re-play sky-events back in time... considering various of : long-term drift effects. Would love to fool around with that kind of : stuff... but it is probably unobtainables for mere mortals like me. But I though that unobtainium was easily procured by the time-nuts :) I've seen such software on several shows on TV about "paleo-astronomy". Warner From magnus at rubidium.dyndns.org Fri Jan 30 01:33:45 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Fri, 30 Jan 2009 02:33:45 +0100 Subject: [time-nuts] Canada's 5,000 year old calendar In-Reply-To: <20090129.181810.-1664198477.imp@bsdimp.com> References: <25630a120901291622l5cc165ecna06e01cc3de52a39@mail.gmail.com> <20090129.180305.-142971468.imp@bsdimp.com> <49825436.5090606@rubidium.dyndns.org> <20090129.181810.-1664198477.imp@bsdimp.com> Message-ID: <498258F9.6070509@rubidium.dyndns.org> M. Warner Losh skrev: > In message: <49825436.5090606 at rubidium.dyndns.org> > Magnus Danielson writes: > : M. Warner Losh skrev: > : > In message: <25630a120901291622l5cc165ecna06e01cc3de52a39 at mail.gmail.com> > : > michael taylor writes: > : > : An academic maverick is challenging conventional wisdom on Canada's > : > : prehistory by claiming an archeological site in southern Alberta is > : > : really a vast, open-air sun temple with a precise 5,000-year-old > : > : calendar predating England's Stonehenge and Egypt's pyramids. > : > ... > : > : Since we had some discussion about historic calendars earlier this > : > : year, I thought it might of interest here. > : > > : > I wonder if he has accounted for the progression in the earth's wobble > : > over the past 5k years to make his claims... > : > : Hmm... never check a story too closely... :) > : > : I think to recall that that kind of people use software that can fairly > : accurately re-play sky-events back in time... considering various of > : long-term drift effects. Would love to fool around with that kind of > : stuff... but it is probably unobtainables for mere mortals like me. > > But I though that unobtainium was easily procured by the time-nuts :) Yes, that's the easy stuff for us. :) > I've seen such software on several shows on TV about > "paleo-astronomy". So obviously it exists and it makes sense from their context. I guess many of the existing viewers does not require much more logic to them to pull it off. At least positive JD era should have a fair precission for most of their work. Cheers, Magnus From brooke at pacific.net Fri Jan 30 01:54:37 2009 From: brooke at pacific.net (Brooke Clarke) Date: Thu, 29 Jan 2009 17:54:37 -0800 Subject: [time-nuts] Canada's 5,000 year old calendar In-Reply-To: <49825436.5090606@rubidium.dyndns.org> References: <25630a120901291622l5cc165ecna06e01cc3de52a39@mail.gmail.com> <20090129.180305.-142971468.imp@bsdimp.com> <49825436.5090606@rubidium.dyndns.org> Message-ID: <49825DDD.2060907@pacific.net> Hi Magnus: MICA is a package done by USNO that I use to check astronomical events for my location. http://www.willbell.com/almanacs/almanac_mica.htm good back to only 1800. Starry Night is rated for 4713 BC to 9999 AD http://www.starrynightstore.com/17236.html#learnmore Have Fun, Brooke Clarke http://www.prc68.com Magnus Danielson wrote: > M. Warner Losh skrev: >> In message: <25630a120901291622l5cc165ecna06e01cc3de52a39 at mail.gmail.com> >> michael taylor writes: >> : An academic maverick is challenging conventional wisdom on Canada's >> : prehistory by claiming an archeological site in southern Alberta is >> : really a vast, open-air sun temple with a precise 5,000-year-old >> : calendar predating England's Stonehenge and Egypt's pyramids. >> ... >> : Since we had some discussion about historic calendars earlier this >> : year, I thought it might of interest here. >> >> I wonder if he has accounted for the progression in the earth's wobble >> over the past 5k years to make his claims... > > Hmm... never check a story too closely... :) > > I think to recall that that kind of people use software that can fairly > accurately re-play sky-events back in time... considering various of > long-term drift effects. Would love to fool around with that kind of > stuff... but it is probably unobtainables for mere mortals like me. > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From holrum at hotmail.com Fri Jan 30 04:27:55 2009 From: holrum at hotmail.com (Mark Sims) Date: Fri, 30 Jan 2009 04:27:55 +0000 Subject: [time-nuts] Lady Heather Update In-Reply-To: References: Message-ID: Here is an updated version of the good Lady Heather's GPS Disciplined Oscillator control program for the Thunderbolt. This version adds command line support for setting the video mode: /VS = 800x600 /VM = 1024x768 (default) /VL = 1280x960 (also good for 1280x1024) /? for command line help Again, the compiled version is for DOS/WIN98 and mayby WIN ME, WIN/NT DOS mode on systems with a VESA compatible video BIOS. _________________________________________________________________ Windows Live? Hotmail??more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_012009 -------------- next part -------------- A non-text attachment was scrubbed... Name: HEATHER.ZIP Type: application/zip Size: 77862 bytes Desc: not available Url : http://www.febo.com/pipermail/time-nuts/attachments/20090130/cffdd619/attachment-0001.zip From VK3FGJM at commtelns.com Fri Jan 30 09:46:05 2009 From: VK3FGJM at commtelns.com (VK3FGJM) Date: Fri, 30 Jan 2009 20:46:05 +1100 Subject: [time-nuts] Lady Heather Update In-Reply-To: References: Message-ID: <50D403A38069BF4196F41887738C03EE0788B6@companyweb> Hi Mark, Again thanks. Kind regards, Gerald VK3FGJM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Mark Sims Sent: Friday, 30 January 2009 3:28 PM To: time-nuts at febo.com Subject: [time-nuts] Lady Heather Update Here is an updated version of the good Lady Heather's GPS Disciplined Oscillator control program for the Thunderbolt. This version adds command line support for setting the video mode: /VS = 800x600 /VM = 1024x768 (default) /VL = 1280x960 (also good for 1280x1024) /? for command line help Again, the compiled version is for DOS/WIN98 and mayby WIN ME, WIN/NT DOS mode on systems with a VESA compatible video BIOS. _________________________________________________________________ Windows Live(tm) Hotmail(r)...more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_ howitworks_012009 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg From alan.melia at btinternet.com Fri Jan 30 10:33:20 2009 From: alan.melia at btinternet.com (Alan Melia) Date: Fri, 30 Jan 2009 10:33:20 -0000 Subject: [time-nuts] Astro-paleology or paleo-astronomy Message-ID: <005501c982c6$2e655c60$0900a8c0@AM> Hi Magnus, I am sure I have at least one astro planetarium program somewhere (it doesnt get much use here) that will allow you to set the clock to 5000BC ....not GPS disciplined though :-)) I will have to check the detail. One was written by a good friend now deceased. Alan G3NYK From holrum at hotmail.com Fri Jan 30 13:37:30 2009 From: holrum at hotmail.com (Mark Sims) Date: Fri, 30 Jan 2009 13:37:30 +0000 Subject: [time-nuts] Tbolt temperature sensor In-Reply-To: References: Message-ID: My latest Thunderbolt is one from March 2005 (like Asa's). The others are much earlier production. The later production units seem to handle the temperature sensor differently. Tbolts use a DS1620 sensor chip. This chip reports the temperature in 0.5C increments, but has support for getting higher resolution. The earlier production tbolts generated a smooth temperature curve that tracked temperature changes gracefully.On the later production tbolts you usually see a flat temperature plot with the temperature quantized to 0.25C/0.75C values. This indicates that the Tbolt firmware is doing at least part of the high resolution temperature read cycle shown in the DS1620 data sheet. The first part of this is to take the temperature reading (0.5C steps), knock off the lower bit, and subtract 0.25C. You should then read some counter registers and do some arithmetic to generate the high res temp reading. It appears that the later production units are not doing this (or later DS1620 chips do not support the counter registers) because the temperature plot is always quantized to 0.25C/0.75C (except for some apparent software filtering that is performed when the value changes). One side effect of the coarse temperature steps in the later Tbolts is that cause Lady Heather to log lots of temperature spikes. The eralier tbolts produced nice smooth curves with an occasional temperature spike (that I now suspect is due to boundary conditions in the DS1620 count registers) that quickly faded away. The newer units can show lots of high frequency oscillations in the temperature reading as the DS1620 readings jitter around the 0.5 degree temperature steps. _________________________________________________________________ Windows Live? Hotmail?:?more than just e-mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009 From james.p.lux at jpl.nasa.gov Fri Jan 30 14:26:50 2009 From: james.p.lux at jpl.nasa.gov (Lux, James P) Date: Fri, 30 Jan 2009 06:26:50 -0800 Subject: [time-nuts] Canada's 5,000 year old calendar In-Reply-To: <49825436.5090606@rubidium.dyndns.org> Message-ID: On 1/29/09 5:13 PM, "Magnus Danielson" wrote: > M. Warner Losh skrev: >> In message: <25630a120901291622l5cc165ecna06e01cc3de52a39 at mail.gmail.com> >> michael taylor writes: >> : An academic maverick is challenging conventional wisdom on Canada's >> : prehistory by claiming an archeological site in southern Alberta is >> : really a vast, open-air sun temple with a precise 5,000-year-old >> : calendar predating England's Stonehenge and Egypt's pyramids. >> ... >> : Since we had some discussion about historic calendars earlier this >> : year, I thought it might of interest here. >> >> I wonder if he has accounted for the progression in the earth's wobble >> over the past 5k years to make his claims... > > Hmm... never check a story too closely... :) > > I think to recall that that kind of people use software that can fairly > accurately re-play sky-events back in time... considering various of > long-term drift effects. Would love to fool around with that kind of > stuff... but it is probably unobtainables for mere mortals like me. I haven't read the article yet (I'm going to though) I wouldn't count on them having a fancy sky simulator. For all you know, they've got something that just has a "good enough" approximation to do right now, and they plugged in a date for 5000 years ago. There's applications that do this sort of thing for Palm Pilots and iPhones for instance. I have a little Celestron SkyScout (a very nifty device) and it has a GPS receiver and magnetic sensor, so you can punch in what planet you want to look at, and it figures out where to point, presumably by using some sort of programmed ephemeris. However, the accuracy of that ephemeris probably significantly degrades if you were to somehow enter a date (normally picked up from GPS) 200 years ago or in the future. Ditto for the "go to" telescopes. There ARE very accurate planetary ephemerides available for free. Check out CCMATLAB (not free, but cheap) for an interface to the JPL Ephemerides algorithms. These are basically numerically integrated differential equations used for predicting the motions of heavenly bodies for doing, among other things, spacecraft navigation. http://ssd.jpl.nasa.gov/horizons.cgi http://ssd.jpl.nasa.gov/?ephemerides You can download them all from various JPL sites. Jim From bruce at w1bw.org Fri Jan 30 16:31:14 2009 From: bruce at w1bw.org (Bruce Walker) Date: Fri, 30 Jan 2009 11:31:14 -0500 Subject: [time-nuts] Tbolt temperature sensor In-Reply-To: References: Message-ID: On Fri, Jan 30, 2009 at 8:37 AM, Mark Sims wrote: > The newer units can show lots of high frequency oscillations in the temperature reading as the DS1620 readings jitter around the 0.5 degree temperature steps. I wonder how that affects holdover compensation. It seems that my TAPR Tbolt has moves the DAC by about 1e-4 V, or 5e-4Hz, per 0.1C. 0.5C represents a huge step of something like 2.5e-10. --bruce w1bw From had at to-way.com Fri Jan 30 17:39:54 2009 From: had at to-way.com (Had) Date: Fri, 30 Jan 2009 09:39:54 -0800 Subject: [time-nuts] Austron 1250A Manual Message-ID: <20090130173956.3B13298D9F7@mail-in05.adhost.com> Hi gang, I just put a scan of the Austron 1250A manual on the www.to-way.com site. 1.3 MB .pdf 300x300 monochrome. Had From holrum at hotmail.com Fri Jan 30 17:09:35 2009 From: holrum at hotmail.com (Mark Sims) Date: Fri, 30 Jan 2009 17:09:35 +0000 Subject: [time-nuts] Tbolt temperature sensor In-Reply-To: References: Message-ID: I don't know if it is bad... but it certainly can't be good... BTW, my newer Tbolt is a second group TAPR unit.... I am pretty sure it shows the same firmware (3.0) / build (10.2) versions as an earlier one that does not show the "problem". I am thinking it may be caused by changes in the sensor chip (or it could be a bad batch... mine was made within days of Asa's unit which also shows the flat temperature line). The firmware is definitely doing the "subtract 0.25C" step of the high resolution read cycle. It is just not producing the extra digits from the counter/slope registers. ------------- I wonder how that affects holdover compensation. It seems that my TAPR Tbolt has moves the DAC by about 1e-4 V, or 5e-4Hz, per 0.1C. 0.5C represents a huge step of something like 2.5e-10. --bruce w1bw _________________________________________________________________ Hotmail? goes where you go. On a PC, on the Web, on your phone. http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208 From magnus at rubidium.dyndns.org Sat Jan 31 15:26:05 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 31 Jan 2009 16:26:05 +0100 Subject: [time-nuts] Lady Heather Update In-Reply-To: References: Message-ID: <49846D8D.6080401@rubidium.dyndns.org> Mark Sims skrev: > Here is an updated version of the good Lady Heather's GPS Disciplined Oscillator control program for the Thunderbolt. This version adds command line support for setting the video mode: > > /VS = 800x600 > /VM = 1024x768 (default) > /VL = 1280x960 (also good for 1280x1024) > > > /? for command line help > > > Again, the compiled version is for DOS/WIN98 and mayby WIN ME, WIN/NT DOS mode on systems with a VESA compatible video BIOS. Fails to run on my old Win2k box... even with /2 it fails to find COM1 while the Thunderbolt software does... Cheers, Magnus From martinrh45 at googlemail.com Sat Jan 31 15:36:20 2009 From: martinrh45 at googlemail.com (Martin Richmond-Hardy) Date: Sat, 31 Jan 2009 15:36:20 +0000 Subject: [time-nuts] Lady Heather Update In-Reply-To: <49846D8D.6080401@rubidium.dyndns.org> References: <49846D8D.6080401@rubidium.dyndns.org> Message-ID: <8a3357d10901310736w75457af9ucba62b35beea12aa@mail.gmail.com> I had similar probs with trying to run on WinxP Home ? just a few coloured dots at the top of a black screen. But then I read the words the compiled version is for DOS/WIN98 and mayby WIN ME, WIN/NT DOS mode on systems with a VESA compatible video BIOS. Martin G8BHC 2009/1/31 Magnus Danielson > Mark Sims skrev: > > Here is an updated version of the good Lady Heather's GPS Disciplined > Oscillator control program for the Thunderbolt. This version adds command > line support for setting the video mode: > > > > /VS = 800x600 > > /VM = 1024x768 (default) > > /VL = 1280x960 (also good for 1280x1024) > > > > > > /? for command line help > > > > > > Again, the compiled version is for DOS/WIN98 and mayby WIN ME, WIN/NT > DOS mode on systems with a VESA compatible video BIOS. > > Fails to run on my old Win2k box... even with /2 it fails to find COM1 > while the Thunderbolt software does... > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Martin Richmond-Hardy From w1ksz at earthlink.net Sat Jan 31 18:22:16 2009 From: w1ksz at earthlink.net (Richard W. Solomon) Date: Sat, 31 Jan 2009 11:22:16 -0700 (GMT-07:00) Subject: [time-nuts] Lady Heather Update Message-ID: <16325123.1233426136881.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> I tried it on my Compaq 486 running WIN98SE I get a black screen with Logoff on it and a couple of other lines that make no sense ? Who has the Rosetta Stone ?? 73, Dick, W1KSZ -----Original Message----- >From: Mark Sims >Sent: Jan 29, 2009 9:27 PM >To: time-nuts at febo.com >Subject: [time-nuts] Lady Heather Update > > >Here is an updated version of the good Lady Heather's GPS Disciplined Oscillator control program for the Thunderbolt. This version adds command line support for setting the video mode: > >/VS = 800x600 >/VM = 1024x768 (default) >/VL = 1280x960 (also good for 1280x1024) > > >/? for command line help > > >Again, the compiled version is for DOS/WIN98 and mayby WIN ME, WIN/NT DOS mode on systems with a VESA compatible video BIOS. >_________________________________________________________________ >Windows Live? Hotmail??more than just e-mail. >http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_012009 From magnus at rubidium.dyndns.org Sat Jan 31 18:31:20 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 31 Jan 2009 19:31:20 +0100 Subject: [time-nuts] Lady Heather Update In-Reply-To: <16325123.1233426136881.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> References: <16325123.1233426136881.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Message-ID: <498498F8.3010608@rubidium.dyndns.org> Richard W. Solomon skrev: > I tried it on my Compaq 486 running WIN98SE I get a black screen > with Logoff on it and a couple of other lines that make no sense ? > > Who has the Rosetta Stone ?? I do not know... British Museum maybe? I tried to recompile in my Cygwin environment but with no luck, failed to compile. It seems to be beyond me... I know nothing about Windows... I just need to run the damn thing for some apps... Cheers, Magnus From alan.melia at btinternet.com Sat Jan 31 19:26:13 2009 From: alan.melia at btinternet.com (Alan Melia) Date: Sat, 31 Jan 2009 19:26:13 -0000 Subject: [time-nuts] Lady Heather Update References: <16325123.1233426136881.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <498498F8.3010608@rubidium.dyndns.org> Message-ID: <002701c983d9$d0fc3020$0900a8c0@AM> Hi all, I am running an AMD Duron 700MHz running W98SE when run the program opens a DOS window but crashes the video monitor until the program is stopped with the escape key. So some of the problems may be with the monitor parameters which may not support the high res that a lot will be running even on 98. One solution might be to temporarily select a generic VGA ?? and the boot the program ?? But setting the display to 640 x 480 and 16 colours also gave a blank sccreen (the monitor didn't undestand the drive to it ) Alan G3NYK ----- Original Message ----- From: "Magnus Danielson" To: "Richard W. Solomon" ; "Discussion of precise time and frequency measurement" Sent: Saturday, January 31, 2009 6:31 PM Subject: Re: [time-nuts] Lady Heather Update > Richard W. Solomon skrev: > > I tried it on my Compaq 486 running WIN98SE I get a black screen > > with Logoff on it and a couple of other lines that make no sense ? > > > > Who has the Rosetta Stone ?? > > I do not know... British Museum maybe? > > I tried to recompile in my Cygwin environment but with no luck, failed > to compile. > > It seems to be beyond me... I know nothing about Windows... I just need > to run the damn thing for some apps... > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. From REMartinson at rcn.com Sat Jan 31 20:41:04 2009 From: REMartinson at rcn.com (Bob Martinson) Date: Sat, 31 Jan 2009 15:41:04 -0500 Subject: [time-nuts] Lady Heather Update In-Reply-To: <498498F8.3010608@rubidium.dyndns.org> Message-ID: Both the old & new versions of Heather run fine on my Win-XP pc here. Help only flashes on the screen, but the 3 screen options all work fine. 73, Bob K1REM -----Original Message----- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On Behalf Of Magnus Danielson Sent: Saturday, January 31, 2009 1:31 PM To: Richard W. Solomon; Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Lady Heather Update Richard W. Solomon skrev: > I tried it on my Compaq 486 running WIN98SE I get a black screen > with Logoff on it and a couple of other lines that make no sense ? > > Who has the Rosetta Stone ?? I do not know... British Museum maybe? I tried to recompile in my Cygwin environment but with no luck, failed to compile. It seems to be beyond me... I know nothing about Windows... I just need to run the damn thing for some apps... Cheers, Magnus _______________________________________________ time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. From paul at greenrover.demon.co.uk Sat Jan 31 20:57:16 2009 From: paul at greenrover.demon.co.uk (paul at greenrover.demon.co.uk) Date: Sat, 31 Jan 2009 20:57:16 +0000 Subject: [time-nuts] Lady Heather Update In-Reply-To: References: Message-ID: <4984BB2C.9060303@greenrover.demon.co.uk> Bob Martinson wrote: > Both the old & new versions of Heather run fine on my Win-XP pc here. Help > only flashes on the screen, but the 3 screen options all work fine. runs fine on my 2 x winxp-pro machines and I just tried an old win2K laptop - again works fine. Its a pity people are having trouble getting it going as its very good. Regards Paul -- 73 de Paul GW8IZR IO73TI http://www.gw8izr.com From boyscout at gmail.com Sat Jan 31 21:17:59 2009 From: boyscout at gmail.com (Matt Ettus) Date: Sat, 31 Jan 2009 13:17:59 -0800 Subject: [time-nuts] HP 4352A/B with different signal generator Message-ID: Does anyone know if it is possible to use the HP4352A/B VCO/PLL analyzers with signal generators other than the 8665A? What is involved? I have a sig gen which is plenty good, so buying an 8665 just to go with a 4352 (which you can now get for about $1K) seems like a waste. Thanks, Matt From brooke at pacific.net Sat Jan 31 21:32:22 2009 From: brooke at pacific.net (Brooke Clarke) Date: Sat, 31 Jan 2009 13:32:22 -0800 Subject: [time-nuts] HP 4352A/B with different signal generator In-Reply-To: References: Message-ID: <4984C366.5030105@pacific.net> Hi Matt: Where can I get one for that price? The Sig Gen phase noise is the driving spec since it needs to be better than the phase noise of the VCO you are measuring. Have Fun, Brooke Clarke http://www.prc68.com Matt Ettus wrote: > Does anyone know if it is possible to use the HP4352A/B VCO/PLL > analyzers with signal generators other than the 8665A? What is > involved? > > > I have a sig gen which is plenty good, so buying an 8665 just to go > with a 4352 (which you can now get for about $1K) seems like a waste. > > > Thanks, > Matt > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > From jra at febo.com Sat Jan 31 22:19:47 2009 From: jra at febo.com (John Ackermann N8UR) Date: Sat, 31 Jan 2009 17:19:47 -0500 Subject: [time-nuts] HP 3456A stability upgrade Message-ID: <4984CE83.3060807@febo.com> For you volt-nuts out there... There's a fellow in California, John Lion (LionElectronicLabs at BigPlanet dot com) who has a supply of temperature-chamber-aged and then hand-selected references that he will install into an HP 3456A DMM for a fairly reasonable price. I don't know how much of a difference these really make, but supposedly they provide better stability both short and long term than the standard reference that HP installed. I don't have the gear to test that myself, but I had a good report from a cal lab that has worked with a few of these units. Anyway, I don't have any connection with John other than as a customer (and he's been extremely good on customer service and follow through), but thought I'd pass this on for those who might be interested. John From boyscout at gmail.com Sat Jan 31 22:42:02 2009 From: boyscout at gmail.com (Matt Ettus) Date: Sat, 31 Jan 2009 14:42:02 -0800 Subject: [time-nuts] HP 4352A/B with different signal generator In-Reply-To: <4984C366.5030105@pacific.net> References: <4984C366.5030105@pacific.net> Message-ID: There's a 4352B on ebay for a $1K start bid, but there's a reserve. There's a 4352A for $1999 Buy it Now with an "Or Best Offer" option. In general, this is an absolutely great time to get modern test equipment at very low cost. With the economy down, everybody wants to get rid of inventory. I just got a like-new R+S SMATE200A (Dual IQ signal generator up to 6 GHz) for $8K, even though the new price is still $65K. I think I could have gotten it for less if I had tried, since it was right before the end of the year. On the subject of the alternate sig gen with a 4352, do you need to just tune it to some frequency offset away from the signal you are measuring? Does the offset change during the measurement? If it changes during the measurement, some form of automation would be necessary. Thanks, Matt On Sat, Jan 31, 2009 at 1:32 PM, Brooke Clarke wrote: > Hi Matt: > > Where can I get one for that price? > > The Sig Gen phase noise is the driving spec since it needs to be better than > the phase noise of the VCO you are measuring. > > Have Fun, > > Brooke Clarke > http://www.prc68.com > > Matt Ettus wrote: >> Does anyone know if it is possible to use the HP4352A/B VCO/PLL >> analyzers with signal generators other than the 8665A? What is >> involved? >> >> >> I have a sig gen which is plenty good, so buying an 8665 just to go >> with a 4352 (which you can now get for about $1K) seems like a waste. >> >> >> Thanks, >> Matt >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts at febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> > > > _______________________________________________ > time-nuts mailing list -- time-nuts at febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > From holrum at hotmail.com Sat Jan 31 21:27:07 2009 From: holrum at hotmail.com (Mark Sims) Date: Sat, 31 Jan 2009 21:27:07 +0000 Subject: [time-nuts] Lady Heather Update In-Reply-To: References: Message-ID: Hello again Magnus, If the program is started up and it is not seeing the Tbolt on the COM port you should see the "Log: OFF" indicator, two lines of text that are the plot area header, and the plot axes/grid. Pressing the SPACE bar should bring up a help screen in place of the plot grid. If all that is working, the problem is probably in the COM port. It wants the tbolt to be at factory com settings (9600,N,8,1) The program talks to the COM port UART directly. It probably won't work with a USB converter. The default is COM1, the /2 command line option should select COM2 (but I don't have a machine here with two serial ports to test it... the com port code was lifted from another program that did work with COM2). There are several command line options. use /? to see them. _________________________________________________________________ Windows Live?: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009