[time-nuts] Programming of 5370B

[Daun Yeagley]

Hi David

You have hit on the exact reason the 5370 has a binary transfer mode.  This mode
essentially transfers the bits directly from the counter hardware to the bus.
Remember this counter was designed and built quite a few years ago, and the
processor in it is rudimentary at best by today's standards.  It took a *lot* of
time for it to format up the numbers into ASCII!  I'm not sure if it was
specifically stated in the manuals, but it was a well known fact that to get any
speed at all, you had to use the binary format.

Daun

-----Original Message-----
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On
Behalf Of David Kirkby
Sent: Tuesday, May 31, 2005 4:47 PM
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] Programming of 5370B


I was going to send this to Poul-Henning Kamp personally, but thought it
might be useful to put here, as the discussion might be useful to others.

BACKGROUND.
I was aware Poul-Henning Kamp had written some software to read from the
HP 5370B TI counter.

I asked him to send it to me, which he did. After getting Solaris
drivers for my GPIB card, the software was reading around 4000
measurements/second on my old Sun (4x450MHz) which was not too different
from the 5000 on his OpenBSD box. (I doubt CPU performance is a limit,
but probably bus speed).

Poul-Henning Kamp's program was reading in binary mode and I had some
difficulty working out exactly how the numbers were obtained from all
the shifts and logical operations. Things such as:

                 n0 = (buf[3] << 8) + buf[4];
                 if (!(buf[0] & 0x20))
                         n0 = -n0;

                 n12 = ((buf[0] & 3) << 16) + (buf[1] << 8) + buf[2];
                 if (n12 & (1 << 17))
                         n12 -= (1 << 18);

are not too obvioous, although they seem to work very well.

I took the software and some of the ideas to write my own, so I
understood it. I learnt one thing for sure - I can write slower
software!! But at least I understand it.

What I did do however (for simplicity) was to read the data in as the
standard ASCII, which is the default output data format of the HP. I did
not use binary.

The 5370B manual says each measurment consists of about 5 differnet
parts, all of which add up to exactly 23 bytes.

For TI, a measurement might something like:

TI = 9.98898989E-08\r\n

but will be exactly 23 bytes.

But I am getting very poor performance, with around 63ms between each
data point collected (around 16 results/second), which is a lot poorer
than the 4000 measurements/second I was getting with  Poul-Henning
Kamp's program. I suspect this is the result of reading with ASCII, but
would be interested in comments.

The program I wrote is called 'hptic' and takes options for function
(time-interval, frequency etc), as well as SD etc. It uses
autoconf/automake and accepts long options, so it should be pretty
friendly if I get the peformance up.

The program prints a couple of lines of notes, including the GPIB string
the program actually sends to the counter. In this case its just 'FN1'
for time-interval.

sparrow /export/home/drkirkby/5370B-code/src % hptic --function
time-interval --text "Note the long delays on TI too"

# Note the long delays on TI too
# Sending FN1 to the HP 5370A or 5370B Time Interval counter
t= 0.000000615 TI= 9.979e-08
t= 0.062570361 TI= 9.982e-08
t= 0.124602710 TI= 9.977e-08
t= 0.186614622 TI= 9.979e-08
t= 0.248818597 TI= 9.973e-08
t= 0.311027399 TI= 9.975e-08
t= 0.373508745 TI= 9.973e-08
t= 0.435905975 TI= 9.975e-08

It basically has a loop:

while (1) {
ibwrt(device_descriptor,cmdstring,strlen(cmdstring));
ibrd(device_descriptor, buf, 23);
print_results(buf);
}

I seem to be transferring about 16 measurements/second, with each
needing 3 bytes written and 23 read, making a total of just
16*(23+3)=416 bytes/s. I've no idea of what the bus should support, but
clearly this is very slow.

I know when I stuck the ibrd command into a bit of software supplied
with Labview (I'm not using Labview, but one of its tools is handy for
testing GPIB command), the counter returns more than one result at a
time, but I am not sure that number of results returned is consistent.
It might be consistent with just TI in mean mode, but try to do
something else and the number of bytes returned is very different.

At least reading 23 bytes I can guarantee to get one measurement and
only one measurement, but I suspect this is slowing me down.

BTW, I see some note from you about your program Allan.tgz and attempted
to compile it. Neither Sun's make of gnu make could handle the makefile,
but there seems nothing much to it, so it should compile once I remove
the err.h and the fpsetmask(FP_X_UFL), which my Solaris box croaks on.

There was one thing I noticed looking at your program. If I am not
mistaken, you are creating a lookup table of sines and cosines, rather
than compute them as you need them. Have you actually checked whether
this is faster on your processor than just computing them as needed? I
know this is a trick used to speed things up, but I've found it slower
on some modern CPUs. Certainly on modern Suns, reading from lookup
tables is slower than calling sin() or cos().

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