High-Speed Data Acquisition: Sample Rates, Throughput and System Architecture

High-speed data acquisition is the capture of analog signals at sample rates well above what general-purpose DAQ handles, typically from about 100 kS/s per channel up to hundreds of MS/s or more, so that fast events such as vibration, shock, electrical transients and pulses are recorded without losing detail. At these rates the hard part is rarely the ADC itself. It is moving, storing and processing the data stream without dropping samples, and keeping every channel aligned in time.

This article is part of our complete guide to data acquisition (DAQ), which covers sensors, signal conditioning, specifications and hardware types. Here we focus on what changes when the signals get fast: how to pick a sample rate, how to size the data path, which hardware features matter and how to architect the system.

What counts as “high speed”?

There is no official threshold. A useful way to think about it is by the bandwidth of the signal you need to capture, because that sets the sample rate and therefore the class of hardware:

Sample rate per channel	Typical signals	Usual hardware
Under 1 kS/s	Temperature, process pressure, flow, slow mechanical motion	Data loggers, PLC analog cards, low-cost DAQ
1 to 100 kS/s	Dynamic pressure, strain, load, audio, motor current	Mainstream multifunction DAQ devices
100 kS/s to 10 MS/s	Vibration and acoustics, shock, power-quality transients, ultrasonic, combustion pressure	High-speed and simultaneous-sampling DAQ, transient recorders
10 MS/s and above	Pulses, reflectometry, laser and photodetector signals, RF envelopes	High-speed digitizers, often with an FPGA

Most systems we are asked to build sit in the middle two rows, where an ordinary DAQ card is too slow or too poorly synchronized, but a laboratory oscilloscope cannot record for long enough or integrate with the rest of the test.

How fast do you actually need to sample?

The Nyquist theorem says you must sample at more than twice the highest frequency in the signal, or high-frequency content folds back into the data as false low-frequency signals (aliasing). In practice, twice is not enough. Real anti-aliasing filters need room to roll off, and you usually want to see the shape of the waveform, not just its frequency. Two practical rules:

• For frequency content (vibration, acoustics, spectral analysis), sample at 2.5 to 4 times the highest frequency of interest, with an anti-aliasing filter set just above that frequency. Vibration analyzers commonly use 2.56 times.
• For waveform shape (shock pulses, transients, edges), estimate the signal bandwidth from its rise time using bandwidth ≈ 0.35 ÷ rise time, then sample at roughly 5 to 10 times that bandwidth.

Worked examples

• Bearing vibration up to 20 kHz: 20 kHz × 2.56 = 51.2 kS/s per channel, with the anti-aliasing filter set at about 20 kHz. A delta-sigma DAQ with built-in filtering is a good fit.
• A shock pulse with a 50 µs rise time: bandwidth ≈ 0.35 ÷ 50 µs = 7 kHz. Sampling at 50 to 70 kS/s captures the pulse shape well.
• An electrical edge with a 10 ns rise time: bandwidth ≈ 35 MHz, so you need a digitizer sampling at roughly 200 to 350 MS/s with at least 35 MHz of analog input bandwidth.

Sampling faster than you need is not free. Every extra sample has to be transferred, stored and processed, which is why the data-rate calculation below matters as much as the sample rate. The guide’s section on DAQ specifications covers resolution and accuracy in more depth.

The real bottleneck: data throughput

The data rate of an acquisition is simple to calculate and easy to underestimate:

Data rate = channels × sample rate per channel × bytes per sample

For example, 16 channels at 1 MS/s with 16-bit (2-byte) samples produce 32 MB/s. That is about 115 GB per hour, or close to a terabyte in an eight-hour shift. Every link in the chain has to sustain that rate continuously, not just on average:

Link in the data path	Approximate practical sustained throughput	Notes
USB 2.0	30 to 40 MB/s	Shared bus; fine for moderate channel counts
USB 3.x	300 to 400 MB/s	Host controller and cable quality matter
Gigabit Ethernet	About 100 MB/s	Good for distributed nodes; 10 GbE gives about ten times more
PCIe (x4 Gen 3) and PXI Express	Several GB/s	Highest bandwidth, with shared clocks and triggers in PXIe
SATA SSD	About 500 MB/s	Sustained write speed can drop when the drive fills
NVMe SSD or RAID	1 to several GB/s	Needed for continuous multi-channel streaming at MS/s rates

These figures are rough planning numbers, not guarantees. Always check the sustained (not peak) throughput of the specific hardware, and leave margin: a system running at 90% of its bus or disk capacity will drop samples the first time the operating system gets busy.

Hardware features that matter at high speed

Simultaneous vs. multiplexed sampling

Many multifunction DAQ devices use one ADC shared across channels through a multiplexer. The quoted sample rate is then the aggregate: a 1 MS/s multiplexed card scanning 8 channels gives only 125 kS/s per channel, and the channels are sampled one after another, not at the same instant. Fast scanning can also cause ghosting, where one channel’s voltage bleeds into the next because the input has not settled. Simultaneous-sampling hardware gives each channel its own ADC, so all channels are captured at the same moment at the full rate. Choose it whenever phase between channels matters, such as vibration from several accelerometers, three-phase power or modal testing.

ADC architecture

ADC type	Typical speed	Strengths	Trade-offs
Delta-sigma	Up to a few hundred kS/s	High resolution (24-bit), built-in anti-aliasing filtering	Filter delay; not suited to fast closed-loop control
SAR (successive approximation)	Up to about 10 MS/s	Low latency, good for multiplexing and control	Needs an external anti-aliasing filter
Pipeline and flash	Tens of MS/s to GS/s	The speed needed for pulses and RF	Lower resolution (typically 8 to 14 bits), more power and data

Bandwidth, memory and triggering

• Analog input bandwidth must exceed the signal bandwidth. A fast ADC behind a slow front end still smooths away the edges you wanted to see.
• Onboard memory and DMA let the hardware buffer data and move it to the host without CPU involvement. Deep onboard memory is what makes short bursts at very high rates possible even when the bus cannot keep up.
• Hardware triggering (edge, level, window, digital) with pre-trigger samples captures what happened before and after a rare event, instead of recording everything and searching afterwards.
• Synchronization across devices needs a shared sample clock and trigger lines (as in a PXIe chassis), or IEEE 1588 PTP and GPS timing for distributed nodes. Software timestamps are not accurate enough at these rates.
• Signal integrity becomes part of the design: coaxial cabling, correct termination (often 50 Ω for fast digitizers), short cable runs and good grounding.

High-speed DAQ system architectures

Architecture decides where the data goes and where it gets reduced. These are the patterns we use most, often combined in one system:

Architecture	How data moves	Best for	Limits
PC with a USB or Ethernet DAQ device	Device buffers samples and streams them to a PC	Bench tests, portable systems, moderate channel counts	Bus throughput; PC timing for anything closed-loop
Modular chassis (PCIe or PXI Express)	Plug-in digitizers and DAQ modules share a high-bandwidth backplane, clocks and triggers	Test stands with many synchronized channels and mixed instruments	Cost; the chassis has to sit near the test article
FPGA-based acquisition	Samples are filtered, triggered, decimated or analyzed in hardware before reaching the host	Microsecond-level control, edge processing, data rates too high to store	Development effort; needs FPGA programming expertise
Distributed synchronized nodes	Local nodes digitize near the sensors, buffer and send data over the network with shared timing	Large machines, test cells and facilities with widely spaced sensors	Synchronization design; network capacity
Standalone high-speed recorder	Self-contained instrument records to internal storage	Field testing and transient capture without a host PC	Limited integration and automation

The key architectural question is where to reduce the data. If you only need peak values, spectra, pass/fail results or the few milliseconds around a fault, computing those close to the sensor, often in an FPGA, can cut the data stream by orders of magnitude and make the rest of the system simple.

Streaming vs. triggered capture

There are two basic ways to record fast signals, and choosing between them early saves a lot of rework:

• Continuous streaming records every sample to disk. It is the right choice when you cannot predict when the interesting event will happen and need the whole record for later analysis. It is limited by sustained bus and storage throughput, and it generates large files.
• Triggered (burst) capture fills onboard memory at a very high rate and saves only the window around a trigger, with pre-trigger history. It allows much higher sample rates than the bus could sustain and keeps data volumes small.

Many systems use both: a moderate-rate continuous stream for trends plus high-rate triggered captures of unusual events.

Software for high-speed acquisition

High-speed systems fail in software more often than in hardware. The patterns that keep them reliable:

• Use hardware-timed, buffered acquisition, never software-timed loops.
• Separate acquisition from logging and display (a producer-consumer design), so a slow disk write or a busy screen never stalls the acquisition loop.
• Write binary formats such as TDMS or HDF5. Text formats like CSV cannot keep up and multiply file sizes.
• Decimate for display. A screen cannot show a million points per second, so plot a reduced or min/max version.
• Put closed-loop control on a real-time controller or FPGA, not on a desktop operating system.

For a comparison of platforms, see our article on data acquisition software options, from ready-to-run tools to LabVIEW, Python and custom applications.

Common mistakes in high-speed DAQ

• Reading the aggregate sample rate of a multiplexed card as the per-channel rate.
• Sampling with no anti-aliasing filter, or with one set far above the frequencies of interest.
• Choosing the sample rate without calculating the data rate, then discovering the disk or network cannot sustain it.
• Recording everything when a trigger, or a feature computed at the edge, would capture what matters.
• Using software timestamps to align channels from different devices.
• Relying on a Windows PC for timing-critical control.
• Treating cabling as an afterthought: unshielded or unterminated cables at MHz rates add ringing and noise that no software can remove.

High-speed DAQ systems Sciotex has built

• Production test with high-speed digitizers: a production test system that inspects cable end-connection reflections using NI high-speed digitizers and pulse sources.
• Glove box tester: an automotive test system that cycles glove boxes, monitors component forces and logs unusual events at high speed.
• FPGA-based systems including a ring laser gyro test station, high-speed laser triggering and galvo mirror control for microscopes, and a fly wingbeat analyzer.

More projects are on our data acquisition examples page.

Frequently asked questions

Related articles

• What Is Data Acquisition (DAQ)? The Complete Guide
• Data Acquisition Software: Ready-to-Run, LabVIEW, Python or Custom?
• How to Choose a Data Acquisition System: A DAQ Requirements Checklist
• Signal Conditioning: What It Does and What Each Sensor Needs
• Sampling Rate, Nyquist and Anti-Aliasing Filters Explained