Native vs LT Streaming in openDAQ: Why Reference-Domain Semantics Matter
Native versusLT streaminginopenDAQis not just a comparison of throughput. This engineering study looks at signal identity,ReferenceDomainInfo, source timebases and the information preserved by each transport so that a plotted value is not confused with a scientifically qualified measurement.
Quick access
Streaming andDAQworkflows require a compatible acquisition environment.
Native versus LT streaming: one deceptively simple question
Two plots can look identical even when one has lost information that makes its readings scientifically meaningful. In the FermiLabs laboratory this led to a deceptively simple question: when an openDAQ device sends its values through Native or LT streaming, what does the receiving application actually know about the source clock? OurNative vs LT Streamingcomparison is not a contest to declare one product the winner. It is a case study in choosing transport capabilities based on the information the experiment cannot afford to lose.
Students are familiar with values and units: a temperature may be shown as 21 °C, for instance. Professional measurement systems also need to know *when* each value was observed and which clock that time belongs to. In distributed acquisition, two instruments may use different counters and clock origins. A chart that puts them on the same horizontal axis without justification might communicate a false relationship. This matters even if the packet delivery itself is perfect.
The journey from Arduino Streaming LT to Native
OurArduino GIGA R1experiment used Streaming LT because a compact embedded producer benefits from a lightweight interface supported by independent clients, including the bounded DewesoftM test. LaterLinux ARM64and UNO Q work used Native where the downstream application needed the specificReferenceDomainInfofields associated with signal domains. openDAQ’s self-describing model made it possible to pose this precise question: what survived the transport boundary? The answer came from a repeatable codec and client check rather than a preference for a fashionable protocol.
The tested LT Modern 4.0.3 round trip preserved certain basic metadata but did not preserve the required reference-domain identity. The resulting FermiLabs policy classified that path asREDUCED_ONLYfor applications requiring this field. It does not mean LT necessarily loses numeric samples, and it certainly does not mean Native automatically synchronizes clocks. It means an application must not silently replace missing producer truth with a convenient guess.
Why openDAQ and Dewesoft users should care
For an openDAQ developer, this is a concrete example of the difference between API compatibility and semantic compatibility. For aDewesoft-oriented engineer, it reinforces the discipline of understanding time bases and metadata before comparing measurement channels. For anArduinoexperimenter, it offers a way to choose the smaller protocol when it is appropriate and a stricter one when the scientific workflow requires it. The most useful technical decision is often a qualified boundary, not an unqualified “always use X.”
Case study · documented progression:GIGA direct Streaming LT has physical acceptance in July 2026; current transport-policy evidence is documented under the openDAQ 3.40.3 host qualification of 10 September 2026. The result is a scoped comparison, not a declaration that LT is unusable.
A transport can deliver values but change their meaning
The FermiLabs project began with anEtherCAT/IOLITE acquisition path, then added direct Arduino GIGA Streaming LT and a Native-capable UNO Q/Linux gateway. Those developments exposed a question more important than raw throughput: when the same quantity crosses a different transport, which parts of its scientific identity are preserved? A synchronized-looking chart can mislead if the receiving application silently substitutes local arrival time for the producer’s reference clock.
Two useful paths, different guarantees
For an Arduino GIGA R1 with a constrained embedded firmware stack, LT is a compact, practical way to expose channels and a time domain to openDAQ clients. For applications whereReferenceDomainInfois itself authoritative measurement context, FermiLabs adopted a fail-closed Native policy on the qualified host path.
| Question | Native path | LT path (admitted scope) |
|---|---|---|
| Numeric signal values | Available through admitted Native reader | Available in the admitted LT scope |
| Basic time-domain descriptors | Retained and checked against stream/configuration identity | Basic fields retained by the bounded codec round trip |
| ReferenceDomainInfo identity | Required and preserved in the strict Native policy | Not preserved in the tested LT 4.0.3 codec round trip |
| Scientific cross-device synchronization | Only claim it when actual clock mapping and uncertainty are evidenced | Cannot be inferred from LT signal values or host receive time alone |
| Hardware readiness | Depends on independently verified producer and device | Depends on independently verified producer and device |
Implementation of the strict Native policy
- Open a qualified configuration endpoint using the
daq.nd://scheme. - Explicitly require
OpenDAQNativeStreamingfor configuration and streaming, rather than falling back to LT. - Require nonempty
ReferenceDomainInfo.referenceDomainIdwhen the application depends on that fact. - Confirm that configuration and live streaming descriptors agree, and re-admit on changed clock/domain/descriptor epochs.
- Verify strictly increasing per-channel domain ticks. Leave clock origin, calibration and uncertainty UNKNOWN unless source evidence proves them.
Timeline and updates
| When | Milestone and boundary |
|---|---|
| 12–15 July 2026 | The Arduino GIGA R1 LT path is physically tested and accepted for bounded direct client scenarios including DewesoftM 26.2.6. |
| August 2026 | UNO Q V06/V07 provide a Native-oriented measurement topology and the multi-source project formalizes distinct source domains. |
| 7–10 September 2026 | The Native reference-domain host policy and openDAQ 3.40.3 dependency gate are independently qualified. |
| 10 September 2026 | The retained LT Modern 4.0.3 codec gate establishes a specific loss of ReferenceDomainInfo at the transport boundary. |
| November 2026 | Downstream Browser Kit, MQTT, replay and FRC comparison stories must continue to preserve this Native-versus-reduced distinction. |
What was actually tested
The accepted codec check shows that LT Modern 4.0.3 retains basic domain fields while losing the ownerReferenceDomainInfo. For this application that is a demonstrated reduction of transported time-reference semantics. It is not evidence that every LT client drops samples, that every LT deployment lacks timing, or that Native magically synchronizes two unrelated clocks.
A separate manifest or measurement-bundle sidecar may record the missing provenance truth, but it does not change what the LT packet itself carried. The proper approach is to make provenance visible and fail closed where source-clock reference identity is a requirement.
Result, limitations and reusable lesson
The engineering decision is intentionally narrow:Native when reference-domain truth is mandatory; LT for qualified reduced-capability scenarios.Neither protocol substitutes for explicit hardware/clock calibration. This distinction guides future GIGA, UNO Q, EFBus, Browser and scientific measurement consumers.
Technical qualification records remain internal. Public references:Arduino OpenDAQ,Measurement & DAQ, and the officialopenDAQwebsite. Add real descriptor and trace screenshots only after they have been reviewed for publication; current diagrams are illustrative.
Partners, technologies and further reading
This FermiLabs engineering case study is part of our work withArduinoandDewesoft, using theopenDAQdevice-and-signal framework where documented. Check each provider’s official resources for current product information. These scoped experiments do not imply manufacturer certification of the described integration.
Related FermiLabs reading:Arduino GIGA R1 and UNO Q paths;Arduino OpenDAQ project;EFBus project;Arduino measurement course. Links to the other new case studies will be enabled individually as their articles become public, rather than linking to inaccessible drafts.
Try this thought experiment in class
Suppose one sensor reports 1000 samples, each indexed from 0 to 999, while another reports the same number of samples. If both use the same nominal rate, are they synchronized? Not necessarily. Ask students to annotate sample index, local tick period, source epoch, reference clock and uncertainty on both streams. Then remove the reference-domain identifier from one. Which cross-device comparisons are still defensible? That is the practical motivation behind the Native/LT gate and the reason metadata deserves as much attention as the waveforms.
Partner-ready case study summary
FermiLabs investigated openDAQ Native and LT streaming while developing Arduino GIGA R1 and Linux/UNO Q measurement paths. The central question was whether transport preserved the metadata required to interpret time-dependent signals, not which protocol could draw the fastest chart. An accepted September 2026 LT Modern 4.0.3 codec check retained basic fields but did not preserve the required ReferenceDomainInfo identity. FermiLabs therefore designated that scope REDUCED_ONLY when reference-domain truth is needed, while using a stricter Native path for the relevant consumers. This does not imply that LT drops all values or that Native establishes physical clock synchronization by itself. The result offers a practical lesson for students and a useful integration decision record for Arduino, openDAQ and Dewesoft users concerned with reproducible measurement.
How partners can move the conversation forward
Useful follow-ups include verified descriptor examples, independent protocol conformance checks, clock-uncertainty exercises and end-to-end comparisons using two real sources. We welcome review of the transport policy, rather than assuming any vendor has endorsed our interpretation. ConsultopenDAQfor the framework,Arduinofor hardware context andDewesoftfor professional measurement references.
