[comp.sys.hp] Help! HP16500A analyzer control via RS-232 port

curtis@megatek.UUCP (Curtis Popoff) (05/31/91)

    Help!  I'm trying to control my HP16500A logic analyzer via the
serial port so as to dump its trace aquisition buffer out of the serial
port.  I've figured out how to control the thing and get the data, but
it stops sending data too early.  Has anyone else had similar problems
or have a solution?

    I've got an HP16500A logic analyzer configured with 16540A/
HP 16541A 100 Mhz State Analyzer Modules and a HP16515A 1 Ghz Module.
I'm trying to convince the silly thing to dump the ENTIRE trace aquisition
buffer out via the serial port.

    I send out a ":sel 4" via the serial port to select the 100 Mhz
module (master).  And then I send out a ":syst:data?" command and
start saving the data the analyzer sends out the serial port.  Everything
is cool at this point except that the analyzer stops sending data
after 819+ states.

    I've decoded the data file is sends out and compared it against the
trace info display on the analyzer screen and all the data looks correct.
Looking at the header info it is sending out, it says that its going to
be sending 114748 bytes of data, that there's 10 pods hooked up (correct),
and that its sending 4096 states (also correct).  The amount of data
it actually sends is 16455 bytes.  Where did the rest of my data go???

    The 16455 bytes of data consist of:

        Section length of 10 bytes "#800114748"
        Section header of 16 bytes (bytes 12-15=0x1402C=81964 bytes)
        Data preamble description of 44 bytes 
            bytes 0-1=0 (hmm.. manual says should be 16540)
            bytes 2-3=0x1b44 (hmm.. is this valid?)
            byte 4=2 state data (correct)
            byte 5=0x0A=10 pods (correct)
            byte 6-7=0x1000=4096 states (correct; note: doc says this
                will be between 0 and 4095, hmmm..)
            byte 8=1=trace point was seen (correct)
            byte 9=0 (not used)
            bytes 10-11=0x0800=2048 (correct? range on the analyzer
                is -2048 to 2047, trigger point 0, which is 2048
                states after 1st one stored)
            bytes 12-19=0x0000010800000110 (not used)
            byte 20=1=time tags (correct)
            bytes 21-33=0x00000000000000000000000000 (pod clocking)
            bytes 34-41=0130000001380000=? (sample period:should be 30 ns.)
            bytes 42-43=0x0140 (not used)

    This adds up to 10+16+44=70 bytes of header.
    Total data 16455-70=16385 (suspicious looking number 16384+1).

    Since I have 10 pods connected, I should have 20 bytes of info per
state.  BOTEC 20 bytes*819 states=16380 bytes leaving 5 bytes of extraneous
info.  The last byte in the file is always appears to be a newline (0x0a).
The other 4 bytes appear to be valid pod data.  The HP gives up the ghost
after sending 16384 bytes of data.  Is this a bug in the HP serial output
not allocating i/o buffers larger than 16Kb?

    Now to confirm that its not the receiving system not accepting more
than some fixed buffer size for input, I connected the HP directly to a
terminal and hand typed the commands in to dump the aquisition buffer.
It stops dumping after ~16 seconds (by my watch), which when running
at 9600 is about 16K of data.  It should have taken almost 2 minutes to
dump the whole trace out.

+----------------------------+-----------------+----------------------------+
|Curtis Popoff               | Don't sweat the |       curtis@megatek.UUCP  |
|Megatek Corporation         |   small stuff   |        uunet!megatek!curtis|
|9645 Scranton Road          |                 |         ucsd!megatek!curtis|
|San Diego, California  92121|     It's all    |hplabs!hp-sdd!megatek!curtis|
|(619) 455-5590 x2620        |   small stuff   |  ames!scubed!megatek!curtis|
+----------------------------+-----------------+----------------------------+