[time-nuts] Prologix GPIB-NET, HP 5370A, HP5334A problem?

[wje]

   Yes, that was essentially what I was seeing over a few runs. The
   failure times I saw were on the order of 2-4 hours.
   I've moved my 5370 over to a UPS, along with the Prologix and the
   router, and I'll see what happens. I have to wait until my 3-day 5334
   run finishes, though. I'm measuring long-term phase difference between
   my 5061A and my Z3801A. The 5334 has been running solidly for 1.5 days,
   so I can eliminate power problems at this point.
   This brings up another question. I'm seeing cyclic phase variations of
   about 10 ns with a pretty regular 1 hour cycle. The overall long-term
   average is OK, 1e-13 ADEV at 6000 seconds. I'm guessing this has
   something to do with satellite orbits, but I'd welcome any
   explanations.
   As for the 5370A bug, there was a thread a while back in time-nuts
   describing a bug in the GPIB controllers for the 5370A's that would
   occasionally and randomly cause a bus lockup. This problem was
   supposedly fixed in the B series. That's all I've seen on the issue, so
   it's possible that the bug doesn't actually exist. If I still get
   failures, I'll swap in a controller from my spare 5370 and see if
   there's any difference.
   BTW, I've been doing precision AC and DC measurements for a long time,
   but I have to say that high-resolution time/freq measurements are even
   more fun!
Bill Ezell
----------
They said 'Windows or better'
so I used Linux.

   John Miles wrote:

I'm not familiar with any GPIB bugs on the 5370A, but I moved your code over
to C and ran it on my 5370B via a GPIB-LAN adapter.  The test app failed
after ~6 hours with a Winsock timeout error.  I'm thinking that was caused
by a power glitch, though, because I actually had to power-cycle the counter
(rather than the Prologix dongle) to get the program running again.  Was
that your experience?

Since then it's finished a 24-hour run without any sign of trouble.

-- john, KE5FX




   If the 5370A problem is actually the 5370A gpib controller bug, then I
   don't think it can be reproduced with the 5370B; I'm pretty sure that
   was fixed in the B model.
   However, if you want to give it a try, here's what I do (you'll have to
   interpret, but it should be pretty clear)...


C version:

   GPIB_connect(atoi(argv[1]),
                GPIB_error,
                0,
                20000); // Set 20-second timeout

   GPIB_set_EOS_mode(10);
   GPIB_set_serial_read_dropout(20000); // 20-second dropout

   GPIB_write("SS2");   // Sample size = 100
   GPIB_write("MD2");   // Lock out rate control, hold until MR
   GPIB_write("AR1");   // +T.I. arming only
   Sleep(2000);

   GPIB_write("MR");    // Manual read (discard first reading)
   Sleep(1000);

   for (S32 h=0; h < 24; h++)
      {
      for (S32 m=0; m < 60; m++)
         {
         for (S32 s=0; s < 60; s++)
            {
            GPIB_write("MR");
            Sleep(1000);

            printf("%d:%d:%d  %s",
                        h,m,s,
                        GPIB_read_ASC());
            }
         }
      }


_______________________________________________
time-nuts mailing list -- [1]time-nuts at febo.com
To unsubscribe, go to [2]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

References

   1. mailto:time-nuts at febo.com
   2. https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts