How to take control of your test rig data: a hands-on walkthrough with Quix
Industrial R&D has a recurring problem: before anyone can visualise test data, they have to do "data archaeology" to find it, clean it and give it context. Comparing experiments to find the best result needs data that's reliable and accessible — hard when test information is fragmented and scattered.
The physical demonstration
Quix built a drone-inspired propulsion test rig — an electric ducted fan, a load cell for thrust, and a set of sensors streaming live data — and debuted it at the Aerospace Test & Development Show 2025 in Toulouse. The scenario: developing an autonomous delivery drone where engineers have to evaluate lightweight battery options. The question to answer is whether a lighter Battery B can deliver the high current required without critical voltage drops, and how voltage stability affects motor consistency during high-power manoeuvres.
Step 1 — configuring and setting the test
Test engineers usually configure a lot of metadata — campaign details, sensor mappings, measurement points — but that setup data ends up disconnected from the measurements coming off the rig. Storing the configuration centrally is what lets you correlate it with outcomes later.
In this demo the engineer starts a test in LabVIEW and enters the campaign ID, test ID, asset configuration and test parameters (throttle percentage, duration). On start, LabVIEW sends that metadata as structured JSON to the Quix API at the same moment it issues the motor commands.
That payload arrives at the Dynamic Configuration Manager (DCM), which acts as the registrar: it versions and stores the metadata, then publishes a lightweight notification — just the configuration ID and a retrieval URL — to an internal config-update topic. That lets the web-based Test Manager show the run as "In Progress" immediately. One action versions, stores and catalogs the entire test context centrally.
Step 2 — processing the test data
With the test running, the system captures and processes time-series data in real time — thrust, current draw, battery voltage and vibration. The microcontroller samples at 100 Hz and posts raw streams to the Quix API tagged only with the Test ID. The device only needs that one key; it doesn't need to know the rich configuration, which keeps it decoupled.
A data-normalization service does the first pass of cleanup — un-batching incoming data, flattening schemas and converting timestamps from relative offsets to absolute time. Every node in the pipeline is a customisable Python program (all in the accompanying GitHub repo); real customer deployments often run MATLAB nodes for live modelling or several downsampling nodes to store data at different resolutions.
The normalized data then passes to a Config Enricher, which uses the Test ID to do fast lookups against cached configurations and merge the context into the stream. Raw data that arrived as test_id, timestamp, raw_thrust_value comes out enriched with battery: "premium_supplier_A" and motor: "standard_v2" — removing the usual manual, after-the-fact step where engineers export logs and hunt for config files to correlate.
Step 3 — analysing the test data
In-depth analysis usually happens after the test, though real-time visualisation is available throughout. The demo writes enriched data into a Lakehouse built into the platform — massive volumes of raw data on cheap object storage like Amazon S3 or MinIO, but with warehouse features like indexing, metadata and versioning, so there's no need to repackage the data for each use case.
A Marimo notebook connects to the Lakehouse so engineers can visualise and compare runs, and non-technical stakeholders can change dropdown values to generate their own reports. The comparison shows the new configuration in test t006 delivering an 11% thrust improvement over t002 — but at 45% more power, and so a significantly shorter flight time. The Test Manager also lets you select multiple runs and compare measurements directly.
Centralising data for digital transformation
R&D speed comes down to how fast a team can get a clear answer out of its test data. The goal is to automate the low-value wrangling — finding files, fixing timestamps, correlating results — so domain experts spend their time on high-value analysis and confident design decisions.
Plenty of organisations try to build this in-house, but a centralised data platform takes serious, sustained investment in data and platform engineering — effort pulled away from the actual product. A specialised platform like Quix provides the resilient, scalable infrastructure while still letting engineers write their processing logic in familiar languages like Python. The real choice is whether to spend engineering resources building data infrastructure, or to use external expertise and spend them building a better product.