> I have done picket-fencing for years on my 5370B and never seen this > problem. > > I usually use a 1Hz signal as start and a 10MHz from my house reference > as the stop.
That seems to work OK on this counter, now that you mention it, except that I see wraparound from 105 ns to 6 ns rather than the expected waffling between 100.xx ns and 0.xx ns. I've been assuming that people will use two 1-pps sources, as in the paper. Can you try that (easily) to see if the same thing happens on yours within a few milliseconds of coincidence? > I clock the HP5370B from a third source (usually the internal OCXO) > to avoid synchronicity. > > I will caution you, that the IEEE488 implementation on the 5370B > is one of the more interesting I have encountered. > > You can easily loose measurements, like what you see, by not being > ready when the counter is. This isn't a GPIB issue; it happens in local-control mode as well. The counter arms itself every second but the display only changes every other second. > You should put the counter in talk mode, and have the computer > continuously > in read mode to prevent this. > > Also, you should timestamp the measurements in the computer with > fractional second granularity Sure. That wasn't from the ADEV program, it's just a dump from an existing 5370b.cpp console app that illustrates the problem. I'm pretty sure at this point that there's something weird going on with the counter itself. Would be curious to know if it's true of other 5370s when feeding both A and B from 1-pps sources. -- john, KE5FX _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
