[time-nuts] Z3801 lockin behaviour

Greg Burnett gbus at adelphia.net
Mon Jul 24 12:37:32 EDT 2006


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




More information about the time-nuts mailing list