DAQ file size calculator

How the file size is calculated

A DAQ recording stores one value per channel per tick of the sample clock:

values    = channels * sample rate * duration
file size = values * bytes per value
data rate = channels * sample rate * bytes per value

Binary formats store each value in a fixed width (2 bytes for a 16-bit integer, 4 for a 32-bit float, 8 for a 64-bit double). A 24-bit converter’s output normally sits in a 4-byte word unless the format packs it into 3 bytes. CSV stores each value as text, so its size depends on how many digits you print. The calculator estimates a CSV value as the digits you choose, a decimal point and a minus sign on about half the values, then adds the delimiters, the timestamp column and the line ending for each row. Sizes use decimal units, so 1 GB is 1,000,000,000 bytes.

Worked example: 16 channels at 50 kS/s for two hours

Sixteen channels at 50 kS/s each is 800,000 values per second, or 5.76 billion values over 7,200 seconds.

Each CSV row in that example holds a 10-character timestamp (four integer digits to reach 7,200 s, a decimal point and five decimals to resolve the 20 µs sample period), 16 values of about 8.5 characters, 16 commas and a newline. That comes to 163 bytes per row, about 10.2 bytes per value, so the CSV ends up larger than the float64 file and much slower to load. The guide to test data file formats compares CSV, TDMS, HDF5, Parquet and MAT for long recordings.

Compression and real file sizes

HDF5 and Parquet compress per dataset or column, and MATLAB compresses v7 and v7.3 MAT-files by default. The savings depend on the signal. Noisy analog channels from a 16-bit converter have little redundancy in their low bits and shrink only modestly, while thermocouples, digital lines and values pinned at a rail compress far better. Plan storage around the uncompressed numbers and treat compression as margin.

File headers, channel names and scaling metadata add kilobytes to gigabytes of data, so container overhead only shows up in very short runs with hundreds of channels.

Common mistakes when sizing a recording

• Entering the device’s aggregate rate as the per-channel rate. A multiplexed device rated at 100 kS/s total gives 8 channels 12.5 kS/s each, and this calculator takes the per-channel rate.
• Comparing GB with GiB. Windows File Explorer divides by 1,073,741,824 and still labels the result GB, so the same file looks about 7% smaller there than in this calculator or in macOS Finder.
• Planning to open a long CSV in Excel. One hour at 1 kS/s is 3.6 million rows, and an Excel sheet stops at 1,048,576.
• Recording to FAT32 media. FAT32 caps one file at 4 GiB minus one byte, so a long run to an SD card or an older USB stick can fail partway through.
• Forgetting the timestamp. With one channel, an ISO 8601 timestamp with microseconds is 26 characters, about three times the value it labels.

Recording and exporting in DAQAtlas

DAQAtlas, which is in development, records to its own .edaq format (a JSON header followed by raw samples, readable even after a crash) and exports to CSV, MATLAB .mat, TDMS, Parquet and HDF5. An export can cover the whole run, the visible range or the span between cursors, with optional decimation to shrink a file you only need for a report. To check a file you already have, open it in the data file viewer, which reads TDMS, HDF5, Parquet, MAT and CSV.