Data Acquisition System Considerations

Capturing Raw Data

It is generally good practice to capture the raw data and record it for later detailed analysis. There are several good reasons for recording raw data as opposed to processed data. These include:

• Raw data is frequently more compact requiring less storage space and lower system throughput. A typical 16-bit ADC generates 2 bytes of raw data for each conversion. When converted to engineering units it takes 4 bytes (32-bit floating point) to 8 bytes (64-bit floating point) to represent the converted data sample.
• Once data is converted (e.g. to engineering units based on calibration information available at acquisition time) it is difficult to apply new calibration information should the original calibration be found inaccurate.

Exceptions to the above occur when it is possible to significantly compress the data by some amount of preprocessing such as digital filtering and decimation, using n-point averages, signal averaging, etc.

Time Coherency and Synchronization

It is generally important to acquire data in a time-coherent manner especially where one is expecting to extract time-dependent information from the data---which is typically the case. In such applications it is frequently important to be able to relate data from different sensors in time as well as having a uniform sample interval for each sensor. Depending on the degree of synchronization required this can be problematical with some configurations, especially when the system is physically distributed.

The Grand Interconnect provides a number of features that insure that data is captured synchronous with a precision internal crystal clock or an external clock. Furthermore, data samples in the data stream are organized in a pre-determined fixed relationship with time, i.e. the sample time can be reliably correlated with the relative position of the sample in the data stream.

When the I/O chassis are co-located, it is possible to share a common clock between chassis. The VXI Slot-0 Grand Interconnect Controller V160 provides the capability of sharing a common 10 MHz system clock as well as one of the 8 VXI TTL trigger lines across multiple chassis using a coax cable.

The interconnect also supports a "broadcast'' trigger message that can be used to synchronize clocks in different I/O chassis. Each slave node includes a presettable delay counter that "delays'' a synchronization pulse generated from a broadcast trigger message. By presetting the delay counters in each slave node by an appropriate delay factor, it is possible to compensate for the fixed delays encountered by the trigger message to each node.