From openDAQ Recording to FRC Studio: A Provenance-Aware Scientific Reference Workflow

openDAQrecordingis the traceability boundary between a generated reference signal andFRC Studio’s comparison workflow. This case study describes Native SDK recording, SHA-verified exports, explicit signal mapping and the limitations of synthetic reference experiments.

A scientific comparison is only as good as the history of its data

When students see two similar scientific plots, it is tempting to say the experiment agrees with the model. But where did the values come from? Were they recorded from a calibrated instrument, generated by software or replayed from an earlier dataset? Could a timestamp have changed during export? TheopenDAQ Recording to FRC Studiocase study addresses these questions using a controlled reference-data workflow, before making any claims about physical plasma experiments.

FRC Studio is part of FermiLabs’ broader interest in modeling field-reversed-configuration (FRC) plasma systems. It combines numerical and scientific-computing workflows with ways to inspect reference information. The team is also developingArduinoand openDAQ measurement pathways, informed by the professional acquisition practices supported byDewesoft. The research challenge is ambitious, but this particular integration milestone deliberately stays modest: show that a known software signal can be captured, exported and compared without losing its identity.

What openDAQ recording contributed to FRC Studio

openDAQ offers a self-describing signal model and Native SDK readers. In the admitted September 2026 reference test, two deterministic software signals were recorded through real SDK/Native reading operations. Their channel identities, domains, counts and file hashes were preserved for FRC Studio’s existing reference importer and comparison workflow. A check against an independent analytical oracle then tested the path. This is important because it validates software data handling without depending on an unqualified physical sensor or instrument.

Dewesoft’s acquisition tools offer a useful model of the professional discipline needed when real measurements arrive: the instrument configuration, units, sampling and reference clocks must be documented. Arduino provides an approachable route for later small-device experiments. But neither brand is claimed as the source of the two synthetic SDK signals in this test; their role is the technological context for a future instrument-to-science workflow. The actual demonstrated bridge is between openDAQ reference recording and FRC Studio’s software import/comparison.

The subtle trap of a perfect score

The accepted reference comparison can report zero difference when two deterministic software datasets match exactly. That is satisfying as a regression check, yet it says nothing about the accuracy of a future field probe or the behavior of a fusion plasma. The team therefore preserved the original recording bytes, SHA-256 identities, mapping statements and UNKNOWN calibration/clock relationships. Distinguishing a software oracle result from physical validation is the central scientific lesson of this project.

The next technical stage remains separately gated: a current openDAQ 3.40.3 producer and the full MeasurementBundle integration with an exact current FRC consumer. A historical accepted 3.40.0 reference test cannot be relabelled as this later validation. Stating that limit makes a case study more useful to researchers and software vendors than pretending the whole experiment is complete.

Case study · documented start:FRC Studio’s published Alpha/geometry-simulation baseline existed by 22 August 2026. The openDAQ-to-FRC reference-software integration is documented from 7 September 2026. A later dedicated openDAQ 3.40.3 producer/MeasurementBundle integration remains a separate unfinished scope.

Scientific data needs more than a readable CSV

FRC Studio studies field-reversed-configuration engineering questions through numerical geometry, meshing, electromagnetic simulation and comparison. Its measurement workflow must know not merely which numbers arrived but what they mean, where they came from and whether they correspond to a physical instrument. The Arduino/openDAQ laboratory offered a practical test source: capture two known synthetic signals through a real openDAQ Native SDK route, then import the recorded artifact into an existing scientific comparison tool.

Why a reference-software test was appropriate

Physical calibration, source clock alignment and arbitrary real sensor interoperability require additional equipment and qualified procedures. Before those gates, a deterministic software producer can test importer integrity and the semantics of data lineage. A reference test cannot prove physical sensor performance, but it can prove that a recording is not silently altered, mislabelled or misaligned during software handoff.

Verified pipeline

• Generate two known SDK signals, A0 and A1, with explicit virtual signal IDs, count units and deterministic sample/tick relationships.
• Read each through real Native StreamReaders, verifying stable signal-domain association and increasing ticks.
• Record original data and descriptors; compute SHA-256 and preserve original immutable bytes.
• Export the authorized three-file FRC reference artifact with original membership/manifest checks, no hidden interpolation or resampling.
• Import through FRC Studio’s existing reference-data importer; map virtual probes explicitly into the diagnostic design.
• Compare against an independent analytical reference and render the Scientific Report/Notebook with calibration and cross-record clock facts still marked UNKNOWN.

Project milestones and updates

Results of the bounded software test

The September reference example used two separate executable invocations that each generated a 256-sample deterministic A0/A1 dataset. The two recordings shared identical expected sample bytes but retained distinct recording identities and observed capture timing. The FRC reference importer consumed the records, compared them against an analytical oracle and produced zero count bias/RMSE/max difference for that known test. Original payload SHA-256 values were preserved.

That zero-difference comparison is not a finding that an FRC plasma instrument is accurate. It is a correctness check of a deterministic software pipeline. In particular, the synthetic producer declared an SDK reference-domain offset that was applied by the SDK, not secretly by the exporter. Physical calibration and cross-record clock relation remained UNKNOWN, and the virtual reference design explicitly selected the appropriate reference-only comparison boundary.

Limits and future completion

• No physical FRC plasma, coil, camera or calibratedDAQmeasurement was produced by this test.
• Reference-software success does not validate a physical MeasurementBundle, independent clocks, electrical calibration or synchronized multiple devices.
• The historical 3.40.0 SDK test is not silently relabelled as a 3.40.3 current-source acceptance.
• The later producer and real current public FRC import/map/report round trip must be accepted on the exact candidate to extend the claim.

Where to learn more

Public background:Arduino OpenDAQandMeasurement & DAQ. Detailed source, qualification receipts and pending engineering work remain internal and are not linked from this site. See theofficial openDAQ projectfor public SDK information.

Visual follow-up:the best eventual figure is a real (sanitized) FRC Studio importer/comparison screen next to a SHA-bound openDAQ recording receipt. Until those assets exist, an architecture diagram must be captioned “illustrative data path — synthetic reference source”.

Partners, technologies and further reading

FermiLabs develops instrumentation and learning workflows withArduinoandDewesoftas technology partners, whileopenDAQprovides a common measurement and signal model where qualified. The architecture in this article is a scoped FermiLabs engineering report, not certification or endorsement of an unqualified integration.

Related FermiLabs material:Arduino OpenDAQ project;Measurement and DAQ hub;SpeedCircuits 0.5 and openDAQ update;Arduino measurement course. Cross-links to other unpublished case studies remain on hold until those articles are individually approved and public.

An exercise for students: prove your dataset has not changed

A student can generate two small, known arrays, save their manifest and hash, load them through an importer and compare every sample to an analytical reference. Next, change one sample deliberately. Does the verification detect the alteration? Then remove the source clock identity and ask whether a cross-record time alignment is still justified. This teaches repeatable computation and data provenance, the hidden foundation beneath more glamorous scientific visualizations.

Partner-ready case study summary

FermiLabs connected an openDAQ Native synthetic recording workflow to the FRC Studio scientific reference importer, mapping and comparison software. In the September 2026 accepted software test, two deterministic SDK signals were captured with stable identities, preserved original artifact hashes and compared with an independent analytical oracle. The bounded result demonstrated software pipeline correctness for reference data; it did not validate an FRC plasma experiment, physical sensor, calibration or synchronized multiple instruments. The work illustrates how an open, self-describing measurement model can supportscientific computingwithout losing track of evidence class. Arduino and Dewesoft technologies remain part of the wider measurement development roadmap, not asserted producers of the synthetic test records. The next step is a separate current-source openDAQ 3.40.3 MeasurementBundle integration and future independently verified physical acquisition.

A research collaboration invitation

Technical partners can help review exporter contracts, clock and calibration uncertainty, metadata interoperability and responsible ways to compare simulations with measured data. We especially welcome reproducible reference datasets and research-level critiques of assumptions. Explore theMeasurement & DAQ huband the officialopenDAQ SDKfor background. The most valuable support is a better experiment, not a premature claim.