Arduino GIGA R1 Streaming LT: Eight Channels, DewesoftM and a Reproducible Acquisition Path

Arduino GIGA R1Streaming LTturned eight timed acquisition channels into anopenDAQ-compatible source. The case study documents DewesoftM interoperability, hardware observations, reconnect behavior and the engineering boundaries that make these results reproducible.

Could a classroom-friendly board become a real DAQ endpoint?

It is easy to read an analog pin and draw a graph. It is much harder to make eight signals appear as a coherent, discoverable acquisition device that independent clients can connect to, disconnect from and reconnect to without quietly changing the meaning of the samples. This was the challenge behind theArduino GIGA R1 Streaming LTexperiment. Instead of forwarding sensor readings through a bespoke script, we built a direct openDAQ Streaming LT producer and tested it with the official openDAQ client and DewesoftM.

The project belongs to the student-led FermiLabs laboratory, whereArduinohardware andDewesoftmeasurement technology have supported experiments inroboticsand acquisition. Following our original IOLITE/EtherCATgateway work, we wanted to see how far a capable microcontroller could go as a self-containedDAQsource. That meant taking the less glamorous engineering questions—buffer sizes, reconnects, timestamps and firmware version identity—as seriously as the waveform displayed on a screen.

Why Arduino GIGA R1 Streaming LT was the right experiment

According toArduino’s official GIGA R1 WiFi documentation, the board uses an STM32H747XI dual-core microcontroller with extensive I/O, advanced ADC/DAC capabilities and connectivity options. That combination made the GIGA interesting for a laboratory firmware experiment: enough processing and peripherals to explore timed analog scans while still using a familiar development platform. Our implementation exercised eight analog inputs; it did not claim that those readings were simultaneous, laboratory-calibrated conversions.

The challenge was to match that physical producer withopenDAQ Streaming LT, so that the board could identify itself, describe channels and serve values in a format supported by other software. DewesoftM then became an important external client in the accepted July tests. This is an instructive partner story: Arduino provided the programmable acquisition platform, openDAQ supplied the streaming contract, and Dewesoft’s software gave us an additional real-world interoperability check.

A small failure that explains a big engineering lesson

One of the most useful moments was a connection that appeared to fail even though the producer still had samples. A non-blocking network write can temporarily make no progress when Wi-Fi is congested. The early firmware interpreted this as a dead client too quickly. Adjusting bounded write deadlines and preserving enough buffered acquisition separated a temporary transport stall from genuine loss of captured data. The important result was not “Wi-Fi became real-time”; it was that our system could report failures clearly and continue the admitted workload.

Case study · documented start:the GIGA work was underway by 12 July 2026, with physical V02 evidence dated 14 July and V03 acceptance dated 15 July. Its exact initial prototype date is not established by the retained summary.Current scope:historic GIGA LT board acceptance, not a blanket claim about newer UNO Q/Linux Native releases.

FermiLabs context:this laboratory connects Arduino embedded platforms with Dewesoft measurement workflows. openDAQ serves as an interoperability and signal-model layer where the specific integration is qualified. The wordssource-tested,host-qualified,board-measuredandreference-dataidentify different levels of evidence, not interchangeable claims.

The next step after IOLITE/EtherCAT

The IOLITE/EtherCAT gateway demonstrated why a common device and signal model matters. We then investigated a different question: could an accessible Arduino board publish its own real acquisition channels directly to openDAQ clients, with no Linux gateway or EtherCAT in the data path? Arduino GIGA R1 WiFi became that direct acquisition endpoint.

Implementation and architecture

The GIGA firmware implements the required openDAQ Streaming LT discovery and WebSocket subset on ArduinoCore-mbed. A timer/DMA producer scans analog inputs A0–A7, then publishes eight Float64 channel values with a declared common Time domain. The firmware also provides mDNS discovery using_streaming-lt._tcp.local, client subscriptions, bounded buffering and disconnect handling. The historical V02 managed server provides persistent configuration and two independent client slots; V03 adds bounded rules, events and laboratory management.

The acquisition channel timing is tied to the GIGA producer. The Wi-Fi transmission path is not hard real-time. In particular, an acquisition scan is not equivalent to eight simultaneous sample-and-hold conversions, and a monotonic local domain is not evidence of an externally synchronized UTC clock.

Project history and updates

Physical results worth reproducing

• Official openDAQ 3.40.0 client, V02:450,039 aligned samples per channel on A0–A3 across approximately 900 seconds, at 499.999999 Hz, with zero estimated domain gaps, duplicates or regressions in that bounded test.
• DewesoftM 26.2.6 on macOS, V02:all eight channels enumerated; A2 rendered continuously for about 15 minutes 35 seconds after the transport correction, and three disconnect/reconnect cycles completed without resetting the board.
• V03 at 100 Hz:the official Python client measured 991 samples per A0–A7 channel in each of two bounded remove/re-add cycles, with aligned domains and zero counted gaps, duplicates or regressions.
• Two-client operation:in the V03 test DewesoftM rendered A0 while the official Python client read A0/A1 on a second slot. This is specific to the accepted images and scenarios.

The critical debugging lesson

The first V02 WebSocket implementation treated a non-blocking socket write that remained temporarily unavailable for more than one second as a dead client. Weak Wi-Fi conditions produced valid pauses longer than that. The revised firmware allowed a five-second write deadline, retained roughly 6.144 seconds of acquisition in a DMA buffer and failed explicitly on DMA discontinuities. The change did not make the radio deterministic: it made acquisition loss observable rather than hidden.

Boundaries and publication notes

• The tests establish a particular GIGA firmware, hardware board and client configuration, not general 2 kHz long-soak or arbitrary network conditions.
• The V03 educational control plane was explicitly unauthenticated on the laboratory LAN. It must not be described as suitable for an untrusted network.
• The last V03 UI/hold image did not inherit a fresh DewesoftM test merely because an earlier V03 data-plane image passed.
• Actual oscilloscope screenshots and the existing DewesoftM visual evidence should be selected only from the original sanitized test capture, not regenerated illustrations.

Where to inspect the original tests

Build details and hardware qualification records remain internal. Public technical resources:openDAQ — official upstream SDKandArduino documentation. Source and raw device captures are not publicly downloadable from this site.

ExploreArduino OpenDAQ,Measurement & DAQ, and theArduino Measurement & openDAQ learning path. FermiLabs case studies are independent engineering reports, not official openDAQ/Arduino/Dewesoft product certifications.

Partners, technologies and further reading

This case study belongs to FermiLabs’ Arduino and Dewesoft engineering programme, withopenDAQas the open measurement interoperability layer. Consult the officialArduinoandDewesoftwebsites for manufacturer documentation. The measurements reported here are FermiLabs’ scoped laboratory tests and should not be read as manufacturer certification.

Related FermiLabs material:UNO Q and GIGA measurement-path update,Arduino EFBus project, andEFBus10 MCU–Linux transport update. Case-study cross-links will be activated as individual posts are published.

The student experiment: rate, latency and continuity

Students can recreate the thinking without expensive instruments. Imagine a source producing 500 samples per second while the network temporarily stops accepting output. What is the difference between a sample rate, a publication rate and a client receive rate? How many samples need buffering to survive a pause? What should the software do when the buffer fills? A robust answer reports gaps rather than drawing a deceptively continuous graph.

In the accepted V02 laboratory run the official client observed 450,039 aligned samples per channel for A0–A3 in roughly 900 seconds, near 500 Hz, with no counted timestamp-domain gaps in that test. DewesoftM 26.2.6 separately enumerated eight channels, displayed one selected channel for more than 15 minutes and completed bounded reconnect exercises. Those results belong to the tested firmware, board and conditions; they are not a universal guarantee for every radio network.

Why this matters to Arduino, Dewesoft and openDAQ

For Arduino users, the project illustrates a pathway from analog I/O experiments to a device that other software can discover and inspect. For Dewesoft users, it demonstrates an educational client-compatibility scenario involving hardware outside a traditional turnkey instrument. For openDAQ contributors, it offers focused evidence about Streaming LT and descriptor/domain behavior on constrained hardware. None of the three benefits requires claiming an official certification that has not been issued.

Partner-ready case study summary

FermiLabs used the Arduino GIGA R1 WiFi to explore a challenging step beyond an analog-read tutorial: turning eight on-board channels into an openDAQ Streaming LT device. The firmware combined a timed analog producer, buffering, self-description, connection management and a bounded client protocol. July 2026 hardware tests with the official openDAQ client and DewesoftM 26.2.6 demonstrated aligned domains, channel enumeration, extended selected-channel visualization and controlled reconnect behavior. The engineering team also diagnosed a Wi-Fi backpressure condition that had caused premature disconnects. The result is a reproducible educational integration case, not a claim of calibrated industrial acquisition or guaranteed wireless determinism. It demonstrates how Arduino’s programmable hardware, openDAQ’s interoperable signal model and Dewesoft software can support real engineering learning. The bounded measurements are useful teaching examples precisely because each test environment is identified.

Help us take the next step

Useful collaboration would include review of LT firmware interoperability, access to controlled signal sources, physical calibration procedures, and additional client or network test scenarios. We especially welcome educational examples that let students reproduce both a successful acquisition and a detectable failure. Explore the officialArduino use casesfor other practical engineering applications and ourArduino OpenDAQ programmefor ongoing experiments.