[time-nuts] Abrupt changes in TI with HP 5370B's own timebase

Mon Jun 20 04:03:57 EDT 2005

Tom,
I believe you are right and there is nothing wrong with my 5370B, which 
is rather good news. At least I think so. I am now putting the data 
dynamically on a web server, so you might find a problem before me, 
since I can't look at all the time.

I have now started measuring temperature changes at the air inlet of the 
5370B and find the drifts, using the *loopback*, were correlated well 
with temperature. These are single temperature measurements, made with a 
very small thermistor, which is an airflow must have a time constant of 
a few seconds at most. There is no averaging in software.

However, when I feed in a second oscillator to both the start and stop 
inputs, (so not using the loopback), with a T-piece on the start, so the 
stop gets delayed by the length of the bit of cable, I find TI 
measurements are stable with temperature. So in a mode that the 
instrument is needed, the measurements are stable. In loopback, measured 
over a period of many hours, this is not so.

The following two graphs were produced in different ways (I can now 
produce them dynamically), but the drifts apparent here:

http://www.g8wrb.org.uk/useful-stuff/time/data/abrupt-changes-in-TI/75hours.html

can (hopefully) not be seen here:

http://www.g8wrb.org.uk/useful-stuff/time/data/abrupt-changes-in-TI/foo.jpg

although since this is updated every 30 minutes or so, you might see a 
change before me.

(note, there is a small probably of this dynamically updated graph being 
messed up, due to there being no syncronisation between the graph being 
produced, and the time it's copied to a web server. There's a small 
chance it gets overwritten as it gets copied. I'll sort that later).

Notes:

1) The first graph

http://www.g8wrb.org.uk/useful-stuff/time/data/abrupt-changes-in-TI/75hours.html

shows individual TI measurements, but the points are not joined, so you 
see they are spaced 20ps apart (usually). It's clear the 20ps resolution 
of the 5370B becomes (as far as the ASCII output is concerned) 10 ps at 
some points. I think this is just the CPU in the 5370B rounding to the 
nearest 10ps.

The graph is a bit hard to follow, and unconventional, so I scraped that 
method of drawing it.

2) The second graph at
http://www.g8wrb.org.uk/useful-stuff/time/data/abrupt-changes-in-TI/foo.jpg
shows again individual TI and temperature measurements. Data is 
collected at 10s intervals, not about 60-100ms as the former graph.

Hence the two graphs I am showing are processed/drawn in slightly 
different ways, but this does not alter the results. I have looked at 
them procesing in exactly the same way and see the drifts are only 
apparent in loopback.

David Kirkby

Tom Van Baak wrote:
> David,
> 
> 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.
> 
> /tvb
> http://www.LeapSecond.com
> 
> ----- 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
>>possible.
>>
>>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
>>related.
>>
>>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.
> 
> 
> 
> 
> 
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> 
> 

-- 
David Kirkby,
G8WRB

Please check out http://www.g8wrb.org/
of if you live in Essex http://www.southminster-branch-line.org.uk/