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 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 [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
