Performance of GPIB (with Tectronix scope)

[GPIB Guy]

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
har
dware 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?

[LesHammer]

> 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 is incredibly slow?"

Short answer is "yes". 🙂

I've seen incredibly great differences in GPIB speeds based on:
Language (BASIC was slow - didn't try QuickBasic)
Computer
GPIB Card
Instrument

Some set-ups could see a 50ms overhead just for an ID query. (Try timing 100 id queries to get an idea of your command overhead.)

That 200k bytes/second is a burst rate with a tail wind. (Special set-up with some delays turned off.)

OTOH, 3 traces/second does seem a bit slow. You may see an improvement with better hardwar
e.

Les Hammer

[GPIB Guy]

Les Hammer wrote:
>
> > 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 is incredibly slow?"
>
> Short answer is "yes". 🙂
>
> I've seen incredibly great differences in GPIB speeds based on:
> Language (BASIC was slow - didn't try QuickBasic)
> Computer
> GPIB Card
> Instrument
>
> Some set-ups could see a 50ms overhead just for an ID query.
> (Try timing 100 id queries to get an idea of your command
> overhead.)
>
> That 200k bytes/second is a burst rate with a tail wind.
> (Special set-up with some delays turned off.)
>
> OTOH, 3 traces/second does seem a bit slow. You may see an
> improvement with better hardware.

FYI:

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
buffer.

[Sean M.]

"GPIB Guy" wrote in message news:408FB31B.A9AB00BF@Guy.com...
>
> 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?


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:

http://www.tek.com/site/ps/0,,60-12123-INTRO_EN,00.html

I hope that helps...good luck to you,
Sean

[GPIB Guy]

"Sean M." wrote:

> Sometimes the instrument is the limiting factor, other times your
> computer/GPIB card are the limiting factors.

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.

> 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).

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).

[DarkMatter]

On Wed, 28 Apr 2004 21:03:35 -0400, GPIB Guy Gave us:


>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
>buffer.


Quite informative material. This is very useful.

Thank you.

[Dennis_Knutson]

If you need much faster data transfer rates than what the scope or the GPIB board (you're using a very slow model, btw) can give you. I would recomend a pci scope card. Several manufacturers, including NI, make them and the data moves across a 32 bit bus at 33 Mhz. They are usuually much cheaper than a standalone scope as well. Unless you absolutely have to have something on a bench with knobs that you can physically twiddle, you might be better off with something inside the pc.

[Chris Carlen]

GPIB Guy wrote:
> FYI:
>
> 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.


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
crcarle@sandia.gov

[perfb]

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.


> > 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?
>
>
> 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:
>
> http://www.tek.com/site/ps/0,,60-12123-INTRO_EN,00.html
>
> I hope that helps...good luck to you,
> Sean