The DAQ FAQ - last revision Feb 5, 2004

The first draft at a DAQ FAQ, mostly from the past couple of weeks. Questions, comments, and additions welcome - please send to nees-daq@mcs.anl.gov

Q1: Rates, channels and limits. How fast can the current code go?

A: The driver has been tested to ~5MB/sec; it has no limits on number of channels or sampling rate; it just forwards data. The bottleneck at last test was how fast Labview could send data. There is also a large dependance on the speed of your DAQ PC. To test this yourself:

Start the driver, and point it to your DAQ machine like so:
```
./driver --daq_machine daqname --nsds_machine daqname
```
Run 'stress test fake DAQ', start with about 128 channels. (This program just generates N channels of data, and sends them as fast as it can. In the CVS archive with the rest of the code)
Run the server daemon
Run 'NSDS stress tester'. This subscribes to all available channels, and displays approximate rates in terms of bytes/sec and data points/sec.

Note that this test is slightly worse than real life, in that the DAQ PC has to deal with both sending and receiving data. If you have another labview machine, run the NSDS stress tester on it for a more accurate result

Post your results to the nees-daq@mcs.anl.gov list!

Q2: Decimation. How can we stream less than the full rate of 1 or more channels?

A: Several ways are possible:

Don't call the 'tcp send' routine with every data point. This is local decimation.
Modify the driver to drop as required
The NSDS should handle decimation; I defer to ISI for an answer

Q3: Calibrations. How are calibrations stored and tracked?

A: Currently, the DAQ code uses National Instruments' facility for these, the 'MAX' program. It handles channel definitions, units and calibrations. The alpha1 code reports the units as defined by MAX, e.g. 'C, V, kpa', etc. It would not be difficult to add code that would extract calibrations from MAX, and add them to the metadata header. Users wanting to recalibrate or reprocess their data should save both raw and engineering units for the immediate future.

Calibrations are an area of debate in the SI group, so please let us know your requirements in this area. Suggestions are welcome!

Q4: Labview hardware, drivers, and Linux: What hardware do we recommend? Will this work on Linux?

Many people wanted to know what we've tested on, and what we recommend. Several also asked if they could run the code on the Linux version of Labview, perhaps on the NEES-POP.

A: LabVIEW only supports their direct-attach DAQ hardware (PCI cards, firewire) under Windows. Remote-attached hardware (i.e., ethernet or GPIB-connected) are supported on all platforms. There are freeware Linux drivers for the E-series PCI boards; we have not tested them. Much of the non-DAQ code was actually written under Linux.

We have locally: PCI 6036E, Firewire 6050E and 6070E.

For Linux, there are other companies that have drivers for their DAQ cards; we have one that we've not tested yet. It's info:

 Vendor:
 Name: United Electronic Industries
 Address: 611 Neponset Street
 City: Canton
 State: MA
 Zip: 02021
 Tel: (800) 829-4632
 Fax: (781) 821-2891
 EMail: sales@ueidaq.com
 URL: http://www.ueidaq.com/

 Item Number: (1 of 3)
 Brief Description: Lab PCI multifunction DAQ card
 Model Number: PDL-MF
 Cost/Unit: $595.00
 Quantity: 1
 Subtotal Cost: $595.00

 Item Number: (2 of 3)
 Brief Description: Breakout for DAQ card
 Model Number: PDL-STP
 Cost/Unit: $100.00
 Quantity: 1
 Subtotal Cost: $100.00

 Item Number: (3 of 3)
 Brief Description: Cable to connect DAQ to breakout
 Model Number: PDL-CBL-100
 Cost/Unit: $50.00
 Quantity: 1
 Subtotal Cost: $50.00


 Total Cost: $745.00

Q5: Replacing the driver and/or Labview code, to use a different system

A: Best place to start are the documents covering the NSDS-driver protocol and the driver itself, found at http://www.mcs.anl.gov/neesgrid

I will also post my slides from this weeks' meeting, which go into detail about the protocol and how to speak it. They will be on the same website, and probably on neesgrid.org as well.

The protocol is quite simple, and should be easy to emulate. As an aid to that, we supply a couple of programs that simulate a Labview DAQ:

fake_daq, C code in the 'fake_daq' cvs package. Simple 2-thread code to stream N channels of sine wave data at a user-specified rate. Lots of source documenation via Doxygen, see the html subdirectory.
nees-di, C code in the (new!) 'nees-di' cvs package. Reads from a Dataq DI-194{RS}, and streams it out via the driver. This code is currently only in use at a couple of sites, and so may still have bugs.
nees-adxl, C code in the 'nees-adxl' package. Reads and streams data from a Crossbow 2-axis accelerometer. See the page for details, please.

Q6: How do I know if the code on the nees-pop is working?

A: Alpha1 is short on test cases and verification; expect this to improve over time. To test DAQ code, you can use any of several NSDS emulators in the lv-programs archive. To do so:

Run the driver, and tell it that the NSDS in on the DAQ machine:
```
./driver --daq_machine daqname --nsds_machine daqname
```
Run the server daemon on the DAQ
Start your DAQ program
Start the 'NSDS Simulator', enter a valid channel name, and run it

(Order of these steps is not critical, though DAQ should be running before you run the NSDS sim)

This will connect, subscribe and plot the channel you specify. There's also code in the archive (NSDS stress tester) to subscribe to all channels, but it doesn't plot or save the data it gets. I'm working on code to subscribe and plot multiple channels; it's in there now but has a few bugs to eradicate before its useful.

The driver, server daemon, daq code and NSDS simulators are long on debug and progress messages - I have a display field in the bottom of labview applications that displays status and progress messages.

You should also run the DNDTester protocol validation tool. This is Java code that will thoroughly test any implementation for compliance. Highly recommended!

Support

This work was supported primarily by the George E. Brown, Jr. Network for Earthquake Engineering Simulation (NEES) Program of the National Science Foundation under Award Number CMS-0117853.

Links

Back to MCS NEESgrid page