[time-nuts] Abrupt changes in TI with HP 5370B's own timebase
Tom Van Baak
tvb at leapsecond.com
Wed Jun 15 19:59:12 EDT 2005
With the lack of similar tests here on my 5370
let me first say that what you're seeing is not
necessarily a "problem". It may simply be a
subtle artifact of the implementation.
But here are some additional, simple things you
can do to investigate the effect you're seeing.
1) Try a cable of different length. In the particular
self-test you're performing there is synchronization
between the main internal clock and the signal
you are measuring. A slightly different length cable
will cause the zero crossing to occur at a different
time in both the 10 MHz and the 200 MHz clocks.
It should not effect the special interpolator 256/257
199.22179 MHz clock. See chapter 8 for details.
The self-test itself is fine -- you are measuring
100 ns as expected -- but perhaps when it's run
for that long, you are exposing certain timing
boundaries in the design which would not occur
in normal use. Just a guess; I could be all wrong,
especially since the size of the jumps doesn't
sit well with me.
2) Keep the internal ref; don't use an external ref;
instead try using an independent 10 MHz input
source for your test, rather than a loop-back.
You should still get a 100 ns result but the phase
jumps you are seeing may disappear completely.
In this case, it would be due to the complete
break in both synchronization and *syntonization*
between the 10 MHz source being measured and
the internal 10 MHz 5370 clock. If this makes the
effect go away it's good news since this is a more
real-world scenario anyway.
----- Original Message -----
From: "David Kirkby" <david.kirkby at onetel.net>
To: "Discussion of precise time and frequency measurement"
<time-nuts at febo.com>
Sent: Wednesday, June 15, 2005 15:52
Subject: Re: [time-nuts] Abrupt changes in TI with HP 5370B's own timebase
> Tom Van Baak wrote:
> > David,
> > Nice plots.
> Thanks Tom. As you can see, I did not put any effort into making the
> graphs look nice, but they are functional.
> > Although you got the "right answer"
> > in your initial test it was good of you to let it run
> > as long as you did.
> Computers are good for that. I've still got it running and it just looks
> like it might be about to start another slowish change. It's actually
> quite cool now.
> > What averaging mode were you using? Or were
> > you taking one 100 ns sample every 100 ms?
> There is no averaging at all. Hence the data points always differ by an
> integer multiple of 20ps (the resolution of the 5370B), which is why you
> see the straight horizontal lines.
> Actually the data points are more like 65ms apart, rather than the 100ms
> I stated, but the times on the axes are correct. They are set by the
> time for the 5370B to convert the data to ASCII and my GPIB board read
> it, rather than any intensional delay. (As was discussed before, reading
> in ASCII is not ideal, but for this, I don't need it any more speed)
> > I agree it is unlikely a problem is with the OCXO
> > as in this self-test mode the absolute frequency
> > is irrelevant. You could double check by using
> > an external osc ref input.
> I will do that. I have a rubidium, but it not too convenient to use just
> now. I have another 10811-60111 I could put in should the need arrise,
> but I think I'll investigate the other (more likely) possibilities first.
> > However, that's not to say the OCXO is the only
> > temperature sensitive element inside a 5370,
> > especially when you're measuring picoseconds.
> I did wonder if drift in the trigger points would occur with
> temperature, which would have this same effect. That would seem quite
> Some look to be very sharp jumps though, whereas others do look to have
> an exponential characteristic, as if they might be temperature or drift
> There is probably more than one effect showing in those graphs. I need
> to remove and/or reduce them all before I can make any meaningful
> comparisons of oscillators.
> > I say this because your events are roughly a day
> > apart -- (12, 18) + 24 sort of equals 33 - 43.
> The problem is that that the room temperature is regulated not only by
> the Sun, but when I open windows etc.
> > Unless you get better suggestions, the first few
> > things to try are mains input voltage and ambient
> > temperature and shock/vibration.
> I'd obviously thought about temperature, but not given mains or
> vibration a thought.
> > Since you aren't
> > continuously monitoring these, you can simulate
> > each of them in turn to see if you get the 5370 to
> > show the abrupt change. Wiggling BNC cables is
> > easy as is jumping around your room. Varying
> > mains voltage is not that hard. And a hair dryer
> > works well to cause a temperature delta (as well
> > as pull nearby mains voltage down).
> You have given me some ideas there Tom.
> I have to do some real work now, so will just leave it running until I
> have time to do some more experiments. Continuous monitoring temperature
> and mains voltage should not be hard, but vibration is not something I
> can easily measure, but is easy to induce as you say.
> I'll let the group know what I find.
> David Kirkby.
More information about the time-nuts