From Dewesoft IOLITE EtherCAT to Arduino openDAQ: Where the Measurement Lab Began

DewesoftIOLITEEtherCATwas the starting point for the FermiLabsArduinomeasurement laboratory. This case study follows the original gateway question, how device data could move into an Arduino/Linux workflow, and which lateropenDAQintegrations were independently qualified.

A professional sensor, an Arduino ambition, and a question worth asking

Imagine holding a sophisticated vibration sensor and wondering whether the data it produces can become part of a low-cost, student-built laboratory. That was the human question behind FermiLabs’ originalDewesoft IOLITE EtherCATexploration. We wanted more than a screen full of numbers: the goal was a bridge from professional acquisition hardware to an understandable Arduino/Linux project, with enough information preserved for other software to use the signals responsibly. One instrument became the beginning of a much wider engineering journey.

FermiLabs is an independent, student-driven Maker and Student Research and Development initiative. It began in 2022 as CARE4Space and adopted the FermiLabs identity in 2024. Our projects connect hands-on experimentation withrobotics, electronics, numerical science and measurement. The mission is deliberately ambitious but accessible: students should be able to confront real integration problems, not just follow a prepared tutorial. Technologies developed byDewesoft,Arduinoand theopenDAQcommunity made this particular challenge worth attempting.

Dewesoft IOLITE EtherCAT: why the challenge was real

IOLITE 3xMEMScombines a triaxial MEMS accelerometer, analog-to-digital conversion and an EtherCAT interface in an integrated sensor. The sensor and professional measurement chain matter because motion and vibration are physical quantities, not arbitrary variables in a software demo. EtherCAT also presents a genuine engineering constraint: the exchange is handled by a master over Ethernet frames, not by connecting to a conventional website or opening a generic TCP socket. At this layer, a mistaken ownership decision can disrupt the entire experiment.

We studied an optional reader using SOEM (Simple Open EtherCAT Master), a software library for an EtherCAT master, while separating its network-adapter responsibility from the robot-oriented MCU transport. The technical reward was not merely getting a channel: it was learning why configuration, operational state, working counter, timing, scaling and signal naming must all remain visible. Our retained V06 notes include a bounded operating result, but a laboratory result is never a universal vendor compatibility certificate.

Why Arduino and openDAQ became the natural next steps

Arduinogave the programme a practical embedded foundation. Unlike a proprietary one-purpose recorder, a development board lets students explore sampling, firmware, communication interfaces and failure recovery directly.openDAQcontributed the idea of a self-describing device with named signals and time domains, so acquisition software and a scientific consumer could speak about the same source without sharing the original bus-driver implementation. The gateway’s acquisition process still owned EtherCAT; openDAQ represented the admitted results. This division later informed our GIGA streaming and UNO Q work.

Case study · project origins · engineering status:historical IOLITE/EtherCAT integration, later Arduino/openDAQ gateway development.Project start:the IOLITE exploration predates the first dated integration note found in the retained archive (9 July 2026); the exact first working day is not established by that record. This article is an engineering history, not a certification of a commercial EtherCAT product.

The original engineering question

Before the currentLinux ARM64, Native-streaming, Browser Integration Kit and EFBus companion work, our measurement laboratory began with a practical question: could an Arduino-class platform act as a useful gateway to aDewesoft IOLITE EtherCATacquisition system, while exposing the results through the openDAQ device-and-signal model? This was the starting point of a broader Arduino and Dewesoft engineering programme. openDAQ became the common software language between embedded producers, measurement clients and later scientific applications.

The motivation was not to replace professional instrumentation. It was to connect accessible embedded systems to professional data-acquisition workflows, and to discover precisely which timing, source-identity and transport details must survive an integration.

Architecture: three separate responsibilities

• IOLITE / EtherCAT:a dedicated Ethernet adapter and a Simple Open EtherCAT Master (SOEM) acquisition process interact with the Dewesoft IOLITE device using raw Ethernet frames, not ordinary TCP/IP traffic.
• Arduino/Linux gateway:the host integrates the optional IOLITE acquisition source with separately owned MCU telemetry; each source retains its own clocks, rates and status.
• openDAQ:a Native-compatible device model publishes named channels, signal descriptors and time domains to external clients. This is the integration interface, not the owner of EtherCAT bus control.

A critical design decision was to avoid running two competing EtherCAT masters on the same interface. The laboratory dashboard exposes IOLITE as an explicitly enabled source; when it is switched off, the reader and its background polling stop so that unrelated EFBus transport measurements remain meaningful.

Documented history and updates

What the engineering evidence establishes

The retained technical index recordsIOLITE 3xMEMS EtherCAT OP, WKC 1/1 and a 500 Hz scopefor its validated UNO Q V06 technical package. These results apply to that particular laboratory configuration. They do not constitute general interoperability certification for every IOLITE model, every EtherCAT slave or every firmware release. The V04/V05 implementation and the V06 validation are different versioned states, not one undated result.

The openDAQ model also makes a useful distinction: values and a host-receive timestamp are not automatically a hardware-synchronized measurement. The source clock, conversion/mapping, reference-domain identity and uncertainty must be stated before comparing unrelated devices.

How this led to GIGA, EFBus and the robot

The initial integration experiment led to a broader architecture. Arduino GIGA R1 became a direct Streaming LT producer, validated separately against DewesoftM.Arduino UNO Qgained its own gateway path. EFBus, developed for MCU-to-Linux and robotics needs, provided a reusable typed transport; its optional openDAQ companion presents that data as signals without letting openDAQ own the SPI bus. Subsequent work qualified openDAQ 3.40.3 on Linux ARM64 and explored browser-based inspection, reference recordings and scientific-data consumers.

These areconnected engineering decisions, not a claim that a prototype was simultaneously running all later features.

What this does not prove

• No general EtherCAT interoperability certificate, third-party product approval or production readiness is implied.
• The original SOEM/IOLITE initialization procedure and potentially device-specific technical material require rights and partner review before any public source release.
• The 500 Hz V06 scope must not be reused as acceptance evidence for later firmware, different hardware or a different Native companion.
• Physical measurement, software reference generation, replay and modeled results remain different evidence classes.

Related projects and source notes

ExploreArduino OpenDAQ,Arduino EFBusand theMeasurement & DAQ hub. TheopenDAQ Community Projectspage already features an Arduino gateway and EtherCAT bridge with a historical SmartKids link. The goal is to tell the complete documented evolution here rather than create a competing historical project.

Publication note:detailed engineering and version-history records are maintained internally.Editorial update:3 November 2026. The first-project date will be revised only when an earlier dated artifact is confirmed.

Visual assets / publication checklist

Illustrative architecture diagrams may show IOLITE → EtherCAT/SOEM → Arduino/Linux → openDAQ Native. Authentic device photographs, source screenshots and signal plots remain to be added with provenance. Do not present a schematic as a screenshot of physical acquisition; verify the licence and rights for third-party logos, code and hardware images before publication.

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 OpenDAQ project;UNO Q and GIGA measurement-path update;Arduino EFBus project;Arduino Measurement and openDAQ course. Links to the other new case studies will be enabled individually as their articles become public, rather than linking to inaccessible drafts.

What a student can learn from this first experiment

Three learning questions make the story useful even without an IOLITE unit on the bench. First: who owns a bus? A single Ethernet interface cannot safely host two independent EtherCAT masters without an explicit arrangement. Second: who owns time? Sensor time, host receive time and displayed plot time are different concepts. Third: what does a published “signal” promise? Besides values, a reader may need channel identity, units, quality and a declared source clock. These are the foundations of trustworthy data acquisition.

A student exercise can start with a drawing: place the sensor, EtherCAT master, gateway and openDAQ client in separate boxes; annotate who configures the device, where measurements are created and where timestamps are assigned. Then identify what a software-only reference test could verify versus what would require a real sensor. That exercise mirrors the reasoning that guided our implementation.

Why this story is relevant to technology partners

For Dewesoft, the case shows how professional measurement devices can inspire an educational integration project beyond their usual application. For Arduino, it demonstrates the appeal of embedded development as an accessible entry point into industrial communication. For openDAQ, it highlights why open signal descriptors and time-domain metadata make cross-platform exploration possible. The value for each company is a documented use case and a set of student questions that their technologies helped us investigate—not an invented commercial deployment.

Partner-ready case study summary

Dewesoft IOLITE EtherCAT inspired a student-led experiment: could an Arduino/Linux gateway expose professional sensor data as reusable openDAQ signals? FermiLabs explored an optional SOEM EtherCAT master, explicit bus ownership and a Native-capable signal model. A dated July 2026 technical package recorded a bounded 3xMEMS operating state and device topology; it did not certify every IOLITE model. The challenge seeded a broader laboratory, including Arduino GIGA R1 Streaming LT, EFBus from rescue robotics, and later Linux ARM64 openDAQ work. This engineering journey shows why metadata, source ownership and honest timing claims matter as much as receiving numeric values. It is intended as an educational integration story, with exact device/firmware evidence retained in the owning technical repository and remaining physical or production gates described openly.

Collaborate with FermiLabs

We would welcome technical feedback on EtherCAT interoperability, access to verified test configurations, advice on source-clock interpretation and educational opportunities to compare professional instrumentation with embedded prototypes. Our invitation is to help students ask better questions and test them rigorously, not to endorse unqualified compatibility. See theMeasurement & DAQ hubfor the wider programme.