[time-nuts] 5370B problem

[Magnus Danielson]

From: SAIDJACK at aol.com
Subject: [time-nuts] 5370B problem
Date: Sat, 23 Jun 2007 05:18:58 EDT
Message-ID: <cf9.12eaa527.33ae3f82 at aol.com>

> Hi guys,
>  
> has anyone seen phase jumps of the  "nanoseconds" range without any affect to 
> the picosecond display in  the 5370B before?

Not yeat, mine is so new in the house. :)

> This seems to me to be a digital problem, maybe in the averaging algorithm?  

Would be very strange if that was the case.

> Maybe because the unit is in GPIB talk-only mode with the GPIB-to-RS232  
> converter attached?

You should have clearly separate measure and transmit data periods and not
until it is done with either it enters the other.

I would have it do digital dump and then recalculate the TI value yourself
and then average yourself.

If you see the same problem then you have to look into the hardware since the
hardware registers is more or less directly dumped (a tradition that made it
into the 5371A and 5372A). 

If you don't see the same problem, there is something in the processing which
causes a problem.

Please note that the TI value is calculated as

      N1N2
TI = (---- + N0) * 5 ns
      256

N1N2 = 257 * (N1 - N2)

where N0, N1 and N2 are the actual hardware counters.

An incorrect count in N0 would give a jump in counts of 5 ns, however when
averaged over 100 samples each occurence would contribute 50 ps and the shift
due to N0 count errors would result in 50 ps variations. Since you see integer
nanosecond jumps you could be running on the mere 5% chance on each measurement
run to be an integer ns offset and for muliple events just do the math and you
see that it is highly unlikely if we assume statistical even spread.

An error in N1 or N2 would result in a similar pattern since you get

      257
TI = (--- (N1 - N2) + N0) * 5 ns
      256

       1
TI = (--- (N1 - N2) +  (N1 - N2) + N0) * 5 ns
      256

Thus each sample error on N1 or N2 would result in about 5.02 ns.

I am starting to lean towards some processing error.

> Maybe it's an "anti-coincidence" calibration issue?
>  
> In the attached PDF you can see it jump back and forth by about 1 or 2  
> nanoseconds. I have seen it jump 5 or more nanoseconds as described  above.
>  
> It happens (repeatably) at around 13.5 nanoseconds.

Interesting.

> Has anyone seen this as well?

Gotta look.

Oh, somebody have some HP5370B code for a Linux box with Linux-GPIB driver
laying around? I have never really come to terms with that API which is
"classically" used. Never seen a good enought documentation of it and how it
should be used.

Cheers,
Magnus