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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts