What You’ll Learn in this Article 

System Requirements for Correlated Measurements

The degree to which data can be analytically correlated comes down to the degree to which the various measuremeents are synchronized in time. Synchronized data guarantees that every sample in a dataset, regardless of sensor or measurement type, shares a common timing reference. Without it, cause-and-effect or event-correlated relationships between measurements cannot be established with confidence.

A system that delivers truly synchronized data must satisfy the following criteria:

• Single timing source - All sample clocks derive from the same oscillator (or clock), which elimnates drift between channels and ensures timing relationships remain stable over the duration of test. Note that not all measurement channels need to have the same sample rate in order to be synchronized, but rather, the sample clocks are derived from the same reference.

• Shared start trigger - Acquisition begins across all channels at the same defined moment. This establishes a common t=0, so relative timing between measurements across channels is knowna nd fixed.

  
  

How NI cDAQ Simplifies Synchronization

The chassis architecture of the NI cDAQ provides a single, unified timing source shared by all installed C Series modules. This shared timing source is foundational to acquiring synchronized data from disparate measurement and signal types. NI C Series modules span a broad range of measurement and signal types; any combination of these modules can be installed in the same NI cDAQ chassis, which provides the same unifying onboard timing source.

Each NI cDAQ chassis include up to three independent analog input timing engines, which enable simultaneous, mixed-rate acquisition. For example, a thermocouple measurement, which typically requires slower sampling rates, and a vibration measurement, which typically necessitates faster sampling rates can be sample at their ideal rates using independent timing engines that are derived from the same timing source.

The NI cDAQ platform addresses each of the correlated data requirements in hardware:

• When full synchronization across all modules is required, all channels can be brought under a single timing engine

• Hardware triggering on digital lines and analog thresholds ensures all tasks begin at a precisely defined moment

• When channel count or physical distance exceeds what a single chassis can support, TSN-enabled NI cDAQ Ethernet chassis extend synchronization across multiple chassis to sub-microsecond accuracy over standard Ethernet, with no dedicated synchronization wiring required

  
  

Two practical considerations are worth addressing before moving to implementation.

• Dynamic Signal Acquisition (DSA) modules introduce a predictable group delay due to their digital filter architecture. NI-DAQmx provides mechanisms to compensate, but the delay must be characterized first.

• Each C Series module offers a defined isolation architecture. Matching that architecture to the grounding characteristics of the signal source prevents common-mode noise from corrupting sensitive measurements

Implementing Synchronized Acquisitions with NI FlexLogger

NI FlexLogger is the recommended starting point for engineers who need correlated mixed-signal datalogging without the need to write code. It handles sensor configuration, data rate assignment, synchronization, and file output through a configuration-based interface, with no programming required.

Setting Up Mixed Channel Types in NI FlexLogger

NI FlexLogger supports a broad range of channel types within the same project, including analog, digital, and counter channels. Each channel type is assigned to one of three configurable data rate levels: slow, medium, and fast. This allows measurement types with different sampling and bandwidth requirements to run at their own appropriate rates within the same project, without oversampling “slow” channels or undersampling “fast” ones.

FlexLogger coerces modules to the nearest common supported rate within a rate level. This becomes important when mixing module types with different sampling architectures:

• Some modules, slow-sampled modules, use a multiplexed converter that limits how fast they can acquire data. When a slow-sampled module shares a rate level with other modules, it limits the achievable rate for the entire group and prevents anti-aliased downsampling from being applied to any of them

• Anti-aliased downsampling to 100 Hz is available for modules that support it, but only when no other slow-sampled modules are assigned to the same rate level

• If modules in the same chassis have incompatible rate requirements or sampling architectures, assign them to different rate levels or place them in separate chassis to avoid unintended rate coercion
  

Synchronization in NI FlexLogger

Within a single chassis, NI FlexLogger synchronizes hardware-timed inputs automatically. No additional user configuration is required for single-chassis correlated acquisition.

For multi-chassis systems, TSN-enabled Ethernet chassis are required for synchronization. Without TSN-capable hardware, NI FlexLogger falls back to software synchronization, which carries unknown skew and drift characteristics and is not suitable for applications where timing relationships between channels matter.

Note: Synchronization across channels and chassis is only supported with an NI FlexLogger Professional license.

Additional synchronization limitations to be aware of:

• Software-timed inputs cannot be synchronized

• PXI and PXIe Digital I/O modules cannot be synchronized with other channel types in FlexLogger

• C Series DSA modules and NI-XNET modules cannot be synchronized in the same USB or non-TSN Ethernet chassis

Implementing Synchronized Acquisition with LabVIEW

When full control over timing, synchronization, triggering, and data handling is needed, NI LabVIEW with the NI-DAQmx driver provides a complete programmatic solution.

Note: The NI-DAQmx driver also supports data acquisition modules in FieldDAQ, NI CompactRIO, and NI PXI platforms, so the programming patterns described here apply wherever the NI-DAQmx is supported across the NI hardware portfolio.

Channel Expansion with NI-DAQmx

Channel expansion is the simplest to achieve multi-channel and/or multi-device synchronization using the DAQmx driver. When channels from multiple modules or chassis are added to a single DAQmx task, the driver automatically routes triggers and sample clocks so that timing and triggering are consistent across all channels in the task. No explicit synchronization programming is required.

Key rules for channel expansion on NI cDAQ:

• All channels in a single task must be of the same type, all analog input, all analog output, or all digital I/O.

• Channels from multiple chassis can be included in a single task when TSN-enabled Ethernet chassis are used

• The DAQmx driver handles clock routing automatically

For mixed measurement types, such as combining analog input and digital I/O in the same acquisition, separate tasks are required. The simplest way to synchronize separate tasks is to specify identical start trigger times.

Multi-Rate Acquisition with Multiple Timing Engines

Each timing engine can support an independent NI DAQmx task, allowing different measurement types to run at different sample rates simultaneously. The driver assigns each task to an available timing engine automatically. Alternatively, the timing engine can be set explicitly using the “Sample Timing Engine” property. Two approaches are available.

Separate tasks at different rates:

• Up to three analog input tasks can run simultaneously, each on its own timing engine at its own sample rate

• Each task operates independently, so measurement types with fundamentally different bandwidth requirements are not forced to compromise

• This is the preferred approach for mixed-type systems where signal bandwidths differ significantly

Single task at the fastest required rate, resampled in software:

• All channels run in a single task at the fastest required sample rate, with slower channels resampled or averaged in software after acquisition

• This approach works on any hardware regardless of timing engine count

• The tradeoff is that post-processing is required to recover the intended sample rate for slower channel types

Note: When a slow-sampled module is included in a multi-module task, it repeats data points to match the task sample rate. This must be accounted for during data analysis.

Structuring LabVIEW Loops for Correlated Acquisition

The recommended approach for hardware-timed correlated acquisition across multiple channel types in LabVIEW is a parallel loop structure, one loop per DAQmx task, each governed by its own timing source.

The NI-DAQmx “Create Timing Source” VI creates a timing source derived from the task's sample clock. This timing source drives a Timed Loop that executes in lockstep with the hardware.

Advantages of this approach:

• Loop execution is driven by the hardware sample clock, not the OS scheduler

• The Timed Loop provides execution timing feedback through the Finished Late node, flagging iterations that did not complete on schedule

• Multi-rate applications use multiple Timed Loops in parallel, each driven by a different task's timing source

• A configurable sleep time between the sample clock event and loop execution allows lower-priority threads to run without impacting acquisition rate

NI TDMS for Correlated Data Storage

Both FlexLogger and LabVIEW with NI-DAQmx can log natively to the NI TDMS file format. TDMS stores raw data at full acquisition rate alongside per-channel timing metadata, including start time, sample interval, and number of samples. With all channels referencing the same hardware timing source, that metadata accurately captures the timing relationships between channels and carries them through to post-processing.

TDMS organizes data in a three-level hierarchy, file, group, and channel, and each level accepts custom properties. In practice, this means test metadata such as operator name and date can be stored at the file level, measurement type at the group level, and channel-specific properties such as units or calibration data at the channel level. This structure makes TDMS files searchable and self-documenting without requiring a separate database or custom header format.

In LabVIEW, the TDM Streaming API is the recommended interface for writing TDMS in a correlated mixed-type acquisition. It is optimized for streaming high-speed data to disk continuously and works on real-time systems. Data from each DAQmx task is written to its own channel group within the same file, preserving per-channel timing metadata and keeping measurement types organized without splitting the dataset across multiple files.

Other file types, such as CSV and custom binary, are available in FlexLogger and LabVIEW. For FlexLogger, the data written to the CSV is limited to 100 Hz per channel. Data acquired at a higher rate will be decimated on export, so the CSV will not reflect the full resolution of the original acquisition.

Correlated Measurement Across NI Platforms

NI cDAQ is not the only platform that enables correlated mixed-type measurements. The NI-DAQmx driver can be used with devices of other form factors, including CompactRIO (cRIO), PXI platforms, and FieldDAQ. For data acqusiition devices, the programming patterns discussed here apply across all three.

• NI cRIO is the right choice when embedded, headless, or real-time processing is required alongside correlated mixed-type measurement

• NI PXI provides the precision and throughput required for high-channel-count, high-speed production test and automated validation environments through its backplane-based synchronization architecture. Clockk sharing is available across the PXI

• NI FieldDAQ provides highly ruggedized, TSN-enabled distributed measurements.

Summary

Getting correlated data from a mixed-type system is not complicated, but it does require the right foundation. NI cDAQ is designed to provide it.Every application has different implementation details, but the underlying requirements are constant:

• Every channel in the system must share a common timing source; the NI cDAQ chassis provides this natively across all installed C Series modules

• Both NI FlexLogger and NI LabVIEW with NI-DAQmx support correlated mixed-type acquisition; FlexLogger through a configuration-based interface, LabVIEW through full programmatic control of every timing and synchronization parameter

• TDMS is the optimal file format that preserves the per-channel timing metadata for data recall and correlated post-processing