[time-nuts] Z3801 lockin behaviour

Bill Hawkins bill at iaxs.net
Mon Jul 24 17:42:04 UTC 2006


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: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] 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" <cfmd at bredband.net>
To: <shoppa at trailing-edge.com>
Cc: <time-nuts at febo.com>
Sent: Monday, July 24, 2006 10:21 AM
Subject: Re: [time-nuts] Z3801 lockin behaviour


From: shoppa at trailing-edge.com (Tim Shoppa)
Subject: Re: [time-nuts] Z3801 lockin behaviour
Date: Mon, 24 Jul 2006 09:36:45 -0400
Message-ID: <20060724133645.DBF95848058 at mini-me.trailing-edge.com>

> Magnus Danielson <cfmd at bredband.net> 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
time-nuts at febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts


_______________________________________________
time-nuts mailing list
time-nuts at febo.com
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






More information about the Time-nuts_lists.febo.com mailing list