Performance of GPIB (with Tectronix scope)

G

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?
 
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.
Click to expand...
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.
 
"GPIB Guy" <GPIB@Guy.com> 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?
Click to expand...

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
 
"Sean M." wrote:

Sometimes the instrument is the limiting factor, other times your
computer/GPIB card are the limiting factors.
Click to expand...
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).
Click to expand...
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).
 
On Wed, 28 Apr 2004 21:03:35 -0400, GPIB Guy <GPIB@Guy.com> 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.
Click to expand...

Quite informative material. This is very useful.

Thank you.
 
Dennis Knutson wrote:

If you need much faster data transfer rates than what the scope
or the GPIB board (you're using a very slow model, btw)
Click to expand...
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.

I would recomend a pci scope card. They are usually much cheaper
than a standalone scope as well.
Click to expand...
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.
 
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.
Click to expand...

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
 
On Thu, 29 Apr 2004 09:46:09 -0400, GPIB Guy <GPIB@Guy.com> Gave us:

Dennis Knutson wrote:

If you need much faster data transfer rates than what the scope
or the GPIB board (you're using a very slow model, btw)

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.

I would recomend a pci scope card. They are usually much cheaper
than a standalone scope as well.

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.
Click to expand...
"Their implementation"??? Da Bus is Da Bus is Da Bus...

The problem appears to be with their compilation of the data to be
sent.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top