DEV Community: Marco

SLX OrbitLab: satellite mission software with F Prime and Basilisk

Marco — Wed, 14 Oct 2026 12:37:17 +0000

An Earth observation mission requires coordinated orbital planning, attitude control, energy management and data transfer. SLX OrbitLab integrates these functions in a PC-based software system: a simulated satellite receives a target, plans the pass, acquires an optical product and transfers it during ground-station contact. Commands, telemetry and events track software decisions and the physical model's response.

SLX OrbitLab is the Silicon LogiX platform for satellite mission software development and simulation, autonomous systems and embedded controllers. Version 0.7.0 integrates a native NASA F Prime deployment running on Linux, a proprietary C++ core, Basilisk simulation, a Qt desktop console and Godot 3D inspection. An optional subsystem executes RTEMS firmware on a LEON3 processor emulated in Renode. The platform executes a complete command, physics simulation and telemetry cycle on a PC. Integration tests connect operational decisions, spacecraft dynamics and firmware behavior.

Embedded engineering and mission software integration

Flight software: F Prime components, FPP interfaces, dispatching, telemetry, events and native command sequencing.
Simulation and control: orbital and attitude dynamics, sensor measurements, reaction wheels and energy accounting.
Embedded systems: RTEMS firmware, the LEON3 BSP, timers, periodic tasks, UART and CRC-protected protocols.
Verification: repeatable faults, recording, synchronized replay, strategy comparisons and measured results.
Integration: Qt operation, Godot visualization and a C++ core that can be supplied separately as a binary library.

Mission software architecture: commands, simulation and telemetry

The operational path is explicit: command → mission software → physical simulation → telemetry → console and 3D update. The GUI sends a request; F Prime receives it through its dictionary and dispatcher; the Mission component calls the C++ core to assess conditions and select actions. Basilisk applies actuator commands and power loads, integrates the dynamics and returns new measurements.

At the next step, mission software consumes those measurements, updates its decisions and emits telemetry and events. GUI refreshes do not advance physical time. This boundary makes it possible to repeat an experiment, pause it, advance by individual steps and inspect the same moment through different views.

F Prime executes mission logic; Basilisk returns the physical response. Native packets and simulation snapshots feed recording, the console and 3D views. The optional RTEMS node uses a distinct interface, shown later.

SLX OrbitLab technology architecture

Technology	System responsibility
F Prime 4.3.0 / C++	Commands, components, events, telemetry channels, responses and native sequencing.
Silicon LogiX C++ core	Mission decisions, target management, energy assessment, protection and attitude control.
Basilisk 2.12.0 / C++ and Python	Orbit, attitude, sensors, reaction wheels, solar generation, battery and applied thrust.
Qt 6.12 / QML	Mission console, command and sequence editors, telemetry, recordings and reports.
Godot 4.5 / Blender and GLB assets	Synchronized spacecraft, interior, exploded, orbit and ground station inspection.
RTEMS 5 / Renode 1.16.1	Energy-controller firmware running on an emulated LEON3/SPARC target as an optional subsystem.

F Prime: C++ components, native commands and telemetry

F Prime organizes flight software into components with declared ports and connections. OrbitLab uses this architecture as its command execution path. FPP definitions describe parameters and interfaces, the Ground Data System uses the generated dictionary to encode requests and decode packets, and the native dispatcher delivers each command to its destination component.

Version 0.7.0 exposes 28 dictionary commands and 50 native channels. Selecting a command shows its parameters, examples and operational meaning. Operators can request panel deployment, a relative rotation, Sun or Earth pointing, payload and downlink permissions, a beacon and the orbital maneuvers supported by the model. Diagnostic commands also verify the communication path.

For example, OrbitLab.mission.MANEUVER [3,30] requests a 30-degree relative rotation in mode 3. The dispatcher response confirms acceptance of the parameters; telemetry subsequently shows pointing error, attitude and actuator state. Acceptance, physical effect and operational completion are separate pieces of evidence. An accepted request may remain pending while simulation time is paused or energy, sensors and protection inhibit the action.

For a commissioned project, this executable path supports concrete discussions about interface contracts, parameter bounds, component behavior, failure handling and integration tests.

The F Prime console presents command arguments, operational responses and telemetry from the Linux deployment.

F Prime sequences: planning, validation and execution

OrbitLab integrates native Svc.CmdSequencer execution. Operators prepare plans of 1 to 64 steps with relative delays in simulated seconds and validate them against the session dictionary. F Prime tools compile the binary file; native validation checks its format and CRC before execution.

A plan can run automatically or advance through manual steps. Cancellation, completion verification and responses for each step are preserved. Delays follow simulation time and begin after the previous command's response. Pausing stops this clock as well, keeping sequencing and dynamics consistent.

The eight-step example deploys the panels, suspends the optical instrument, requests Sun pointing, enables the beacon after five seconds, commands a 30-degree rotation after another 45 seconds, disables the beacon after another 60 seconds, and restores the payload and automatic mission. Events and telemetry show the executed list and its consequences for the spacecraft.

Sequences time command requests; they do not automatically wait for attitude convergence. Acquisition conditions remain in the C++ mission state machine. Separating the operational plan from control of physical behavior supports focused testing and a correct interpretation of the results.

The Qt console presents the operational plan and native validation. Step responses and times are preserved; completion of the command list is distinct from physical attitude convergence.

Basilisk: orbital dynamics and attitude control

Basilisk combines C++ numerical modules and Python configuration for space-system simulations. OrbitLab uses this foundation to integrate orbital position and velocity, attitude and angular rate, sensor measurements and reaction-wheel action. Python coordinates the laboratory and adapters; mission decisions execute in the C++ component.

The reference case declares an initial circular orbit at approximately 550 km, a 65 kg rigid body and three reaction wheels. Quantities cross the simulation boundary with explicit units: metres, metres per second, seconds, radians, watts and joules. Attitude and measurements use declared frames, distinguishing the controller's available information from diagnostic simulator truth.

Orbital maneuvers integrate mission commands, operational constraints and propulsion dynamics. An RTN delta-v command is checked against energy, propellant, sensors, alignment and orbital conditions. Basilisk integrates finite thrust applied to the body; reports retain delivered delta-v, remaining propellant and changes to orbital parameters. Adding a terrestrial target during a mission preserves the existing trajectory. The software predicts accessible passes, while a physical burn changes the orbit gradually.

Energy management and activity planning

The battery has a finite capacity of 180 Wh. Solar generation, panel orientation and deployment, eclipse and active loads contribute to the physical balance. The core compares available energy, reserves and activity demand, using a short-horizon energy forecast. The numerical foundation includes Basilisk's storage model and solar-generation model.

When energy is insufficient, acquisition is deferred, loads are reduced and the reason is recorded. The physical model therefore experiences a different consumed power from the load required to capture an image. Battery telemetry reflects an energy balance changed by the software decision. Protection remains active during manual requests.

Two comparable strategies, priority-first and energy-aware, use different planning margins while both protect the minimum reserve. A comparison starts from the same initial conditions, targets, seed, faults and recorded stimuli, with separate F Prime processes and Basilisk simulations. Results include completed or deferred observations, final energy and pointing accuracy during acquisition.

A geometrically useful window is only part of the decision. Software authorizes the activity against energy and sensor state; deferral and its reason become recorded mission evidence.

Earth observation: targets, acquisition and downlink

The operator selects coordinates and priority. Software predicts access windows, commands pointing and requires stability before exposure. The reference configuration requires a measured error below 0.5 degrees, three seconds of stability and a twelve-second exposure. These values are parameters of the simulated mission.

The synthetic optical product uses actual simulated body attitude, camera-ray intersections with the spherical Earth and the geographic texture. Raw data is a 256 × 256 monochrome PGM image. A derived PNG preview relates the target, sensor footprint and cartographic context, making the experiment's content easier to interpret.

Bytes are saved in modeled onboard storage and transferred during a geometric ground-station contact window when energy permits downlink. Storage capacity, the product queue and link availability can change the plan. Delivery is confirmed when the received file passes its SHA-256 integrity check. The link model verifies data handling and mission constraints; it does not calculate an RF link budget or radio modulation.

Qt console and 3D visualization with Godot and Blender

Qt Quick and QML compose the operational console: mission control, F Prime commands, sequence editing, channels, targets and products, orbital passes, tests and recordings. The telemetry model updates values while preserving the operator's browsing position. Parameters and descriptions connect a command to its function, operational response and telemetry. One operator controls a session; viewers receive its state.

Godot 4.5 presents close-up spacecraft, interior, exploded, orbit and ground station views. Component selection connects geometry to subsystems and available commands. Attitude, panel joints, the beacon and antenna follow confirmed backend telemetry.

Blender assets and GLB exports retain original component names, hierarchy and pivots. Earth's illustrative scale and exploded-view offsets belong to presentation and do not enter the dynamics. Blender/glTF axis conversion is explicit and applied once. This integration choice makes 3D a useful inspection tool while keeping it distinct from the physical model.

RTEMS and Renode: embedded firmware on emulated hardware

RTEMS provides the kernel and services for real-time embedded applications. In OrbitLab it executes an independent energy-controller firmware. F Prime remains a Linux process; RTEMS is a separate subsystem. Interfaces between mission software, the energy model and firmware handle power requests, controller responses and load states.

Renode emulates the LEON3/SPARC target, including the peripherals needed for timers and UART. Antmicro's public RTEMS/LEON3 example documents the platform overlap; OrbitLab's integration was verified with its own firmware. Compatibility requires alignment between the ELF, BSP, memory map, clocks and timer, followed by boot and execution tests.

The adapter sends battery energy, capacity, requested power and explicit mission time through sequence-correlated, CRC-protected UART messages. Firmware returns permitted power, flags and the task heartbeat. This permission constrains the loads applied to Basilisk. Tests cover boot, timer interrupts, a periodic task, load reduction at low and critical energy, malformed CRC rejection and recovery after an invalid message.

Emulated time advances in controlled intervals. Missing firmware responses stop the experiment; the laboratory does not silently replace RTEMS with PC logic. Compatibility and integration tests cover this specific combination of firmware, BSP and emulator. Qualification of electronics or a flight processor requires dedicated work.

The physical model retains battery and load dynamics. Emulated firmware authorizes power over a verified protocol, allowing embedded execution and its effect on the mission to be analyzed independently.

Mission scenarios, synchronized replay and results analysis

Operational scenarios and fault management

Scenario	Expected operational outcome
Nominal mission	Target access, stable pointing, acquisition, storage and a delivered file with verified integrity.
Insufficient energy	Deferred activity, a recorded reason, reduced loads and a recorded recharge balance.
Temporary sensor outage	Acquisition held while measurements are invalid, tracked sensor state and renewed condition checks after recovery.

The extended campaign also covers actuator faults, loss of solar generation or ground link, multiple products, full storage and continuous operation. Fault-injection intervals and operator commands are retained as test evidence.

SQLite recording preserves configuration, commands and native packets, events, physical snapshots and products. Replay restores recorded state without redispatching actuator commands. Timeline, telemetry, imagery and 3D follow the same instants. HTML, JSON and CSV reports and SHA-256 manifests support investigation from a shared trace and strategy comparisons with explicit metrics.

The release 0.7.0 acceptance evidence records 26 Linux integration tests, three Windows CTest checks, eight publication-boundary regressions and GUI workflows with native commands, sequences and maneuvers. Operation with a binary SDK, without the proprietary core sources, was verified separately.

The documented SDK case delivers one product with an acquisition pointing RMS of approximately 0.0586 degrees. A maneuver delivers 2 m/s and updates remaining propellant. These are results for the stated configuration and test conditions, rather than an accuracy promise for arbitrary satellites.

Proprietary C++ core, binary APIs and simulation models

The proprietary Silicon LogiX engine exposes a versioned C ABI with fixed-size structures, declared units and an opaque handle. Its interface contains no Qt, Godot, Python or F Prime types. The core can be supplied as a shared library and integrated or updated while preserving the binary contract, independently of presentation and adapters.

The public GitHub repository contains the GUI, integrations, API, example firmware, scenarios, approved assets, documentation and tests. Proprietary core implementation is excluded. Building and running OrbitLab from public source requires the matching evaluation binary SDK; distribution and commercial development follow the project's terms.

The model declares its scope: spherical Earth, simplified reference frames, no J2 perturbation, atmosphere, terrain or thermal environment, an ideal battery, constant dynamic mass and a synthetic optical instrument. It does not represent cell chemistry, analog power electronics or a complete RF link. Repeatability is verified with the pinned Linux environment and the same seed; cross-platform bitwise identity is not promised. The model documentation makes parameters, criteria and simplifications available for review.

Custom engineering for companies and research organizations

OrbitLab's architecture integrates engineering capabilities applicable to mission software, embedded controllers, simulation benches and operational consoles. For companies and research organizations, a project can begin with operational requirements, available measurements, energy constraints, abnormal conditions and system acceptance criteria.

F Prime components: FPP definitions, topologies, commands, telemetry, events, service integration and native tests.
Simulation and autonomy: Basilisk models, C++ control, planning, resource management and fault scenarios.
Embedded firmware: RTOS/BSP integration, protocols, peripherals and emulated-target verification before hardware tests.
Consoles and tools: Qt/QML applications, 3D inspection, evidence acquisition and presentation.
Verification and delivery: repeatable campaigns, agreed metrics, reports, documentation and distributable interfaces.

Explore the OrbitLab repository and technical documentation, or contact Silicon LogiX for a technical presentation, an evaluation SDK or a custom project. The starting point is to define what the system must do, how it should respond at its limits and which tests must document compliance with those requirements.

SLX RadioTwin: industrial radio propagation studies with C++ and Qt

Marco — Tue, 13 Oct 2026 07:20:43 +0000

Silicon LogiX introduces SLX RadioTwin, a desktop demonstrator for studying radio propagation in a three-dimensional industrial plant. The project brings geometry, antenna configuration, obstacles and robot movement into one environment, making it possible to compare how link conditions change. Version 0.2.1 is available on GitHub with a Windows evaluation package.

For a company integrating wireless sensors, gateways or mobile robots, the questions concern what happens along a mission: where does received power fall? Which obstacles does the radio path cross? What difference does a metal door make? RadioTwin makes these questions explorable and documentable, connecting each result to the assumptions that produced it.

Industrial connectivity also depends on geometry

A plant contains surfaces, volumes and passages that affect propagation. Tanks, machine tools, shelving and walls can change the signal path; a door changing state or a moving receiver introduces different conditions even with the same radio parameters. Studying these variations requires a shared reference between object positions, link configuration and numerical results.

The demonstrator uses a scene with 2,584 meshes in its complete representation: a process area with tanks and pumps, CNC machines, a warehouse, a raised control room, robotic arms, an inspection robot, two gateways and a sliding door. The cutaway view allows users to explore the interior, navigate and select components. The RF engine retains the complete enclosure, including walls and the roof, through 373 meshes dedicated to calculations. Opening up the factory view therefore keeps the obstacles in the radio model.

The robot, door and gateways share the scenario state between the visualization and RF geometry. This consistency makes it possible to relate a change in estimated received power to the configuration actually analyzed, while keeping the demonstration animation distinct from experimental measurements.

An explicit RF model with interpretable results

The solver combines free-space path loss with effective losses associated with the obstacles crossed. Intersections are calculated on the triangles of the RF geometry; a BVH, or bounding volume hierarchy, accelerates the search for possible intersections. Antenna positions, frequency, transmit power, gains, receiver sensitivity and material parameters are configurable.

An optional first-order reflection model uses image sources on six enclosure planes. Each path reports power, length and delay. Powers are summed incoherently: this version does not reconstruct the phase interference of a coherent multipath channel. Results distinguish power in dBm, losses and margins in dB, distances in metres and delays in nanoseconds.

Material coefficients are illustrative assumptions, not values calibrated against a real plant. The model supports comparative studies and checks of software behavior; field accuracy requires surveys and calibration. Diffraction, polarization, antenna patterns, protocol traffic and throughput are not simulated in the published version. The RF model documentation describes equations, units and limitations.

From individual links to scenario comparisons

The interface allows users to observe the link as the robot moves, visualize coverage, identify areas with reduced margin and save configurations for comparison. One example is studying an open door against a closed door while keeping the same planned route and radio parameters.

Coverage is sampled on a 49 × 37 grid at receiver height, with points occupied by solids excluded from the count. The mission profile contains 81 samples along the planned 16-metre corridor. The placement search evaluates up to 15 candidates for gateway A, keeps gateway B fixed and compares the worst value of the best link along the route. This is a comparison between defined candidates; mounting feasibility and site performance require separate verification.

The scenario laboratory in the software. The displayed values belong to an example using illustrative coefficients.

Analyses can be exported as PDF, JSON and CSV, retaining the configuration, geometry identity, units and assumptions. For a technical team, this makes it possible to discuss the same configuration, compare alternatives and retrace the reasoning behind a result. Before export, the application requires an updated analysis when the state has changed.

The technologies: C++, Qt Quick and native GPU rendering

RadioTwin demonstrates a software architecture that separates the interface, scenario management and numerical computation. The C++17 core handles asset import, geometry queries, propagation, coverage and candidate evaluation. The desktop presentation uses Qt Quick and QML, while the 3D viewport is implemented in C++ with QQuickRhiItem and Qt RHI, Qt's interface to the graphics backend.

The renderer groups geometry by material and uses GPU buffers. The Windows distribution has been checked with Direct3D 11. GLB/glTF assets retain geometry, materials and hierarchies; coordinate transformations connect the visual representation to the metric system used by the solver. GPU acceleration applies to rendering: RF calculations in this version run on the CPU.

QtConcurrent runs analyses asynchronously on copies of the scenario. The application checks the parameter version before accepting a result, avoiding the presentation of calculations for an earlier configuration as current. The numerical core is distributed as a DLL with a public API and a versioned ABI, while its implementation remains proprietary. This separation provides a starting point for modules and integrations agreed with the customer.

The build uses CMake, Ninja and the Qt 6.12.0 / MinGW GCC 13.1.0 kit. Checks cover reference equations, radio link-budget accounting, reflections, geometry consistency, persistence and scenario comparison. Public-distribution audits also run through GitHub Actions. These checks verify implementation consistency; RF validation at a plant requires independent measured data.

A concrete basis for tailored industrial tools

The value for companies is the opportunity to evaluate a working application and define a specific need: studying a robot route, comparing permitted antenna positions, documenting a scenario or connecting a model to plant data. This provides a basis for a technical discussion about geometry, devices, available measurements and acceptance criteria.

The custom-development section presents eight proposals, explicitly not implemented in the demonstrator. They cover measurement-based calibration and uncertainty quantification; coherent wideband channels with fading and Doppler; MIMO and beam steering; interference and coexistence; robot missions with radio and navigation constraints; network design with redundancy; CAD/BIM, OPC UA or MQTT integration; and research into programmable RIS surfaces and joint communication and sensing.

Each proposal identifies required data, expected outputs and checks to agree on. The application lets users select modules and prepare a local brief containing objectives and constraints. Extensions can then be defined through a feasibility study, a development scope and a validation plan suited to the industrial case.

Evaluate RadioTwin and discuss a project

The SLX RadioTwin repository contains the frontend, public API, binary SDK, assets and examples. Release 0.2.1 includes a Windows x64 package that runs without installing Qt and without radio hardware. A demonstration video with 3D animations and actual software screens is also available.

The license permits study and business evaluation; production integration and distribution of modifications require an agreement with Silicon LogiX. To assess a custom development, contact us with the type of plant, the wireless devices involved, the behavior to analyze and the data already available. These inputs help define the required model, measurement activities and results to verify.

Originally published at Silicon LogiX.

Raspberry Pi 5 AI: quality inspection without the cloud

Marco — Mon, 12 Oct 2026 11:41:55 +0000

A reversed connector, a missing screw, the wrong label: catching a defect before shipping requires a repeatable inspection. Raspberry Pi 5 with local AI is a platform worth evaluating for an initial visual inspection system that processes images close to the machine.

On 5 October 2026, Raspberry Pi published an overview of Sixfab AI HAT+, an accelerator board with a DEEPX NPU. For businesses, the useful question is how to connect image capture, recognition and inspection results in an application that can work without a cloud connection. Read the Raspberry Pi article.

The cover is an AI-generated conceptual illustration. The diagram and example below describe a possible design; they do not depict a system tested by Silicon LogiX.

What Sixfab AI HAT+ and DEEPX add

The 25 TOPS version uses the DEEPX DX-M1M NPU, a processor dedicated to model execution. The Sixfab documentation lists these main specifications:

Sixfab AI HAT+ 25 TOPS: manufacturer specifications checked on 12 October 2026.

Attribute	Specification
AI compute	Up to 25 TOPS at INT8 precision
NPU memory	2 GB dedicated LPDDR4x
Connection	PCIe Gen 3 ×1 to Raspberry Pi 5
Typical power	Approximately 3 W for the NPU alone
Processing	On-device inference, including offline operation after installation

Three watts is not the power consumption of the complete station. Its power budget must include the Raspberry Pi, camera, lighting, storage and interfaces. TOPS, or trillions of operations per second, describes computing capacity; the time to inspect a part must be measured across the complete application.

What can a camera with local AI inspect?

Start with a defect that is visible, clearly defined and distinguishable at the available resolution. Three examples illustrate the kinds of projects to consider:

Assembly: check whether a connector or component is present and correctly oriented, with a controlled capture position.
Packaging: identify a missing accessory or an incorrect product arrangement before closing the package.
Surface finish: evaluate detection of scratches or surface anomalies after checking optics, contrast and lighting.

A camera cannot see beneath an opaque component or replace an electrical measurement. On an electronic assembly, it can complement functional testing: images check assembly, while measurements check behavior. Reading a code or checking a stable geometry may also be a good candidate for traditional computer vision algorithms.

From the part to the result: an inspection example

Imagine a station that checks a connector on a small electronic module. An operator places the part in a fixture; a signal triggers capture; the software analyzes the image and displays the result. Communication with the machine uses an interface designed for its controller.

Part + controlled lighting
         |
         v
Raspberry Pi 5: capture and preparation
         |
         v
DEEPX NPU: model execution
         |
         v
Inspection software: rules and review
         |
         v
Result: operator, controller and records

An original diagram of a possible station. Application software connects the model output to the product acceptance rules.

For this application, we would design three outcomes: accepted, defect detected and review required. A blurred image, a misplaced part or an insufficient score should trigger recapture or operator review. The application must handle uncertainty before commanding a rejection.

Each inspection should record the part identifier, timestamp, model version and outcome. Which images to retain, and for how long, depends on the process. These records make it possible to investigate inspection conditions and compare two software versions against the same cases.

Do you actually need a Raspberry Pi 5 NPU?

The decision depends on the real workload. Before buying an accelerator, measure a CPU implementation with the intended model. An NPU becomes interesting when inference time, image volume or application load requires more headroom. Our guide to NPUs in embedded systems explains the accelerator’s role.

Consider an illustrative timing budget: at 60 parts per minute, a part arrives every 1,000 milliseconds. A proposed budget could allocate 100 ms to capture, 150 ms to processing and 100 ms to decision and communication, leaving 650 ms of headroom. These are design examples, not measured board performance. The available capture window also matters: the part may spend much less than one second in front of the camera.

Testing must include the slowest cycles while the system saves images, updates the interface and communicates with the machine. A favorable average can hide occasional delays, image queues or missed acquisitions.

How an AI model reaches the board

In the workflow documented by Sixfab, a supported model is exported to ONNX, compiled with DX-COM on an Ubuntu x86_64 machine and deployed as a .dxnn file. The Raspberry Pi runtime executes it through C++ or Python APIs. Training and compilation are separate from on-device inference.

A product-specific defect requires representative images and consistent annotations. When photographing the same parts repeatedly, avoid placing near-identical images in both training and test sets. Splitting samples by physical part or production lot makes evaluation closer to real use.

The INT8 conversion requires checking the deployed model: changes in its results must be measured on your own defects. For repeatable development cases, SLX SynthForge demonstrates a workflow with synthetic scenes and data. A production line still requires real images and validated capture conditions.

How much does a Raspberry Pi quality inspection system cost?

The Sixfab product page lists the 25 TOPS AI HAT+ at US$90 as of the consultation date. That is the add-on board price; the Raspberry Pi and complete station must be budgeted separately. Check the final price, taxes and shipping with the supplier for your destination market.

The project budget should include:

Image capture: camera, lens, lighting, mounts and the part fixture.
Electronics: computer, power supply, cooling, enclosure and controller connection.
Data and model: sample collection, annotation, training and evaluation.
Software: operator interface, result handling, records and business-system integration.
Commissioning: testing on real lots, acceptance thresholds and maintenance.

To estimate the station’s value, compare total cost with the existing process: inspection time, rework, rejected parts and escaped defects. A prototype helps collect the evidence for that assessment before extending the system to production.

Five checks before putting AI on the production line

Missed defects: measure how many defective parts are accepted and which defects remain difficult.
False rejects: check how many conforming parts are rejected or require manual review.
Real conditions: test different lots, position variations, reflections and lighting changes.
Continuity: check restarts, camera disconnection, exhausted storage and communication loss.
Updates: retain the approved model and software, a fixed test set and a procedure to restore the previous version.

Define these criteria before testing. If a model is selected after repeated trials on the same samples, use another independent set to verify the result. For multi-camera lines, our article on industrial vision over Ethernet also covers bandwidth and capture architecture.

Frequently asked questions about Raspberry Pi AI inspection

Can inspection work without Internet access?

Inference runs locally after installation. Offline station operation also depends on application choices: models, licenses, authentication and result recording must be available at the deployment location.

Will a ready-made model recognize my product’s defects?

A pretrained example helps verify that the system processes images. For a specific defect, evaluate behavior on your own product samples and prepare a dedicated model if necessary.

Can the board also accelerate language models?

The consulted sources disagree: the Raspberry Pi post also describes language models, while Sixfab lists vision as the current scope. This article considers visual inspection. A language-model project requires support confirmation for the chosen hardware, model and runtime.

From a specific defect to a feasibility study

Silicon LogiX can support a project by connecting AI and machine learning, embedded Linux and custom software. The first step is defining what to observe, the required timing and how to use the result in the business process.

Want to assess whether AI can catch a defect in your product? Describe the inspection you want to automate, your available samples and the line cadence. These details help establish a useful feasibility study.

Technical sources consulted on 12 October 2026. Specifications and pricing are manufacturer statements; the timing example and evaluation criteria are Silicon LogiX design contributions.

Originally published on Silicon LogiX.

SLX ResilienceLab: simulated faults, measurable control responses

Marco — Sat, 10 Oct 2026 11:31:04 +0000

A sensor keeps sending a plausible value while the actuator moves away from it. The primary controller stops responding. Two measurements disappear while the system is approaching its requested position. Control software must handle these conditions, yet ordinary bench tests can make them difficult to reproduce.

SLX ResilienceLab is Silicon LogiX's new desktop demonstrator for exploring these cases in an entirely software-based test bench. A virtual motorized valve, three position sensors and two C++ controllers let you observe the response, inject faults and retain the results. The project demonstrates how a dedicated test environment can be built around a product's control software.

For teams developing boards, firmware or machinery, the practical value is repeatability: recreate a critical condition, compare two control versions and discuss the response using recorded measurements, timings and events. Contact me to discuss a test bench for your product.

A virtual valve with decisions computed by the software

The operator requests an opening, such as 80%, and follows the valve's movement in normal and cutaway 3D views. The interface keeps requested opening, actual model position, three sensor readings and the control measurement separate. This makes it possible to see when a reading no longer represents the movement.

The primary and backup controllers execute real C++ code. They receive measurements and messages through a virtual transport and calculate the motor command. They cannot directly inspect the plant's actual position or the operator's fault settings: they must respond using received information. Heartbeats, commands and measurements travel through the transport, where delays and losses can be introduced.

An actual laboratory screenshot during the stuck-S1 scenario. Model position and the measurement used by control remain visible as separate values.

Sensor redundancy compares readings using configurable disagreement thresholds, confirmation times and freshness limits. With two trustworthy measurements, it can exclude a disagreeing sensor; when information is insufficient, it requests a stop. Arbitration authorizes only one controller to command the motor at a time, including during transfer to backup.

Three tests with observable responses

The demonstrator includes three ready-to-run scenarios. The following chart uses traces produced by executing version 0.4.0, with an 80% requested opening, 12 simulated seconds, a 20 ms step and seed 2407. It represents software model results under these stated conditions.

Green: actual virtual plant position. Grey dashed line: requested opening. In the first chart, red: the frozen S1 reading. Times are simulated, not measurements from physical hardware.

Stuck sensor. S1 freezes at 1.60 s. The first isolation event appears at 2.12 s, after 0.52 s; the primary isolates S1 at 2.14 s. Control continues with S2 and S3 and finishes with approximately 0.14 percentage points of position error.
Primary controller loss. The controller stops at 2.00 s. The watchdog stops the motor at 2.24 s and arbitration authorizes backup at 2.58 s: takeover occurs after 0.58 s. The valve resumes movement and finishes with approximately 0.16 percentage points of position error.
Measurement loss. S1 and S2 disconnect at 2.00 s. Their readings expire at 2.40 s and the motor stop is applied at 2.42 s. Final position is 51.48%: the expected outcome is to stop because sufficient information is unavailable.

The report retains position errors, detections, transfers to backup and stops. HTML, JSON and CSV exports make the evidence accessible and usable in other tools. Configuration, the fault timeline and seed let you replay a scenario and compare two control versions under the same simulated conditions.

Why this approach helps embedded development

The principle is software-in-the-loop: execute compiled code on a computer and subject it to repeatable test inputs. MathWorks' SIL and PIL documentation describes how these environments help verify code behaviour during development. ResilienceLab applies this principle using its own C++ and Qt Quick architecture.

Fault injection makes the condition under test explicit. Alongside the ready-to-run scenarios, the laboratory supports progressive sensor drift, disconnections, intermittent communication and actuator jamming. In a physical bench, electrical faults require dedicated interfaces: NI's explanation of fault insertion units illustrates that testing layer. In this demonstrator, faults affect the model and its messages.

For a development project, the benefit is defining verification criteria early: how many measurements are needed to continue, how quickly a loss should be detected, which controller may issue commands and which events must be retained. The same test can then become a regression check when firmware changes.

From PC control to a board connection

The laboratory also supports live operation: change the requested opening and freeze, disconnect or restore sensors while the valve is moving. Actions are recorded so the test can be reconstructed. 1× mode follows the PC clock; a desktop operating system does not guarantee strict execution deadlines.

Message exchange closes the control loop. Actual position remains a reference for observation and reporting; the controllers operate on received measurements.

To integrate customer code, a DLL interface with a C API can replace the motor-command calculation on the PC. The bench retains measurement handling, heartbeats and arbitration. A local JSON-message API provides measurements and diagnostics, changes the setpoint and requests faults; local TCP and USB/serial connections are available in the software. Integrating a specific board requires implementing and verifying the corresponding firmware protocol.

A further step is hardware-in-the-loop, connecting a physical controller to a simulated environment. As NI's HIL overview explains, appropriate timing and input/output interfaces are part of that architecture. Board firmware driving the virtual plant is an integration to be developed; ResilienceLab currently provides the software demonstrator and its connection points.

Three sensors frozen at the same value can still agree. Majority voting alone does not establish that the valve is moving: in the laboratory, a movement request also enables measured-progress monitoring. This illustrates why a bench must be designed around the product's faults and requirements. SLX ResilienceLab is a software demonstrator with no safety certification; it does not validate a physical valve or a customer's firmware.

A test bench designed for your product

Silicon LogiX can build a dedicated environment for a board or control system: a plant model, an adapter for the product's interfaces, fault scenarios, acceptance criteria and reports. The starting point can be one concrete function, such as verifying the response to a frozen sensor or interrupted communication.

Tell me about your product, available interfaces and the behaviour you need to verify. If you already have a board, include its protocol, signals and timing requirements. We can define a representative first test and the integration path. Let's discuss your test bench.

Explore the project through the portable Windows v0.4.0 release and the GitHub documentation. The proprietary core is distributed as compiled libraries under the Silicon LogiX evaluation licence; the interface and integration examples are separate.

Originally published on Silicon LogiX.

SLX SynthForge on GitHub: AI for industrial vision

Marco — Thu, 08 Oct 2026 18:01:47 +0000

SLX SynthForge is available on GitHub, bringing together computer vision for electronic board inspection, 3D scenes and synthetic data. The Silicon LogiX desktop application lets operators edit a virtual board, capture its image and analyse defects with an AI model that runs locally.

The application uses C++17, Qt Quick and QML. The proprietary Silicon LogiX SynthForge Core engine handles rendering, visual analysis and inference, while Python and NumPy train the classifiers. The project documents the workflow from preparing examples to comparing model versions and preserving inspection evidence.

From a 3D board to defect detection

The reference scene is PowerBoard, a demonstration board with 46 editable components. Operators can remove a component, change its position or rotate it before starting an inspection. The board model distinguishes nominal appearance, missing components and changes in position or appearance.

Each result connects the CAD reference to the captured image detail, the score and the model identity. Outcomes are labelled PASS, DEFECT and REVIEW: an accepted component, a detected defect or a case requiring review. Insufficient visibility or captures outside the expected profile require review, as described in the inspection workflow.

Virtual board inspection: defects in C2 and U4 are associated with the captured image and their CAD references.

The vision engine: Silicon LogiX SynthForge Core

At the centre of the application is a C++ engine distributed as a binary SDK in the SiliconLogiX.SynthForge.Core.dll library. Public APIs expose rendering, dataset generation and inspection functions. The Engine module produces the scene image and applies the numerical model to the capture. The SDK documentation describes the separation between the interface and the engine.

Board recognition uses a 640 × 480 pixel RGB image and a defined inspection camera. The engine analyses the captured pixels; commands used to introduce defects remain preparation and traceability data. Model compatibility, asset identity and capture conditions are checked before inference.

CAD scene
  ↓ RGB capture
  ↓ Visual features
  ↓ Linear softmax classifier
  ↓ PASS / DEFECT / REVIEW and report

The C++ engine connects the virtual scene to image analysis and the inspection outcome.

Machine learning: visual features and softmax classification

The AI technology is a multiclass linear classifier with a softmax function. Numerical image characteristics, called features, are normalised and combined with weights learned during training. Softmax produces class scores, which are used alongside acceptance thresholds and capture checks.

The editable board inspector works with 16 visual features per example and three classes: nominal, missing, and changed position or appearance. The inspector training pipeline preserves normalisation parameters, weights and the model identifier.

The dedicated C1 and U4 component laboratory uses 24 × 24 pixel RGB crops aligned to the component regions. Its model distinguishes five scenarios: nominal board, missing component, misalignment, reversed polarity and solder bridge. This is a separate pipeline with its own visual softmax classifier. Scores describe the model response and need to be assessed in the context of the experiment.

Python and NumPy for model training

Training uses NumPy for numerical computation and the Adam optimiser to update weights. The loss function is cross entropy, which measures how far classifications differ from example labels. The model is selected using validation loss.

Training, validation and testing have distinct roles. Normalisation is fitted on training data; a separate test set evaluates the model after selection. Parameters are exported as versioned JSON files and loaded by the C++ engine for inference. Inspection with the included models works without installing Python; a Python environment is needed to train new models.

Synthetic data and capture robustness

Dataset forge generates examples from the 3D scene and associates them with simulated defect labels. This makes experiments repeatable, organises cases and diversifies training examples. Capture groups are separated between training, validation and testing to reduce data leakage.

Robustness lab varies lighting, reflections, blur and camera tilt. Its result grid shows where the model maintains acceptable decisions and where review or a new capture is needed. The evaluation workflow connects image quality to classifier behaviour.

Qt Quick and C++ for the desktop application

Qt Quick, QML and Qt Quick Controls provide the operator interface: board editing, capture controls, inspection results and AI laboratories. OpenGL handles the interactive 3D preview, with a software mode available for workstations that need it.

C++ services coordinate processing outside the interface flow, keeping presentation separate from rendering and generation tasks. CMake and CTest organise builds and automated checks. The documented architecture distinguishes presentation, the vision engine and training tools.

Model comparison and result traceability

Assembly AI lab collects development cases, prepares new examples and compares the initial model with a candidate. An independent benchmark is frozen before collection: both versions are evaluated on the same data with the same threshold. New examples feed training and validation.

The comparison considers missed defects, false alarms, REVIEW cases and the proportion of accepted decisions. Candidate activation is explicit. Experiments and reports preserve images, CAD references, edits and model identity; HTML, CSV and JSON formats make outcomes accessible. The published validation documents results and the conditions of synthetic experiments.

How to try SLX SynthForge

The v0.4.1 release includes a portable Windows package. The GitHub repository contains application sources, screenshots, documentation and examples. The proprietary engine is supplied as a binary SDK under the Silicon LogiX evaluation licence.

SynthForge is an industrial vision demonstration environment based on synthetic data. Applying the workflow to a production line requires validation with real images, optics, lighting and defects representative of the product.

Industrial vision and custom software

For businesses developing inspection tools or integrating visual analysis and reporting, Silicon LogiX offers custom software development and AI and machine learning services. SynthForge shows how a desktop interface, native engine, training data and verifiable results can work together.

Contact Silicon LogiX about an industrial vision project: describe the process, available data and required functions to define requirements and feasibility experiments.

Topics and technologies

Originally published on Silicon LogiX.

SLX Serial Check on GitHub: serial testing with React and Rust

Marco — Wed, 07 Oct 2026 13:03:38 +0000

SLX Serial Check is now available on GitHub. This new Silicon LogiX project runs repeatable serial tests on electronic boards and embedded devices. The desktop application sends command sequences, checks responses against defined acceptance criteria and retains results, timings and communication traffic in a local archive.

The software is built with React, TypeScript, Rust and Tauri 2 and is distributed as Windows and Linux packages. The project shows how we connect interfaces built with web technologies to native services and hardware communication: from configuring a test to handling errors and exporting the evidence.

From manual checks to a repeatable test procedure

When developing an electronic product, many checks use a serial port: reading the firmware version, sending a command, retrieving a value or verifying a diagnostic response. Repeating these operations manually means keeping commands, limits, waiting times and notes consistent for every board.

SLX Serial Check describes this procedure as a reusable test sequence. The operator selects a port, identifies the board and station, loads the sequence and starts execution. Each command has its own acceptance criterion and produces a result that can be inspected afterwards. This workflow supports laboratory checks, comparisons between firmware revisions and preparation of product-specific test procedures.

Configurable sequences: text, HEX and numeric limits

The editor arranges commands in execution order and lets the operator set the expected response, timeout, delay before sending and repetition count. A command can be disabled while retaining its configuration, or tried individually before starting the complete sequence.

The application supports text commands and binary packets in HEX format. Text responses can be checked with an exact comparison, a substring, a regular expression or a numeric range. Binary packets can be checked against expected bytes, with a precise response length when needed.

The examples included in the repository illustrate the workflow: send PING and expect PONG, verify a firmware version format, or extract a value between 4.9 and 5.1 V from the response to VOUT?. In the last example, the software evaluates the value reported by the device. The HEX example sends AA 01 55 and checks a four-byte response.

The editor keeps commands and acceptance criteria together in a sequence, with separate settings for each check.

A sequence library with revision management

Procedures are saved with a name and revision in a local library. The JSON format allows them to be imported, exported and inspected outside the application. A saved snapshot retains the sequence configuration; subsequent edits become part of that library entry when the operator explicitly saves them.

Changing the name or revision creates a new entry and retains the previous one. The application indicates unsaved changes and asks for confirmation before replacing the current work. For teams preparing procedures for several products, these features help organise variants and identify the configuration in use.

Execution, response timing and error handling

The complete sequence is validated before any data is sent to the board. The engine keeps one serial connection open throughout the run and handles both individual command repetitions and multiple cycles of the procedure. Baud rate, data bits, parity, stop bits and response framing are part of the configuration.

During a test, the interface displays progress, the current cycle, transmitted and received traffic, and check outcomes. A response that fails its acceptance criterion can stop execution according to the operator’s selected policy. Timeouts, communication errors, invalid data and cancellation stop the sequence, keeping failed checks distinct from checks that were never executed.

An operator-requested stop retains the available evidence and prevents subsequent cycles from starting. Closing the application during a test also handles cancellation and evidence storage before exiting. Measured timings describe execution on the desktop system and help compare the behaviour observed across tests.

React and TypeScript for the operator interface

The interface is built with React and divided into three workspaces: Test Bench for connection and execution, Sequences for procedure preparation, and Results for browsing saved runs. Dedicated components handle the command editor, connection state, progress, confirmation dialogs and result details.

Interface logic is organised into separate React hooks for execution, the sequence library and the archive. The active-run hook follows the starting, running, waiting and stopping states, retains the configuration used by the test and discards late events belonging to an earlier run. These choices make the lifecycle of asynchronous operations explicit.

TypeScript defines the structures used for sequences, requests, events and reports, helping keep the code that consumes them consistent. Static type checks work alongside data validation in the native engine. Vite handles frontend development and builds: the same interface code can be explored in a browser preview, while serial execution takes place in the desktop application.

Rust for serial communication and test logic

The software’s core is a Rust engine independent of the interface, organised in the serialcheck-core library. Separate modules handle profile models, serial access, execution, command encoding, response acceptance and result export. This separation allows sequence behaviour to be tested without launching the GUI.

The engine addresses practical communication details: partial reads, fragmented responses, message terminators, packet lengths and receive deadlines. Desktop services run the test separately from the interface and allow only one active execution. Cancellation requests are checked during exchanges and pauses.

The architecture documented in the repository demonstrates Rust development applied to I/O, state management, concurrency and error handling. The procedure logic remains separate from the services that display events and persist data.

Tauri 2: web technologies and native desktop services

Tauri 2 connects the React frontend to Rust services through native commands and event channels. The interface requests the port list, starts or stops a test, and queries saved runs; the backend accesses serial devices and the filesystem and reports progress. These responsibilities are also explicit in the frontend-backend communication module.

The result is a desktop application that uses web technologies for presentation and native services for device operations. Sequences, history and the quick-start guide remain available locally, and startup does not require an Internet connection. This approach suits technical tools that run on the operator’s workstation and communicate directly with hardware.

Traceable results and integration with SLX Test Report

Each run retains the board serial number, operator, station, run identifier, effective configuration, responses and outcomes. The SHA-256 fingerprint of the effective profile identifies the configuration used. The TX/RX log retains transmitted and received data, including text and hexadecimal representations and timing information.

Saved runs can be searched and filtered by date and outcome, with details for each cycle and individual check. Export formats include CSV, JSON and JSONL: CSV contains the results, JSON holds the complete report, and JSONL preserves the event stream. Statuses distinguish passed checks, failed checks, errors, cancellations and skipped controls.

Persistence is part of the execution workflow: events are recorded before being sent to the interface, and a log-writing failure interrupts the test. Final files are completed through temporary-file writes. This behaviour helps keep displayed outcomes connected to the retained evidence.

The CSV is compatible with SLX Test Report, our software for PDF test reports. The two projects cover consecutive steps: Serial Check executes checks and collects results; Test Report imports the CSV, analyses measurements and generates the PDF document. The evidence format is described in the documentation.

Result inspection and evidence export. The illustrated data comes from the Linux integration test using an operating-system virtual serial port.

Automated tests and Windows and Linux packages

The repository includes TypeScript tests with Vitest and Rust tests for profile validation, saved revisions, fragmented responses, binary packets, timeouts, cancellation and CSV export. On Linux, an integration test uses an operating-system pseudo-terminal to exercise the serial driver with a controlled exchange.

The GitHub Actions workflow configures Windows and Linux checks for code analysis, types, formatting, tests, compilation and package verification. It also checks Linux archive startup in Ubuntu 22.04 and Debian 12 environments without preinstalled WebKitGTK.

Distribution also covers application dependencies: the Windows package includes its own WebView2 runtime, and the Linux package includes its application libraries. The operator’s workstation does not need Node.js or Rust installed. The build and packaging documentation describes archive preparation, dependency checks and startup verification.

How to download and try SLX Serial Check

Release v0.3.1 provides x64 packages for Windows 10/11 and Linux with a graphical desktop, Ubuntu 22.04+ or Debian 12+, together with SHA-256 archive checksums. Extract the complete folder, then start the Windows executable or Linux launcher.

For a first test, load an example sequence, adapt it to the board’s commands, choose the serial port and enter the run metadata. The operator guide covers preparation, execution and result inspection. Serial is the implemented transport; TCP/IP, SCPI instruments and multi-board testing are shown in the interface as integrations that can be developed on request.

Source code, screenshots and examples are available in the SLX Serial Check GitHub repository. The project is distributed under the Silicon LogiX Evaluation License for study and evaluation; production or commercial use requires written authorisation.

Custom software for interfaces, devices and testing

SLX Serial Check demonstrates a complete custom software development workflow: React interface design, TypeScript models, a Rust engine, Tauri desktop integration, data management, testing and distribution. These capabilities support technical tools tailored to a company’s processes, from control panels to applications that communicate with devices and existing systems.

Silicon LogiX develops desktop and web applications for businesses and firmware for embedded devices. A project can therefore include both workstation software and the product’s protocol and diagnostics, keeping commands, acceptance criteria and exported data consistent.

Let’s discuss your software project: describe the device or process, intended operating systems, data to retain and operations to automate. We can assess the requirements and first development step together.

Originally published on Silicon LogiX.

SLX Test Report on GitHub: from electronic testing to PDF reports

Marco — Tue, 06 Oct 2026 10:31:55 +0000

SLX Test Report is now available on GitHub. This Silicon LogiX desktop application turns electronic test results into traceable PDF reports. It works with CSV exports from the test bench, without requiring a direct connection to the instruments.

The project addresses a practical need: collecting measurements, checking them against acceptance criteria and keeping them in a document that can be reviewed. The release lets you explore this workflow through the application, source code and supplied examples.

From measurements to reports

The workflow has three steps: import, verify and generate the report. The software compares measurements with acceptance limits, handles functional checks and distinguishes passed, failed and skipped tests from invalid data. Search, filters and an analysis view help identify anomalies and readings close to their limits.

Alongside file import, a visual editor lets you prepare CSV files directly in the application. When a file contains several serial numbers, results are grouped by device, with the option to export one PDF for each unit.

JSON test profiles define the model, revision, expected checks and their limits. They keep acceptance criteria separate from the collected measurements and allow the software to highlight missing required tests, duplicates and tests outside the profile.

Test traceability

Each report includes measurements, units, limits, outcomes and diagnostics, together with the model, serial number, date, operator, station and procedure revision. A report ID identifies the document, while a SHA-256 digest links it to the original CSV and, when used, the test profile.

The PDF is laid out on A4 pages and retains anomalous and incomplete results. An appendix preserves full test names and diagnostic notes when the compact table cannot display them in full.

The technologies behind the project

The project is built with C++17 and Qt 6. Its interface uses Qt Quick, QML and Qt Quick Controls, while C++ modules handle data reading, result evaluation and reporting. This structure separates test logic from the presentation of results, as shown in the project configuration.

CSV and JSON are the exchange formats for measurements and profiles. For PDF generation, the software uses Qt's QPdfWriter and QPainter: tables, summaries and graphics are composed directly by the application. The output file is committed only after generation has finished.

CMake coordinates compilation and CTest runs the tests, which cover CSV handling, profiles, filters and the reporting workflow. The repository also includes a GitHub Actions workflow to build the project and run checks on Windows.

How to try it

Release v0.5.2 includes a Windows package that you can extract and run, with example data to explore the workflow and produce a first report. The GitHub repository provides source code, screenshots and documentation, including instructions for building the application.

The project is distributed under the Silicon LogiX Evaluation License, which permits study and evaluation; commercial use requires written permission.

Custom software for testing and reporting

Need an application to manage test data, automate reports or connect software you already use? Silicon LogiX provides custom software development for businesses: desktop and web applications, data analysis tools and integrations with existing systems.

Contact us about your software project: describe the process you want to improve, the data available and the functions you need. Together, we can assess the requirements and the first step towards implementation.

Originally published on Silicon LogiX.

ESP32 without a board: firmware tests with Zephyr and QEMU

Marco — Tue, 29 Sep 2026 12:52:46 +0000

The board has not arrived, but firmware development needs to move forward. Perhaps the PCB is being revised, several engineers share the first prototypes, or a regression is difficult to isolate. Running selected checks on a development computer helps separate software problems from hardware issues.

Zephyr and Espressif’s QEMU fork provide a way to execute firmware for supported ESP32 targets in an emulated environment. The value is earlier, repeatable verification. To interpret the results correctly, engineers need to understand which parts of the device are modeled and which tests still require real hardware.

The starting point is Espressif’s guide published on September 15, 2026, covering Zephyr startup and debugging with QEMU. For product development, the useful idea is to establish an observable software baseline before validating it on the physical board.

Key points

QEMU executes firmware using models of the processor and supported peripherals.
These targets require Espressif’s fork; a generic QEMU installation is not sufficient.
A passing emulation test does not measure radio performance, power consumption or electrical reliability.

How ESP32 emulation with Zephyr and QEMU works

Three components have distinct roles. Zephyr provides the operating system and application environment. The toolchain compiles sources for the target architecture. QEMU executes that code against a software model of the machine on the development computer.

A debugger can pause execution, inspect memory and registers, and follow a program path. The connection uses the remote debugging mechanism described in the QEMU GDB documentation. This emulated debugging session does not need a physical probe attached to a board.

The firmware path in the emulated environment. GDB uses the ELF file for program symbols and information; the physical board belongs to a separate verification layer.

This distinction determines what a result means. Reaching an expected execution point verifies one path in that configuration. It does not establish how a power rail will respond to a current spike or how long a transmission will take at the installation site.

Supported ESP32 targets: what to check first

The Zephyr documentation for Espressif QEMU lists the following combinations. Check that the required board variant exists in your Zephyr revision before configuring the build.

Targets in the documented workflow; support also depends on the emulator build.

SoC	Architecture	QEMU executable
ESP32	Xtensa	`qemu-system-xtensa`
ESP32-S3	Xtensa	`qemu-system-xtensa`
ESP32-C3	RISC-V	`qemu-system-riscv32`
ESP32-C6	RISC-V	`qemu-system-riscv32` with the C6 machine available

ESP32-C6 needs an additional check: the prebuilt esp-develop-9.2.2-20260417 release referenced by the documentation does not include that machine; the documented route is to build from esp-develop. For later packages, inspect the official releases and the machines listed by the installed executable.

What emulation can verify, and what remains outside it

The Espressif QEMU feature matrix identifies modeled peripherals. Coverage differs between SoCs; the ESP32 family name alone does not establish compatibility. Wi-Fi and Bluetooth are not emulated, and many external sensor and device interfaces are also outside the model.

The matrix also describes additional virtual peripherals for particular uses, including emulated Ethernet. A virtual network path does not validate the product’s Wi-Fi connection: association, antenna behavior, interference and coverage need their own tests.

Choose tests by asking a precise question. “Does the parser reject an incomplete message?” differs from “Does the sensor respond correctly on the bus?” Controlled inputs can exercise the first case. The second also depends on the driver, peripheral model and, ultimately, the physical connection.

A first ESP32-C3 boot: where to begin

Start with a working Zephyr workspace, SDK, Espressif dependencies and a revision containing the required QEMU target. The Zephyr getting started guide covers environment setup. Install the emulator separately from Espressif’s releases.

Before building, check that the executable selected by your shell knows the required machine:

qemu-system-riscv32 -machine help

The list should include esp32c3. If it does not, check the executable path and version. A compiler and an emulator serve different purposes: installing the former does not add a chip model to the latter.

The following is a documentation-based reference sequence, run from the workspace root containing zephyr/. It is not presented as a laboratory measurement:

west build \
  -b esp32c3_devkitc/esp32c3/qemu \
  zephyr/samples/hello_world \
  -d build-qemu-c3 --no-sysbuild --pristine

west build -d build-qemu-c3 -t run

The /qemu variant selects the emulation configuration. The initial check is to observe startup and the sample’s message. That establishes a starting point, rather than validating a complete application.

The west build documentation explains build directories and --pristine, which recreates the contents of the build directory. Use a dedicated folder and keep source files and documents elsewhere. A clean build helps avoid stale settings when changing targets or configurations.

For debugging, Espressif’s workflow uses the debugserver target and GDB for the correct architecture. The zephyr.elf file must match the running build: symbols from another compilation can make an investigation misleading.

A practical design example: verifying alarm handling

Consider a device that reads a temperature, activates an alarm above a threshold and clears it below a second threshold. Hysteresis prevents repeated switching near the limit. Several software decisions can be checked before introducing the sensor.

Separate measurement acquisition from the function that updates the alarm state. A test supplies a known sequence: a normal value, a threshold crossing, an intermediate fluctuation and a return below the clearing threshold. At each step, compare the actual state with the expected state. Then add invalid readings, stale measurements and inconsistent configuration.

Synthetic inputs verify the logic that receives them. They do not demonstrate that an I2C sensor works inside QEMU. This separation makes it possible to identify a hysteresis bug independently of wiring. Once the board arrives, testing also covers acquisition, timing and driver error handling.

A useful report names the verified requirement. “Alarm active after a valid reading above the threshold” communicates evidence; “test OK” alone does not explain coverage or limitations. Repeating the sequence after adding a new sensor helps detect regressions in the application rules.

Logic tests, QEMU and physical hardware: complementary layers

A product needs different checks with specific objectives. Logic tests investigate decisions. Emulation exercises parts of firmware integration. Device tests establish properties that exist only in physical hardware and its operating environment.

Each layer answers a different question. Passing a QEMU test adds firmware evidence but does not replace validation of the complete product.

Zephyr provides Ztest for organizing tests and assertions. Its native_sim platform also runs Zephyr applications compiled for the host. That is a different environment from ESP32 emulation and can be useful for software logic and integration that do not require a model of that SoC.

For an automated pipeline, record the code revision, configuration, tool versions and expected outcome for every run. A job should distinguish an application failure, a timeout and an environment startup problem. Otherwise, process termination can be mistaken for a successful test.

Start with a few checks tied to costly defects: invalid configuration, incomplete messages, a full queue or recovery after an error. Evaluate the benefit by tracking which defects are caught earlier and which still need reproduction on the board. There is no universal percentage of time saved.

ESP32, Zephyr and QEMU: frequently asked questions

Can QEMU verify ESP32 Wi-Fi and Bluetooth?

Those radios are not emulated in the workflow described here. Their operation and performance require real hardware. A virtual network interface does not constitute a radio test.

Can I reuse the production configuration automatically?

Check its peripheral dependencies first. Applications that initialize unmodeled components may need a test configuration or replaceable interfaces. Document the differences from production firmware.

Is a passing QEMU test enough to release firmware?

It is one part of the evidence. Release criteria must address the product, including board integration, error handling and the intended operating conditions.

Making verification part of firmware development

A practical first step is to identify a critical software module and the behavior that must remain stable. Build repeatable tests around those requirements, choose where to run them, and connect the results to device-level verification.

Silicon LogiX provides ESP32 firmware development, system integration and firmware debugging support. To discuss verification for your product, describe the device, the current software and the problem you need to solve.

Technical references checked on September 29, 2026. Diagrams are original explanatory illustrations; the alarm scenario is a design example. Check commands and compatibility against your installed versions.

Originally published on Silicon LogiX.

Satellite IoT: keeping sensors connected beyond cellular coverage

Marco — Mon, 21 Sep 2026 12:46:16 +0000

A sensor can keep taking measurements after cellular coverage disappears. Without an available connection, however, those readings and alerts never reach the person who needs to act. This happens on farmland far from towns, at an isolated storage tank, or along a vehicle’s route through areas without mobile service. The device remains powered, but the last update on the monitoring platform gets older and older.

Satellite IoT offers a practical option: compatible devices can use a satellite link to transmit data beyond the reach of cellular networks. For a business, this opens up monitoring opportunities at sites that have been difficult to connect, potentially reducing the need for manual visits. The outcome depends on the complete system: sensors, antenna, firmware, power supply, connectivity service and the software receiving the messages.

A sign of this market’s development came in Nordic Semiconductor’s announcement on August 6, 2026: the LooUQ MTC2-N9151 embedded modem, based on the nRF9151, received Skylo certification for NTN satellite connectivity. It provides an integration platform that combines cellular and satellite communication and simplifies product development.

At a glance

A satellite link can carry readings and alerts beyond cellular coverage, with compatible hardware and an enabled service.
Agriculture, isolated infrastructure and logistics are applications in which to assess sensors with hybrid connectivity.
Firmware, energy consumption, antenna design and data handling determine how useful and sustainable the solution will be in the field.

When cellular coverage is missing, the problem becomes operational

Consider a pump supplying an irrigation system. A sensor detects an abnormal pressure drop, but the modem cannot connect. The alert remains on the device while the operator continues to see an earlier reading. If the platform does not clearly distinguish recent data from stale data, a communication failure can even look like normal operation.

Storing readings locally allows the history to be recovered when connectivity returns. That is essential, but responding while a fault is occurring also requires an available communication path. This is where a second connection option becomes valuable: it increases the opportunities for useful information to reach its destination.

The assessment must cover the network the device will actually use. Signal bars on a smartphone do not establish whether a sensor can access the intended cellular service with its particular modem, SIM and installation.

How satellite IoT works with NTN networks

NTN stands for Non-Terrestrial Network. In the solution discussed here, the device communicates by radio with a satellite; the traffic then passes through ground infrastructure and the operator’s network to the receiving service. Skylo’s network integration documentation describes an architecture that complements cellular networks using existing geostationary satellites.

A product can therefore be designed with two paths: the cellular network when available, and a satellite connection under supported conditions. Switching depends on compatibility between the modem, firmware, antenna and operator service. The application must still handle connection times, failed transmissions and periods when neither path is usable.

Two possible telemetry paths. The satellite relays data towards ground infrastructure, and the backend makes it available to the dashboard. Conceptual diagram, not to scale: the NTN path requires service coverage, a suitable radio path and an enabled device. If both connections are unavailable, firmware stores readings locally within the available memory capacity.

NB-NTN provides narrowband connectivity for compact messages such as a reading, a status update or a position. Product design should start with the information that is essential and the time within which it is needed. Sending a meaningful event can be far more useful than trying to transmit every sensor sample over satellite.

What the LooUQ modem based on nRF9151 changes

The Nordic nRF9151 is a System-in-Package integrating an application processor and a modem supporting LTE-M, NB-IoT and NB-NTN. LooUQ uses it as the foundation of its MTC2-N9151, designed for integration into a device. Developers can start evaluating an existing communication platform and focus their work on the product and its application.

Certification of the underlying platform reduces some of the integration and verification work. The finished product still needs to be assessed in its actual configuration, including its enclosure, antenna and firmware. Skylo distinguishes between chipset, module and device certification: the applicable process should be agreed before planning production.

The Remsight example: water monitoring in the American West

Nordic’s announcement cites Remsight, which uses the MTC2-N9151 in its HydroProxy platform to monitor irrigation infrastructure in the American West. Its solar-powered sensors operate in locations where cellular coverage is unreliable.

The system described by Remsight combines field measurements, hybrid telemetry and map-based dashboards to support water managers. The practical benefit is easy to understand: observing distributed infrastructure without physically visiting every measurement point.

Applications: agriculture, remote infrastructure and logistics

Agriculture and irrigation

Reservoir level, pipe flow, irrigation pressure and pump status remain useful measurements even when a field is far from a cell tower. An agricultural system can be designed to send key readings periodically and report threshold crossings, taking seasonality and the required operating autonomy into account.

Silicon LogiX can work on sensor acquisition, firmware development and the logic that decides when to transmit. Monitoring software can then associate readings with a site and its history, helping operators identify unusual consumption or conditions that require investigation.

Storage tanks, pumps and energy infrastructure

For an isolated tank, knowing the level and its trend may be sufficient. A pumping station may need operating hours, temperature and alarm status. Distributed energy installations and equipment in poorly served areas can also benefit from sending essential diagnostics, provided the site and service support the connection.

We can contribute by integrating existing electronics, processing data locally and transferring useful information to the backend. Machine protection and responses requiring guaranteed timing must remain local; the remote link provides visibility and maintenance support.

Logistics and asset tracking

A mobile asset may pass through areas with intermittent coverage. A hybrid tracker can be designed to send location, temperature or selected events according to the available network. Two functions must be distinguished: GNSS determines the position, while cellular or satellite connectivity carries it to the platform.

Silicon LogiX can develop acquisition logic, event storage and integration with business systems. Antenna placement is critical: a device inside a metal container requires a different assessment from a tracker mounted outside. Countries and service availability along the route also need to be checked.

Environmental monitoring and temporary installations

Weather stations, river-level measurements and instruments at isolated construction sites are further scenarios to assess. Feasibility depends on data volume, access to the installation and available energy. We can contribute through hardware and software prototyping, data acquisition and the diagnostic tools needed to understand the system’s behaviour during field trials.

Firmware must handle hours without a connection

Adding a compatible modem is one step in the project. A reliable product also needs a policy for what happens after each measurement: which data to retain, which events take priority, when to attempt a connection and how long to keep retrying. These are application decisions based on operational requirements.

One possible strategy uses timestamped readings, a persistent queue and message identifiers. The backend can then recognise retransmissions and delayed data. The queue needs a defined capacity and a policy for handling a full buffer while preserving the events most useful to the process.

The dashboard must also make this distinction visible. “Last received value” and “current state” are not always the same thing. Showing measurement time, receipt time and prolonged gaps between updates helps users interpret an alert correctly. This is a central consideration when developing dashboards for operational monitoring.

Power consumption: validate the complete operating cycle

At a remote site, replacing a battery may take longer than collecting a sensor reading. Evaluating autonomy requires measuring a representative cycle: acquisition, processing, network search, attachment, transmission and any subsequent retries. Low sleep current alone does not describe the behaviour of the complete device.

In our firmware work, we can set separate acquisition and reporting intervals, combine several readings into a message and limit repeated network searches. The objective is to keep important information available within a measured energy budget. If the design includes a solar panel, sizing must also account for energy storage, seasons and periods with limited sunlight.

Coverage, antennas and costs: what to check before prototyping

The first check concerns the installation site. The official Skylo coverage map is a starting point, but availability must be confirmed with the provider for the country, service and device selected. A project in Italy needs that specific assessment; a deployment in the United States does not establish feasibility at another location.

The second check concerns the antenna and its view towards the satellite. Buildings, terrain, vegetation and enclosures can obstruct the radio path. A sensor in an underground chamber or a metal cabinet may require an external antenna in a suitable position. Tests should use the intended mounting arrangement because orientation and the surroundings affect performance.

Cost includes the connectivity service as well as hardware. Skylo states that SIMs and data plans are generally available through operator partners. A quotation should reflect the intended usage: device count, messages, data volume and contract terms. Installation, testing, certification and maintenance also belong in the comparison.

Finally, measure the time between an event and its receipt. Periodic readings may tolerate a substantial delay, while an urgent alert has different requirements. Test criteria should include delivered messages, delivery times, energy consumed and behaviour when both connections are unavailable.

Satellite IoT frequently asked questions

Can a sensor transmit without cellular coverage?

Yes, with hardware and firmware compatible with a satellite network, an active service and suitable radio conditions. Having a cellular modem alone does not guarantee that capability.

Does satellite connectivity work indoors or underground?

Feasibility depends on the radio path and installation. Shielded locations need an assessment of how to place the antenna in a suitable position. Testing at the site is part of the project.

Is it suitable for video, remote access or large updates?

The NB-NTN connection discussed here should be sized for small data exchanges. Video, interactive sessions and large transfers require a different assessment. Firmware updates also need a strategy consistent with the available connection.

Can an existing device be adapted?

It can be assessed by checking interfaces, power supply, antenna space and access to the firmware. An initial review can establish whether to integrate a modem, add a gateway or change the device architecture.

How Silicon LogiX can turn the requirement into a project

The starting point is to describe what becomes invisible when the signal disappears: a reading, a fault, an asset’s location or the status of an installation. We can then define reporting frequency, acceptable delay, autonomy and installation conditions, comparing satellite connectivity with the other options available for that setting.

Silicon LogiX can support firmware development, sensor and modem integration, power optimisation and prototype testing. On the software side, we can build IoT platforms and device management systems, backends, historical data storage and dashboards with notifications and diagnostics. The development path depends on the hardware, documentation and services available to the project.

A useful first trial connects a representative sensor to the platform and measures its behaviour at the intended site. The result supports a decision on whether to proceed, what needs adjustment and which costs to consider before deploying more devices.

Official references

Nordic Semiconductor, August 6, 2026 announcement: LooUQ modem certification and the Remsight application.
Nordic nRF9151 and LooUQ MTC2-N9151: platforms and supported connectivity.
Remsight: sensors, connectivity and tools for water management.
Skylo, network architecture and integration.
Skylo, geographical coverage and FAQs on services, SIMs and certification.

Does your installation stop reporting when the signal disappears?

Tell us where it is, which readings or alerts you need to receive and how the device is powered. We can use these details to assess connectivity, firmware and monitoring, and define an initial feasibility trial.

Discuss your IoT project beyond cellular coverage

Originally published on Silicon LogiX.

Industrial machine vision: four Ethernet cameras with Microchip and NVIDIA

Marco — Mon, 07 Sep 2026 15:43:10 +0000

Adding machine vision to an industrial machine means building a reliable chain between what happens on the part and the control system’s decision. Images must show the relevant detail, arrive in time, be processed, and remain associated with the correct component. Once a system uses two, four or more cameras, connectivity, synchronisation and data management become as important as the recognition algorithm itself.

A recent US product release makes this topic especially timely. On 11 August 2026, Microchip announced Revision 2.0 of its PolarFire FPGA Ethernet Sensor Bridge: a board designed to connect sensors and cameras to NVIDIA processing platforms over Ethernet using Holoscan Sensor Bridge technology.

Microchip states that the new revision supports up to four cameras, reduces the form factor by 60% compared with the first generation, and is offered at a lower price. For machine builders, the relevant opportunity is a multi-camera acquisition path on which to evaluate quality inspection, assembly verification and robotic-vision functions.

The starting question is practical: which inspection do we want to automate, and which images are needed to perform it at the speed of the machine? The scenarios and calculations below are design-assessment examples. Product characteristics come from the linked official sources.

At a glance

The new Microchip bridge provides up to four camera inputs and two 10GbE SFP+ ports.
In the architecture described here, the FPGA acquires and transfers data while the NVIDIA platform runs vision and AI processing.
Resolution, pixel format and frame rate determine the required bandwidth.
Industrial results also depend on lighting, synchronisation and integration with the machine controller.
The assessment must cover the actual compatible hardware and software versions.

What changes with the PolarFire Ethernet Sensor Bridge Rev 2.0

The MPF200-ETH-SENSOR-BRIDGE-R2 product page describes a platform based on a PolarFire MPF200T FPGA, with a camera adapter and expansion interfaces. This separates signal acquisition from the computer that processes it while keeping Ethernet as the link between the two.

Element	Stated characteristic	Design implication
Video inputs	Four four-lane MIPI CSI-2 D-PHY receive interfaces via the Jetson Adapter Card.	A hardware basis for capturing images from several viewpoints.
Host link	Two 10GbE SFP+ Ethernet ports.	Flows, physical links and the host’s receiving capacity still need to be sized.
Logic and memory	PolarFire MPF200T FPGA and 2GB DDR4.	Resources for the acquisition and transport design.
Expansion	FMC HPC and PMOD connectors.	Additional interfaces can be developed after checking the required logic and software.
Power	USB-C and 12V DC input support.	Options to validate against the installed configuration and peripherals.

The launch announcement also mentions on-board optical latency measurement circuitry and available design collateral. These can accelerate a bench evaluation, but the performance of the whole machine still has to be measured in the application configuration.

From cameras to AI: the architecture

NVIDIA’s documentation describes a path in which the FPGA acquires sensor data and sends it to the host through UDP over Ethernet. Software receives those streams and inserts them into a Holoscan pipeline, which can include image conversion, preprocessing, inference and visualisation.

cameras → FPGA acquisition → Ethernet → NVIDIA processing → vision result → machine control

Responsibilities must be explicit at every step. The bridge has to transfer usable data; the vision software has to produce a result; the controller interface has to state which part the result belongs to and whether it is still valid. The application design connects those elements, including cases in which an image is missing or arrives too late.

The receiving method depends on the host. NVIDIA documents accelerated configurations with ConnectX interfaces that can place data directly in GPU memory, as well as Linux-socket configurations such as a Jetson AGX Orin Developer Kit without an RDMA NIC. The computer, network interface and software stack therefore need to be checked as one configuration; figures from one setup cannot simply be extended to every other host.

Why multiple cameras change the machine design

Consider a station inspecting an assembled component. A top view may check the presence of primary parts; a side view may help verify an insertion; another view may read a label. Splitting checks across cameras can be useful when one viewpoint leaves hidden areas or does not provide enough detail.

It also adds information that must be coordinated. The software must know whether the images belong to the same part, which inspection recipe applies and how the outcomes are combined. If one camera returns a valid reading while another fails to acquire, the machine must handle an incomplete state. Treating it as an automatically conforming product would create a process error.

For this reason, a technical assessment should first draw the inspection sequence: part entry, identification, acquisitions, processing, decision and confirmation of the action. That sequence also makes clear whether four views are really needed, whether two well-positioned cameras are enough, or whether the part should be presented differently.

Size video bandwidth before choosing the platform

For an uncompressed stream, a first estimate of pixel payload is obtained by multiplying the number of cameras, resolution, frames per second and the effective bits per pixel carried by the link. The result immediately exposes configurations that need more capacity than is available.

pixel bandwidth = number of cameras × width × height × frames/s × bits/pixel

Theoretical examples for image payload only, before protocol overhead and operating margin.

Illustrative configuration	Transported format	Pixel bandwidth
One camera, 1,920 × 1,080 pixels, 30fps.	8 bits per pixel.	About 0.50Gbit/s.
Four cameras, 1,920 × 1,080 pixels, 30fps each.	8 bits per pixel.	About 1.99Gbit/s.
Four cameras, 1,920 × 1,080 pixels, 60fps each.	24-bit RGB.	About 11.94Gbit/s.
Four cameras, 3,840 × 2,160 pixels, 60fps each.	8 bits per pixel.	About 15.93Gbit/s.

These are illustrative calculations, not board benchmarks. Link sizing also needs packet headers, metadata, possible format padding and margin. The location of conversion matters too: Bayer data sent at 8 bits per pixel may become a three-channel RGB image in the computer, with a different memory requirement.

The final example already exceeds 10Gbit/s for pixels alone. Two ports do not by themselves state the usable system capacity: the design must show how sources are distributed and how the host receives them. Cropping to the useful region or acquiring a frame rate consistent with the inspection may reduce traffic, but only if the defect detail and required time coverage are retained.

Latency, synchronisation and the time available to decide

Bandwidth tells us how much data can pass; latency tells us how long it takes for an observed event to yield an available result. A production line may need both: it must handle a stream of successive parts and deliver each decision before the relevant component reaches the reject or selection point.

The NVIDIA latency guide distinguishes transfer of a frame to the bridge, reception on the computer and subsequent processing stages. Metadata includes frame numbers and timestamps that help observe those steps. Times shown in the examples apply to specific configurations.

An industrial implementation must additionally account for camera exposure, model preparation and result exchange with the controller. Some stages may overlap, so total time must be measured on the real path. It is useful to record latency distribution, observed peaks and decisions that miss the deadline—not only an average value.

The useful requirement is to deliver a valid result for the correct part to the controller within the time available in the process.

Synchronisation needs a separate check. NVIDIA’s PTP application note describes timestamp alignment between bridge and host and synchronised camera VSYNC. Aligning exposures still requires sensors, links and logic configured for that purpose. In a system with moving objects, this helps prevent views captured at different times from being interpreted as simultaneous. For cameras at successive stations, correctly associating images with the part identifier may matter even more.

Image quality starts with optics and lighting

Before selecting compute performance, verify that the defect is visible. A reflective surface, a shadowed edge or a part moving during exposure can make the inspection unstable at the acquisition stage.

Basler’s image-quality documentation notes that a longer exposure increases brightness but may increase motion blur and reduce acquisition rate; increasing gain also amplifies noise. These trade-offs have to be addressed together with lighting and lens choice.

An initial trial should use real parts, including defects that are difficult to distinguish, and reproduce the distance, orientation and machine speed. The smallest feature to be recognised must occupy enough pixels for the chosen method. Where the check depends on position or dimensions, calibration and mounting stability must also be evaluated.

When to use AI and when to assess classical vision

The acquisition platform can also be useful for work that does not require a neural network. Hole presence, edge alignment or code reading can initially be addressed with classical machine-vision tools when optical conditions give sufficiently stable results.

For defects with variable shapes or classifications that are difficult to express as rules, an AI model is an option to compare experimentally. Use the same samples and goals in that comparison: missed defects, false rejects, processing time and cases that require a human review. Reserve images from different parts and lots for final validation, rather than testing only images already seen during development.

How this bridge compares with other vision architectures

Microchip’s announcement adds an option to an existing set of architectures. The comparison should also consider GigE Vision, which defines an image-transfer and interoperability interface over Ethernet. Sharing the same transport medium does not automatically make application interfaces equivalent.

Architecture to assess	Where it can fit	Central check
Cameras connected directly to the embedded computer.	A compact product with sensors close to the compute system.	Available interfaces, physical connections, drivers and simultaneous capture.
GigE Vision industrial cameras.	A machine that can use complete cameras and the industrial-vision ecosystem.	Camera features, host compatibility, network and synchronisation.
FPGA sensor bridge with Holoscan Sensor Bridge.	A project requiring customised acquisition and NVIDIA-pipeline integration.	Sensor support, FPGA design, data transport and software versions.

Total cost, space, cabling, heat dissipation and maintenance work also belong in the comparison. A more flexible solution is valuable when the product genuinely needs that flexibility; otherwise a complete vision subsystem may reduce integration effort.

Software checks before starting the prototype

The official Microchip application note includes examples for video streaming, processing and camera setup. It is therefore a useful starting point for proving acquisition before developing the machine-specific function.

At the time of review on 7 September 2026, the same documentation notes that the NVIDIA repository does not currently support MPF200-ETH-SENSOR-BRIDGE-R2 for Holoscan Sensor Bridge SDK 2.7.0 and points to a dedicated SDK branch in the interim. That detail should be checked again when preparing the bench and selecting the versions to maintain.

To make development repeatable, record the board revision, loaded FPGA configuration, sensors, drivers and software packages. An update needs to be verified across the whole chain: received images, recognition result, timing and controller communication. The application should also distinguish a nonconforming part from a measurement that is unavailable after a stream interruption, peripheral restart or queue saturation.

An illustrative assembly-line inspection

Imagine a line carrying small mechanical assemblies. The business wants to check a gasket, connector insertion and a label. This is an illustrative scenario on which to set requirements and measurements.

Four viewpoints may be an initial hypothesis: three for the individual checks and one for an overall view. The trial may show that fewer cameras are sufficient, or that one inspection needs a different lens. The bridge is a possible basis for that assessment.

Assume a conveyor running at 2m/s and a 20cm distance between the observation point and the reject point. Transit time is 100ms. If actuator response takes 30ms and 20ms are reserved as margin, 50ms remain for acquisition, processing and command delivery.

time available for vision and communication = (0.20m ÷ 2m/s) − 30ms − 20ms = 50ms

Those numbers define a hypothetical requirement; the bench must establish whether the selected configuration meets it. The controller interface can associate every inspection with an identifier, an outcome, a validity state and a timestamp. A result arriving after its deadline must not be applied to the next component.

From proof of concept to a production-ready function

An effective assessment produces evidence for a decision. Before testing, define the required inspections, available samples, line speed and acceptance criteria. Then collect images, compare processing options and measure execution on the selected hardware.

inspection requirement → representative images → architecture choice → prototype → line measurements → product integration

The output should include the proposed architecture, results on samples, observed timing, conditions that make a reading invalid and the work still required. Longer-running tests then help assess temperature, stability and recovery after expected interruptions.

Frequently asked questions

Does the Microchip board run AI recognition directly?

In the path described here, the bridge acquires and transports data to the NVIDIA system. The recognition model runs on the connected processing platform, so acquisition and inference must be sized together.

Do four inputs guarantee four 4K cameras at 60fps?

No. Simultaneous operation depends on pixel format, sensor configuration, FPGA design, flow distribution and host capacity. The bandwidth examples show why the number of connectors alone does not describe overall performance.

Is a cloud connection required to inspect parts?

No. The processing path can be designed to run locally on the machine. Sending results to a server, remote management and archival are separate functions to define according to operating needs.

Can any MIPI CSI-2 camera be connected?

Electrical connections, power, data format and configuration software must be checked. Support for a specific sensor has to be confirmed in the adopted FPGA design and software chain.

Can this be used to retrofit an existing machine?

It can be assessed for a retrofit after checking space for imaging, lighting, power, cabling and result exchange with the controller. A trial with real parts clarifies feasibility before final integration.

What determines the cost of an initial assessment?

The required inspection, sample availability and acquisition and integration effort. The defect to recognise, part dimensions, speed and existing hardware are the most useful inputs for defining a focused activity and a reasoned estimate.

How Silicon LogiX can support the assessment

Silicon LogiX supports companies and technical teams in defining embedded-vision functions, starting from the problem to solve and the machine constraints. Initial work can include analysis of the available images, comparison of architectures and definition of a measurable proof of concept.

The work can continue with on-device AI and machine learning, embedded Linux integration, FPGA logic and embedded firmware for acquisition and communication. Diagnostic software, HMIs and dashboards can complete the system when operators and service teams need them.

Conclusion

Microchip’s new bridge is a concrete starting point for assessing multi-camera acquisition and NVIDIA processing. For a machine builder, the opportunity is to develop an inspection function that matches its process, using documented hardware and software as a foundation.

The result depends on the whole chain: visible detail, correctly associated images, sized transport, verified recognition and a decision delivered in time. Taking those requirements to a bench test turns a technology announcement into a reasoned product decision.

Official references

Want to add visual inspection to your machine or product?

Describe the defect or component to recognise, the operating speed and the hardware already in place. Representative images and a short description of the operating sequence help establish the first technical discussion.

Request an assessment for your machine-vision project

Canonical source: Industrial machine vision: four Ethernet cameras with Microchip and NVIDIA.

Building an Industrial HMI and Edge Controller on STM32 with FreeRTOS and Modbus TCP

Marco — Sun, 30 Aug 2026 13:19:23 +0000

Building an Industrial HMI and Edge Controller on STM32 with FreeRTOS and Modbus TCP

Industrial control demos are often judged by the screen. The more useful question is whether the firmware, HMI and simulated process all explain the same state transition.

SLX FlowControl is a demonstrator built on an STM32H750B-DK. It combines a FreeRTOS control task, an LVGL touch HMI, a Modbus TCP/IP server and a Factory I/O Fill Tank digital twin. The goal is to make behaviour testable before a physical machine is connected.

The problem behind the demo

A buffer tank must accept incoming fluid, supply downstream demand and retain an operating reserve around a target level. That sounds simple until commands overlap, sensors are missing at startup, data stops arriving or an operator needs to understand why the process will not restart.

The design therefore treats field demand, automatic control, conflicts, alarms and recovery as explicit machine states. It does not leave them as special cases hidden inside a main loop.

Architecture at a glance

A periodic FreeRTOS control task runs every 100 ms.
Factory I/O acts as a Modbus TCP client; the STM32 acts as the server.
The Modbus map separates measurements, field commands, valve outputs and diagnostics.
LVGL exposes the same state through dashboard, process view, controls, session recipes, alarms, setup and diagnostics.
Fill and discharge are mutually exclusive. A simultaneous request becomes an explicit conflict, not an ambiguous valve command.

A sequence worth validating early

The most useful part of the digital twin is not the animation. It is the ability to test a complete operational sequence:

The controller starts in STOPPED. Before the first Modbus exchange, the HMI reports sensors as pending rather than raising a misleading blocking alarm.
A field request for fill or discharge is reflected by the virtual valve, signal tower, firmware state and HMI.
Two seconds after both commands are released, AUTO moves the level back toward the target with a ±1% deadband.
After another two seconds with both valves closed, field commands are accepted again.
When control is requested, communication loss or stale sensor data drives outputs to a safe state within 1.5 seconds.

That sequence gives firmware, commissioning and product teams a common object to review before final I/O hardware and plant testing exist.

Watch the short demonstration

Watch the SLX FlowControl short demo on YouTube: Factory I/O digital twin, touch HMI and STM32 edge-control logic shown together.

HMI is part of the control design

The HMI is designed to explain what the controller is doing, not only to display a red alarm. Alarm pages carry severity, first-out context, cause, required action and a guided reset path. Acknowledge cannot force a restart while the underlying cause is still present.

The same principle applies to diagnostics: network state, sensor freshness and configuration validity need to be visible so an operator can distinguish waiting, inhibited and faulted behaviour.

What the demonstrator does not claim

SLX FlowControl is validated in simulation and on target firmware. It is not a substitute for risk analysis, hardwired safety functions, physical-process validation, authenticated access, OT firewalls or persistent production logging.

Modbus TCP in this build does not add authentication or encryption. A production machine needs network segmentation and security controls appropriate to its operational context.

Takeaway

A digital twin can be a practical engineering tool when it lets a team validate real firmware behaviour, operator feedback and failure paths before field integration. The value is not a prettier demo. It is a clearer contract between process, controller and operator.

Read the complete case study, including visuals and technical context: SLX FlowControl: Industrial HMI and Edge Control on STM32.

CAN XL: what changes for robots, HMIs and industrial machines

Marco — Tue, 25 Aug 2026 11:47:47 +0000

For decades, CAN has been one of the most dependable languages used by machines. Controllers, sensors, actuators, operator panels and safety modules can exchange information with predictable priority and the robustness required by industrial and automotive environments. Today, however, a machine is no longer sending only a few commands and states: it has to handle richer diagnostics, high-frequency feedback, more capable HMIs, updates, data from multiple sensors and distributed software components.

In this context, CAN XL is not simply faster CAN. It is the third generation of the CAN protocol, designed to increase the amount of data a network can carry without giving up the principles that made CAN so widespread in control systems.

The subject has become especially timely after Texas Instruments announced the TCAN6062, described as the first commercially available CAN XL transceiver, on August 12, 2026. It moves CAN XL from standardisation into the practical availability of hardware for industrial products, robots, HMI systems and next-generation control architectures.

For a team building a machine, an embedded device or a product with several electronic nodes, the question is not “should we replace CAN?” A more useful question is: will our communication architecture still be adequate when data, software functions, sensors and diagnostic requirements grow?

At a glance

CAN XL is the third generation of the CAN protocol and is standardised in the ISO 11898:2024 family.
It supports data fields up to 2,048 bytes and configurable data rates up to 20 Mbit/s, depending on the physical network design.
TI's first commercial CAN XL transceiver makes the technology practical to evaluate for new industrial products.
It is not an automatic replacement for CAN FD or Ethernet: it is relevant when a product needs more data while retaining priority, determinism and continuity with the CAN world.

From classic CAN to CAN XL: the evolution is about more than speed

Classic CAN was created for control networks in which short, high-priority messages must arrive reliably. CAN FD has already extended that model by increasing the data field and making it easier to support richer firmware, diagnostics and extra functions.

CAN XL takes a further step. According to CAN in Automation, the international association behind the CAN ecosystem, the protocol can use data fields of up to 2,048 bytes and configurable throughput up to 20 Mbit/s. The association identifies CAN XL as the third CAN generation, alongside classic CAN and CAN FD, in ISO 11898-1:2024.

Technology	Typical role	Data-field limit
Classic CAN	Commands, status and essential control signals.	8 bytes per frame.
CAN FD	Networks with more diagnostics, application data and a need for greater efficiency.	64 bytes per frame.
CAN XL	Architectures with larger data flows, robotics, advanced HMIs and integration with IP networks.	Up to 2,048 bytes per frame.

The difference has an important practical effect. When information has to be fragmented across many CAN FD messages, it does not only take longer to transmit: bus load rises, firmware becomes more complex, there are more cases to verify and predictable response times are harder to preserve under load.

CAN XL lets engineers work with larger packets while retaining CAN arbitration. Important messages can still receive priority, while the network has more room for diagnostics, parameters, sensor data and updates.

Why robots, HMIs and industrial machines are creating a new network problem

A modern industrial machine is no longer a linear chain in which a PLC sends one command and an actuator returns one state. It is increasingly a distributed system: drives, I/O modules, HMI panels, safety controllers, gateways, cameras, smart sensors and support software must coexist without turning the network into a bottleneck.

In industrial robots, for example, motion control requires priority and predictable timing. At the same time, the system may need to collect encoder data, torque-sensor measurements, temperatures, drive diagnostics and information useful for maintenance. In HMIs, the amount of configuration, recipes, service logs, process parameters and operator-facing information also keeps increasing.

The need is not created by artificial intelligence or cloud connectivity alone. Even when every data point stays on-site, edge computing brings more processing close to the machine. Local nodes then need to exchange richer information while preserving a reliable control foundation that can be understood and supported throughout the product lifecycle.

Texas Instruments specifically cites humanoid robots, industrial robots and HMI systems among the intended applications for its new transceiver. The value of that announcement is therefore not limited to a single component: it signals that higher-capacity CAN architectures are becoming a concrete option beyond a purely theoretical protocol discussion.

Why the first commercial hardware changes the time to evaluate CAN XL

CAN XL did not start in August 2026. Its protocol and physical layer were already standardised. What changes is that a commercial transceiver makes it possible to build a real evaluation chain: compatible controller, transceiver, network topology, firmware, test tools and prototype.

The TCAN6062 supports the CAN XL physical-layer requirements of ISO 11898-2:2024. Its data sheet also describes modes intended to reduce ringing in complex topologies and to handle the fast data phase. This does not remove network-design work. On the contrary, it confirms that at higher speeds, wiring, termination, stub length and signal quality are part of the product design rather than details to fix at the end.

One misconception is worth avoiding: changing the transceiver does not automatically turn an existing machine into a CAN XL system. The controller must support the protocol, firmware must manage the new stack, the network must be verified physically and the behaviour of existing nodes must be designed carefully. TI states that the component supports CAN FD and CAN SIC operation in mixed networks, but the actual migration path depends on the product architecture, not on replacing a single chip.

CAN XL does not automatically replace Ethernet

When data volumes grow, Ethernet is often the first answer. In many applications that is the right choice: Ethernet remains appropriate for large streams, complete IP networks, cameras, industrial PCs, gateways and enterprise infrastructure.

CAN XL addresses a different problem. It retains CAN's non-destructive arbitration, which makes it possible to give priority to messages that cannot wait. It can be attractive when control, sensors and diagnostics must share an architecture without imposing the complexity of a complete Ethernet network on every node.

The two technologies can also coexist. CAN in Automation describes mapping Ethernet frames into CAN XL frames, while Texas Instruments refers to TCP/IP tunnelling in mixed architectures. That does not make Ethernet unnecessary. It means a product can use Ethernet where broad connectivity is required and CAN XL where priority, distributed control and continuity with an existing CAN estate matter more.

The right decision is not “CAN XL or Ethernet?” but “which data must move, which data has priority, which nodes must remain simple, and which architecture can be maintained after delivery?”

When CAN XL is worth evaluating in a new product

CAN XL is not necessary on every microcontroller board. A simple sensor, a low-frequency actuator or a machine with a small number of short messages can continue to work extremely well with classic CAN or CAN FD.

The question becomes relevant when a team is already encountering concrete limits: bus load is high; diagnostics are reduced so control is not slowed; useful data travels over a poorly integrated second network; or the HMI needs an increasing amount of information from peripheral modules.

Question to ask	Why it matters
Are CAN FD messages being fragmented continuously?	Fragmentation increases overhead, application complexity and the number of test cases.
Must control share a network with richer diagnostics and sensor data?	Critical messages need priority without losing system visibility.
Will the product grow with new modules, HMIs or software functions?	A network sized only for the prototype can become a limit during industrialisation.
Are there CAN FD nodes that must be retained?	Migration can be gradual, but it has to be planned at architecture level.

The decision should not be based on a protocol's headline peak rate. A network designed for 20 Mbit/s does not automatically deliver 20 Mbit/s in every topology. The result depends on the physical characteristics of the machine: number of nodes, cable lengths, branches, connectors, electromagnetic interference, power and environmental conditions.

This is where a proof of concept is more valuable than a catalogue choice. Before a final PCB is defined, a team can simulate load, analyse expected traffic, build a representative network and measure latency, errors, degraded behaviour and diagnostic capability.

Migration is not a bus update: it is an architectural decision

In an existing product, moving toward CAN XL requires hardware, firmware and support processes to be considered together. The first step is not choosing a component. It is understanding what crosses the network today, how often it does so, which information is genuinely essential and where bottlenecks are emerging.

The options can then be compared. In some cases, optimising the application protocol is enough. In others, keeping CAN FD for control and adding Ethernet for one specific function is a better fit. CAN XL becomes particularly interesting when the aim is to reduce fragmentation, create room for growth and retain CAN's priority model in a more capable network.

existing architecture → measured real traffic → future requirements → topology → prototype → firmware and physical-layer verification → industrialisable decision

This approach avoids two opposite mistakes. One is adopting a new technology simply because it is available, without a measurable benefit. The other is retaining a saturated network because it “has always worked”, only to find the limit when the product needs a new HMI, gateway, support function or sensor-rich module.

Example: a modular machine with HMI, drives and diagnostics

Consider a modular machine with multiple axes, an operator panel, acquisition modules and a service gateway. CAN FD sends commands and states. Over time, the company adds process parameters, drive diagnostics, recipes, quality data and predictive-maintenance requirements.

Each new feature appears small at first. The result, however, is that information is split across many messages, diagnostics are limited during busy phases and firmware must coordinate a growing number of communication channels. CAN FD is not “wrong”; the original architecture was simply not sized for the product's real evolution.

A CAN XL assessment can determine whether diagnostic and configuration flows can move more efficiently while preserving priority control messages. It can also clarify whether a combined CAN XL and Ethernet design correctly separates local control, HMI functions and gateway connectivity.

The useful outcome is not the promise of a “more modern” network. It is an architecture that identifies which nodes to update, which to retain, which data to move, which physical constraints to respect and how to verify system stability before production.

Frequently asked questions about CAN XL

Can CAN XL already be used in commercial products?

The protocol and physical layer are standardised in the ISO 11898:2024 family. TI's TCAN6062 announcement provides a commercial component with which to start evaluations and new projects. A complete system still depends on controller availability, tools, firmware and the product's requirements.

Does CAN XL replace CAN FD?

No. CAN FD remains an excellent solution for many embedded networks. CAN XL should be considered when larger frames, throughput and architectural growth create a measurable benefit over the complexity of migration.

Can any microcontroller become CAN XL-capable with a new transceiver?

No. A transceiver implements the physical layer; the controller and firmware must support CAN XL. Feasibility must therefore be checked against the specific MCU, any real-time operating system in use and the available software stack.

Is CAN XL only an automotive technology?

No. CAN has strong automotive roots, but the newly available hardware is also presented for industrial robots, HMIs and control systems. The assessment should start with the use case, not with the sector in which the protocol originated.

Can CAN XL replace Ethernet in a machine?

Not universally. Ethernet can remain essential for high-capacity links, industrial PCs, gateways, cameras and IP networks. CAN XL is useful when a team wants to retain CAN priority behaviour while increasing the capacity of a distributed control network.

How Silicon Logix can support an evaluation

Silicon Logix can support companies and technical teams in evaluating the communication architecture of machines, embedded devices and modular systems. The work can begin with an existing CAN or CAN FD network, a new product under definition or a prototype that must progress toward industrialisation.

The objective is not to recommend CAN XL by default. It starts with data flows, priorities, topology, available MCUs, firmware and the future needs of the HMI, diagnostics, gateway or remote support. From there, the team can define a measurable proof of concept and a realistic technical path for the product.

Where needed, the assessment can continue with embedded firmware development, protocol integration, HMI interfaces, Linux gateways or diagnostic tools. The goal is to keep the device, communications and support software coherent without adding needless complexity.

Conclusion

The first commercially available CAN XL transceiver marks an important transition: a technology already defined by standards is becoming a concrete choice for teams designing the next generation of industrial products.

CAN XL will not erase classic CAN, CAN FD or Ethernet. Each technology will retain its place. Its value lies in an increasingly important space: networks that must carry more data without giving up priority, robustness and continuity with the CAN ecosystem.

For a company, the best decision is not adopting the newest protocol. It is designing a network with room for the product's actual evolution, one that can be verified before production and remains maintainable when the machine, firmware and customer requirements change.

The question is no longer only:

“How much data can we transmit today?”

It becomes:

“Will our architecture handle the next HMI, the next module and the next functions without having to be redesigned from scratch?”

Official references

Texas Instruments, TI advances next-generation industrial systems with the first commercially available CAN XL transceiver, August 12, 2026.
Texas Instruments, TCAN6062 CAN XL Transceiver with Standby Mode data sheet, ISO 11898-2:2024 physical requirements and component characteristics.
CAN in Automation, CAN XL, official description of the third CAN generation, payload and throughput.
CAN in Automation, CAN XL (extended data-field length), XL frame structure and its relationship to classic CAN and CAN FD.
CAN in Automation, ISO 11898-1:2024 released, standardisation of classic CAN, CAN FD and CAN XL.
CAN in Automation, Physical layer options, CAN SIC XL physical-layer characteristics and network-design constraints.

Are you designing a machine, HMI or device with more nodes and more data to manage?

Silicon Logix can carry out a technical assessment of the communication architecture, analysing traffic, priorities, nodes, firmware, topology and the product's room to evolve.

The work can start from an existing CAN or CAN FD network or from a new project, with a focused proof of concept before the hardware design is finalised.

Request a technical assessment of your project

Canonical source: CAN XL: what changes for robots, HMIs and industrial machines.