Connect with us

Performance of GPIB (with Tectronix scope)

Discussion in 'Electronic Design' started by GPIB Guy, Apr 28, 2004.

Scroll to continue with content
  1. GPIB Guy

    GPIB Guy Guest

    I have an ICS Electronics GPIB card and I'm using the Quick Basic
    libraries that came with it to code a program that captures a section
    of the displayed trace. The scope is a Tectronix TDS-210.

    The first version of the program used the RS-232 port and I was
    capturing 512 samples of the captured trace (out of a possible 2500
    points). I am capturing thousands of traces in a sequential manner.
    The throughput using the RS232 port was about 1 capture per second.
    With the new code for the GPIB port, I can capture about 3 traces per
    second. I was expecting a MUCH higher capture rate given that GPIB
    has a stated transfer rate of at least 200k bytes per second.

    So, my question is this: Is it typical that certain GPIB cards or
    hardware has effective transfer rates that are much below GPIB spec,
    or is this a case where the command or instruction-processing within
    the device (TDS-210 in this case) is incredibly slow?
  2. CFoley1064

    CFoley1064 Guest

    Subject: Performance of GPIB (with Tectronix scope)
    Hi, GPIB Guy. GPIB and QuickBASIC together almost guarantee slower results in
    IEEE-488. Here are some suggestions:

    * I strongly recommend against running DOS in a window with GPIB if you're
    trying to move things along. I know it can be done, but please don't.
    Dedicate granny's old '486 which has been sitting in the attic for 5 years to
    running your data acquisition setup alone as a dedicated DOS system. The days
    where we had to conserve hardware because of cost/availability are long gone --
    thousands of working PCs are converted to landfill every day. Make sure you
    use at least a '486 with the ISA board. Faster clock speed won't affect ISA
    throughput to the GPIB board, and it will act like an ankus on QB, getting it
    to go faster.

    * Since you've got QuickBASIC (lector emptor -- I've only got experience
    programming GPIB with v.4.0 and 4.5), have you tried doing a compile? I'd stay
    away from the dreaded "P-code interpreter" except for the debugging phase at
    all costs. Also, doing a compile is a good check on some problems, depending
    on how you massage your settings. Being in QB, you tend to forget the
    satisfaction of a clean compile (and incidentally occasionally also forget to
    save before exit -- ouch ;o).

    * You've probably got some kind of ONERR statement available in your program.
    If not, put one in there, and output *all* errors of any type to something.
    Look at them. One of the annoying parts of QB is that you can set it up to run
    just about anything, no matter how kludgy or error-ridden. A special note here
    for memory issues if you're using 4.5 in interpreted mode -- the help facility
    is a pig, and your ONERR might reveal some memory problems. Do a FRE

    * Look at what's happening with the hardware dance on the other stuff in the
    computer. DO NOT use disk access during data capture time, not even with a
    RAMdisk (using the DOS disk access interrupt slows things down). You should
    also avoid doing screen updates if you can help it (errors above can go to an
    array like your data -- the error codes are integer, and you can look them up
    after). The idea is that your ICS board is dancing with a rather slow, clumsy
    elephant in QB. Use the ankus, make it so QB stays out of the way while you're
    busy. GPIB boards timeout and have to resynchronize when the program takes too
    long doing something -- that slows things down a lot.

    * If you've got any anti-virus software running, lose it immediately. I doubt
    there are many hackers out there waiting to prey on unsuspecting DOS systems.
    The anti-virus software will see a DMA or IRQ and flag it just long enough to
    check if everything's OK. That might be too long, giving you a bus timeout.

    * Look at the hardware settings on your ICS board again. If you've bypassed
    DMA access (the board I used had jumpers and DIP switches to set these things),
    that could be your problem. You just might have to stop the boat and get that
    DMA working. If there are conflicts on all DMA, you might have to remove some
    other hardware from the PC or get another one.

    This isn't a complete list, GPIB Guy, but it should get you started. If
    you're looking for speed, try upgrading your drivers libraries for C. If you
    use TurboC++ 3.0/TurboC 2.0 or M$ QuickC, you'll almost certainly get better

    Good luck
  3. CFoley1064

    CFoley1064 Guest

    Subject: Performance of GPIB (with Tectronix scope)
    And, as always, RTFM (Read The Manual). I haven't used the TDS-210 with GIPB,
    but I'm certain the manual will tell you what your maximum throughput will be.
    Your limitation *is* the instrument, not the GPIB bus. Also, you might be able
    to program the TDS to help you. That information will also be in the manual.

    Feel free to email if you have any questions.

    Good luck
  4. GPIB Guy

    GPIB Guy Guest


    I talked to a Tektronix support guy today and specifically asked about
    the TDS-210 and the specs of the "trace?" command. Turns out that the
    best that the 210 can do (and pretty much all Tek scopes) is to
    transfer a complete trace in anywhere from 300 to 320 ms. I was told
    that all Tek scopes behave this way when it comes to GPIB.

    My own benchmarking reveals that when requesting trace down-loads of
    variable lengths (from 32 to 2500 points) that there is a consistent
    fixed delay of 250 ms (1/4 second). The data itself is tranfered at
    between 8k and 12k points (bytes) per second. Basically I was able to
    repetitively acquire complete single-channel traces of 2500 points at
    the rate of about 1.9 per second. This is with an ICS Electronics
    GPIB card (PCI) in a P-4 computer (2.6 Ghz) running Windows 98 and
    running a compiled quick-basic program from the command prompt.

    When I described my application (aquiring thousands of traces from a
    custom piece of hardware where each sample is 512 points acquired from
    a 10 us window) the Tek guy suggested I use a TDS 5000 ($7300) because
    the 8 mb of trace storage capacity can be segmented to store the
    traces in sequence and then I can dump or spool the data out of that
  5. Sean M.

    Sean M. Guest

    Hi GPIB Guy,

    Sometimes the instrument is the limiting factor, other times your
    computer/GPIB card are the limiting factors. With some GPIB controllable
    instruments, you can output all of the trace data (one or more axes) as one
    stream, with a specific character separating the individual data points in
    the stream (e.g. all 512 data points are output at once, with a comma
    between the data for each point). With some other instruments, you have to
    explicitly ask the instrument for each data point coordinate (e.g.
    amplitude/time) individually (e.g. point 1, point 2, point 3......point
    512). Asking for each data point individually can sometimes decrease the
    data transfer rate. Also, the format by which you read the data from the
    instrument (string, real, scientific, etc.) can affect the transfer rate.

    Do you know if the Quick Basic libraries are reading the data in either of
    the ways I've described above? Do you have access to the source code? (I've
    worked with Basic, but not with Quick Basic).

    Also, have you investigated whether a Tektronix data acquisition program
    will work for you? Test equipment manufacturers sometimes write easy to
    use data acquisition software and make it available with/for the
    instruments. I just found something about Tek's WaveStar software here:,,60-12123-INTRO_EN,00.html

    I hope that helps...good luck to you,
  6. GPIB Guy

    GPIB Guy Guest

    I'm pretty sure that in this case it's the Tek scope that's the
    limiting factor. A 2.6 Ghz P-4 computer isin't going to be a limiting
    factor I don't think.
    No - not in this case.

    The TDS-210 can send the trace data to the computer as either ASCII or
    binary. You can set the START and END data points (where the defaults
    are 0 and 2500) and when you send the "trace?" command it will respond
    by streaming the values in sequence (I think there is a 10 or 12 byte
    header sequence first). The data is 8-bit (1 byte) per sample (ie
    they are signed integer values).
  7. DarkMatter

    DarkMatter Guest

    Quite informative material. This is very useful.

    Thank you.
  8. GPIB Guy

    GPIB Guy Guest

    Heh. What's the point of having a "fast" GPIB card if the damn
    instruments connected to it have such lousy latency or internal GPIB
    instuction-handling characteristics? I'm getting burst data transfers
    of between 8 and 12 k/second. That's pathetic - and don't tell me
    it's the card's fault.
    The TDS-210 (and it's sucessor the TDS-1000 series) costs about
    $1000. Show me a dual-channel PCI card capable of 1 or 2 giga-samples
    per second capture (for the same price or less).

    Actually, for the settings I'm using, 200 mhz sampling from each of 2
    channels is the most I need, and I can even do with 50 mhz sampling @
    8 bits.

    But I still think the Tek scopes are a bargain for what they can do
    compared to a dedicated PCI card. I had hoped their implimentation of
    the GPIB was more speedy.
  9. Chris Carlen

    Chris Carlen Guest

    Our experience with other Tek models, I think fromt the 7000 series have
    been entirely consistent with these comments.

    Good day!

    Christopher R. Carlen
    Principal Laser/Optical Technologist
    Sandia National Laboratories CA USA
  10. perfb

    perfb Guest

    FYI - re Tektronix 'Wavestar' - I have used this on Tek TDS/THS scopes,
    and as far as I can see it is not 'built for speed'. It does a credible
    job of downloading and archiving scope files, once one has deciphered the
    cryptic interface. But as far as automating rapid i/o, I dont think it
    can beat hand-coded software, BASIC or otherwise.

    IMLE, data transfer specs are never really realized in real world apps
    no matter what the application:
    VME/VXI/PCI/GPIB/IEEE1394/RS232/USB1/USB2/IEEE802.11 etc.

    fwiw, I would agree a dedicated NI PCI scopecard would most likely achieve the
    fastest capture rate, but would not be less expensive than a TDS2xx/3xx scope,
    esp when adding in Labview full system cost,
    and software would be considerably more complex as NI canned apps are typically
    very limited in functionality, and it takes considerable hair-pulling to
    delve into their buggy libraries to get it to finally do what you want.
  11. legg

    legg Guest

    You must have some pretty interesting SW, to read and interpret these
    traces for you.

    I find it takes quite a while to figure out what a single trace is
    really telling me.

    Are you collecting this info for some other poor smuck to wade through

    If you're sorting for a specific event, you might find that the scope,
    if properly set up, can find it. Then you've got a lot less info, but
    it is closer to being relevent, and worth looking at.

  12. DarkMatter

    DarkMatter Guest

    "Their implementation"??? Da Bus is Da Bus is Da Bus...

    The problem appears to be with their compilation of the data to be
  13. Dave Cole

    Dave Cole Guest

    Pardon my ignorance, but what does 'ankus' mean?
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day