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.jpgalthough 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.htmlshows 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.jpgshows 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" <[EMAIL PROTECTED]> To: "Discussion of precise time and frequency measurement" <[email protected]> Sent: Wednesday, June 15, 2005 15:52 Subject: Re: [time-nuts] Abrupt changes in TI with HP 5370B's own timebaseTom 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 [email protected] 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/ _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
