Hi Bill, Yeah, that was always my experience too, until the HP 5370A/B came along. In the case of the HP 5370A/B, you can end-up with TI systematic offset if the 200MHz start/stop interpolator "TI Zero" adjustments drift. ...And you can end-up with systematic "Frequency Count Mode" frequency offset if the arming adjustments drift. (Strange beast!)
IMHO, if you have a HP 5370A/B, and you play with the above adjustments, it's important to know that the "TI Zero" adjustments have real-time TI offset effect; whereas the arming adjustments do *not* have real-time effect on systematic frequency-mode offset. (In the latter case therefore, you must make a slight arming adjustment, and then toggle from "Frequency" mode to "TI" mode, and then back to "Frequency" mode in order to see the new effect of your adjustment.) There are world-class experts in this group, and so I don't think I needed to (nor necessarily should) mention these things here. But outside this group, you'd be surprised how many metrologists have blindly relied on the HP 5370A/B for timebase related measurements, without even performing an experiment to quantify the [noise + systematic offset] of their process. P.S. Some metrology labs simply quantify the HP 5370A/B systematic offset in software, and rely on the software to subtract-out the offset (correction factor based on measurements taken during set-up part of their measurement session). Cheers, Greg ----- Original Message ----- From: "Bill Hawkins" <[EMAIL PROTECTED]> To: "'Discussion of precise time and frequency measurement'" <[email protected]> Sent: Monday, July 24, 2006 1:00 PM Subject: Re: [time-nuts] Z3801 lockin behaviour Maybe I'm too old to be doing this. Every HP counter that had a test function that I tried read 1 followed by a number of zeros (depending on the divider setting). The last digit might be zero or 1. Perhaps the methods used to get down to picoseconds are vulnerable to noise and offset. I think there's no reason for high-speed dividers to cause the kind of jumping around that Magnus reported. For that, I'd bet on one or more fractures in the crystal, caused by the rough handling that surplus equipment experiences. To the former owner, it's junk. Regards, Bill Hawkins -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of gbus Sent: Monday, July 24, 2006 12:57 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Z3801 lockin behaviour Measuring a counter's own timebase will show the counter's noise and offset *relative* to its timebase. Don't you need to know this limitation *before* making assumptions about the accuracy of your counter as locked to your house standard? Cheers, Greg Burnett ----- Original Message ----- From: "Bill Hawkins" <[EMAIL PROTECTED]> To: "'Discussion of precise time and frequency measurement'" <[email protected]> Sent: Monday, July 24, 2006 11:42 AM Subject: Re: [time-nuts] Z3801 lockin behaviour Sorry, measuring a counter's own timebase will not show frequency errors. The gate time is N/F, where N is the decade divider setting and F is the oscillator frequency. I have a pair of Z3801 receivers and two copies of GPSCon running on Win 98 SE. The Z3801s were powered up on 7 July after replacing one of the HP antennas. Nothing repairable in there, right? Lightning had struck the neighbor's house while the Z3801s were off, with antennas connected. Magnus, GPSCon Pro will supply you with charts of TI and EFC. The link is http://www.realhamradio.com/gpscon-info.htm It's not free, but very little about this hobby is, with the exception of this fine mailing list. I followed the GPSCon instructions to change from GPS time to UTC, and restart with a TEST command. After that, all responses from either Z3801 have error -230 "Data corrupt or stale." One receiver is now giving timeout errors in the GPSCon message display window. Twice, the messages were paired, exactly (to the second) 20 minutes apart. Got a pair on the 17th, one on 19th and 21st, pair on the 23rd and one today, at no predictable time of day. TI for the N/S receivers is AV .66/.15 ns, SD 9.5/12.7. EFC is AD .53/.76, SD 17.8/18.2. That's over 24 hours. And that's my experience with Z3801 receivers. Regards, Bill Hawkins -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Burnett Sent: Monday, July 24, 2006 11:38 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Z3801 lockin behaviour Magnus, Have you established the short-term noise floor and offset of your counter? (To test for these you might try looping the counter's own timebase into its own input for a while.) If you're using a HP 5370B counter that has significant offset, let me know and I can tell you how to adjust-out the offset.) Cheers, Greg ----- Original Message ----- From: "Magnus Danielson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Monday, July 24, 2006 10:21 AM Subject: Re: [time-nuts] Z3801 lockin behaviour From: [EMAIL PROTECTED] (Tim Shoppa) Subject: Re: [time-nuts] Z3801 lockin behaviour Date: Mon, 24 Jul 2006 09:36:45 -0400 Message-ID: <[EMAIL PROTECTED]> > Magnus Danielson <[EMAIL PROTECTED]> wrote: > > I haven't really made any real logs. I have checked the EFC values and it does > > move around. > > EFC is supposed to move around. Usually it moves around in a nice smooth > fashion, it's the jumps that cause attention! Well, I feel a bit unhappy about the resulting frequency. I know the EFC is supposed to move around, it is natural as it is being inside the control loop. (Your talking to a guy that designs PLL among other things for a living) Actually, I am not concentrating my attention to the EFC, I just look there too. I even lack good logging for the EFC, which is annoying. > > > During an EFC jump the TI can go to very large values for short periods > > > of time. > > > > Mine goes into holdover on a regular basis. During holdover it reaches 1.5 us. > > After holdover it tracks in and has TI around 0 (+/- 6-7 ns) but then it starts > > to drift out. It does that with a wobbely walk. It really looks like there is > > too much noise going on so it won't maintain steady lock. > > > > I'm pondering if it may not be something wrong with the running state of the > > SmartClock stuff. Maybe reset that so it has to relearn. I had the same problem > > as I am having now last time I had it powered, and then it didn't sort itself > > out either. It could also be a bad OCXO. It might be that it needs time to > > heal itself. I didn't have this problem initially thought. > > A "virgin" OCXO or one that has been powered up for a long while might > jump around a bit as it outgasses. But there are "bad" OCXO's that > never settle down, and there are "good" ones that after a few years > "go bad". This one sits in a Z3801A which have been the masterclock for a CDMA system, so it surely have outgased itself. It may however have been misshandled and hasn't realligned itself, or it has gone bad in some other way, or maybe just maybe there is some corruption in the SmartClock state relative where the clock is now which fuck things up. I'm not ruling things out totally. The inner control system is a bit of a white spot on our map, so therefore I need to consult the experience of the Z3801 owners on the list. I am considering a few other tests: 1) Measure the GPS PPS (too ensure a stable input) 2) Measure the Z3801A PPS (too see if the walkaround is there too) 3) Measure the Z3801A PPS & 10 MHz while in hold-over state (open loop and less sources of noise) Any thoughts? BTW. I just check the counter again, and it tells the same story. No hold-over in view, but it is a fair amount of walkaround and the current average where just a thad over 1E-9 in error. For being "locked" to GPS I really feel it is out of tune. I can try out another counter if you really want me to. Cheers, Magnus _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/396 - Release Date: 7/24/2006 _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/396 - Release Date: 7/24/2006 _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
