Summer is here. So is openDAQ 3.20.

Dušan Kalanj

7/16/2025

We like to imagine you reading this on a beach somewhere—just the way technical newsletters should be read. Meanwhile, the openDAQ team hasn’t been resting. We’ve been hard at work delivering new features, performance improvements, and expanded device support in the latest 3.20 release. See the main additions below.

Operation Modes

openDAQ now supports operation modes. This feature lets devices express different modes of operation and gives you control over what state a device  is in.

How it works:
Three different operation modes with the following behavior are defined:

  • Idle - the component can be configured, but cannot process data.

  • Safe Operation - the component can be configured and process data, but does not output data to the physical world: analog outputs are disabled, data is not recorded in files.

  • Operation - the component can be configured, process data and output/write data to physical sinks.

Modes can be applied to a single device component, or recursively across its entire tree. The operation modes are an opt-in feature. By default, all devices support the “Operation” mode, while the “Idle” and “Safe Operation” ones need to be added explicitly by device vendors

Data Transfer Performance Optimizations

We’ve made significant optimizations to data packet creation and transfer, as well as to the native streaming protocol server. These improvements deliver up to a 50% reduction in CPU load on standard DAQ devices using openDAQ’s native streaming.

Improvements were achieved through critical-path optimizations in packet handling and socket scheduling. No device-side changes are required beyond updating your openDAQ version to benefit from these improvements.

Network Configuration via mDNS

You can now modify the network configuration of openDAQ devices directly via the mDNS protocol.

How it works:
Discovered devices can expose their network interfaces (e.g., eth0, eth1) via a standardized API. Each such interface allows querying and updating IP configuration such as gateway address, DHCP mode, and static address combined with subnet mask.

The implementation follows the DNS-SD standard and advertises IP configuration capability via the _opendaq-ip-modification._udp.local mDNS service.

Note that this feature is opt-in and requires vendors to adopt it on their devices.

Example (C++):

auto interface = deviceInfo.getNetworkInterface("eth0");
auto config = interface.requestCurrentConfiguration();
config.setPropertyValue("address4", "192.168.56.155/24");
interface.submitConfiguration(config);

Connection Status Monitoring

openDAQ now enables enhanced monitoring of device connections by providing insight into both configuration and streaming statuses.

How it works:
Each device exposes a ConnectionStatusContainer that provides access to:

  • The configuration status

  • Streaming-specific statuses

Inspecting these statuses allows you to check whether a connection is functional (“Connected” state), is recovering (“Reconnecting”), or has failed (“Unrecoverable”).

To track connection status changes, a  new core event type is available - ConnectionStatusChanged.

Example (C++):

auto status = device.getConnectionStatusContainer().getStatus("StreamingStatus_OpenDAQNativeStreaming_1");
std::cout << "Streaming connection status: " << status.getValue() << "\n";

CSV Recorder

We’re introducing the Recorder concept to openDAQ. 

How it works:
Function blocks that record data are unified under a new IRecorder interface, which enables users to start and stop data recording. Any future recorder will share this common interface, supporting our goal of standardized DAQ system configuration.

The feature comes with an example function block - the CSV Recorder, which, as the name suggests, allows users to store signal data into CSV files.

Other Notable Features

  • List of connected clients: Devices now expose detailed information about connected clients, including address, host name, protocol, and client type, retrievable via DeviceInfo.

  • Configurable Device Info Fields: Device info fields can now be modified. Each device has control over what fields are read-only, and which are configurable. The changes are kept in sync with the openDAQ mDNS discovery service, allowing up-to-date broadcasting of the device information.

  • Python 3.13 and macOS support: openDAQ Python bindings are now available on PyPI for Python 3.13 on all platforms, with new wheels also added for macOS on both Intel and ARM processors.

  • Standardized Component Statuses: Component statuses now come with a set of default predefined statuses (OK, Warning, Error). Each status can now be accompanied by a message, giving you information on how to resolve it.

  • Named Threads: The threads spawned by the openDAQ Scheduler, Logger, and Discovery systems are now named for easier debugging.

  • Experimental LT Streaming Server: A new high-performance implementation of the LT streaming server is now in testing. The new server will replace the old LT implementation in a future release.

  • C++20 and C++23 compatibility: Resolved compatibility issues with modern C++ standards to ensure clean builds across GCC, Clang, and MSVC.

Release Notes

This release also includes many quality-of-life improvements, bug fixes, and minor features. Full changelog is available at: github.com/openDAQ/openDAQ/releases/tag/v3.20.0.

Update to 3.20 and try the new features!

We’re excited to see what you build with the latest release. As always, we love hearing your feedback—write to info@opendaq.com to let us know what you think, and what you’d like to see next.