Vernier LabPro - Manual (Page 23)

Revision Date: 08/02/02
LabPro Technical Manual 23
One significant difference is that trying to read from USB will not return 0 bytes of data, like an empty
serial port call. Instead, the call blocks until data is available from the LabPro. This occurs because LabPro
sends a NAK (Not Acknowledge) response until data is valid. The device driver will then wait, blocking on
the read, until the data is there. This means that the software read function will not return until the data is
ready. If this is an issue, the read request can be put in a separate thread so that the main thread can
continue to run. Third party drivers are available to create the abstraction of an input buffer similar to the
serial port operation.
The operating system in LabPro was written to make the USB interface as similar as possible to the RS232
serial interface. Getting data using USB works similar to getting data through the serial port, with some
subtle differences.
There is no checksum character for binary data, since the USB protocol already includes error detection.
Since the data is transmitted in multiples of 64 bytes, it is possible that there will be extraneous data in the
last 64-byte packet. The application software needs to know when to stop reading the buffer. In ASCII
mode, looking for a carriage return character can do this. In binary mode, it is only necessary to keep track
of the number of samples requested, and read the appropriate number of bytes.
In real time binary mode, each real-time sample is returned as 16 bits. The data is formatted as in the
RS232 design, then 0-padded up to 16 bytes. Real-time binary data is normally returned with 1 real-time
sample per USB packet. This allows roughly 1 sample/ms transfer rate, depending on loading conditions
and host controller design. If real-time sampling occurs faster that USB packets are delivered to the host,
there will be gaps in the real-time data. To allow deeper buffering of the sample data (and thus faster
sampling rates), there is an option to pack more than one sample per USB packet. The binary mode
command has an optional parameter to specify this packing. The command format is {4, 0, -1, X} where X
is the number of samples to place into one USB packet. X must be a value from 1 to 4. If no value is
specified, the default is 1. One consideration in applying this scheme is this: if USB packet delivery is
sufficiently delayed in this case, each delayed packet results in a gap that is larger than a single sample
time.
Communications Speed Limitations
LabPro may operate in two modes; real time (RT) and non-real time (NRT). In RT mode, LabPro returns
each sample as it is collected. However, the serial port or USB port have limitations on how fast they may
transfer data. The setup limitations depend on the data rate, the number of samples requested and the
length of the experiment. The primary factor for decision making is the number of active channels. From
that information, the determination of maximum rates etc. can be calculated.
When using LabPro in RT, the samples are not stored internally. Therefore, the max number of samples
and, consequently, the experiment length is limited by the software.
When using LabPro in RT mode over the serial port, the number of bytes per data point is 2*# of active
channels+4 (time bytes) + 1 (checksum) (see above information for details). This translates to
7,9,11,13,15,17 bytes per data point for 1 to six channels (four analog and two sonic) respectively.
Therefore, at a transmission rate of 38400, we can assume 10 bits/byte for a throughput of 3840
bytes/second. Using the timebase options above, we have the following theoretical limits imposed on real
time collect mode for serial port:
500 samples per second max. 1 channel active
250 samples per second max. 2 - 4 channels active
200 samples per second max. 4 - 6 channels active