Hardware-Timed Multi-Phase Waveforms on Arduino UNO Q: From 500 kHz to 5 MHz
Engineering Journal · Activity date: August 2026
Quick access
Public access to SC5 has not yet been verified.
Arduino UNO Qmultiphase waveform:this case study explains a hardware-timed, four-channel 500 kHz design point and the qualification path toward higher-frequency operation. Programmed waveforms, timer validation and physical pin observations are kept separate to avoid overclaiming electrical results.
A practical power-electronics requirement led us to build a reusable four-channel waveform capability for Arduino UNO Q: four hardware-timed square-wave outputs, nominally spaced by 90 degrees, with independently represented dead-time and a design point around 500 kHz. The useful part of the story is not the number itself. It is the engineering path from a browser-level model to a timer route, compile-time qualification and physical observation, while keeping a strict distinction between what the software was programmed to generate, what the operator interface currently knows, and what was actually observed at the pins.
Why the Arduino UNO Q multiphase waveform needs hardware timing
The original use case came from a four-channel power-electronics drive where the channels need deterministic phase relationships and bounded non-overlap. A browser, dashboard or display can visualise the expected state, but it must never pace the real edges. That constraint pushed the timing responsibility into the MCU hardware timer rather than into UI or host scheduling.
Our canonical model represents frequency, period, duty, channel mask, waveform type and dead-time. The same accepted state feeds the oscilloscope-style LAB visualisation and the optional Matrix representation, but both are explicitly labelled as programmed/expected state. A visual trace is not evidence that the electrical signal has the same shape on a physical pin.
From the model to the UNO Q timer route
The source investigation converged on TIM1 and a four-pin route on Arduino UNO Q. The compile-only gate verified the required timer registers, channel enables and DMA request primitives against the exactArduinocore used by the project. This closed the software/toolchain question before any physical timing claim was made.
For the 500 kHz design point, the timer model also makes the quantisation explicit rather than pretending that every requested frequency or dead-time can be represented exactly. That matters in power electronics: the operator should see the accepted hardware state, not only the requested value.
What we physically observed
In the bounded UNO Q laboratory setup we physically observed square-wave operation through 5 MHz. The 10 MHz and 20 MHz modes remain experimental/degraded functional scope and are not presented as equivalent square-wave capability. The original 500 kHz multi-phase requirement therefore sits comfortably inside the range we have exercised, but this does not imply that every downstream gate driver, transformer or power stage is qualified at those frequencies.
The distinction is important:MCU pin timing is one qualification layer; gate-drive integrity, transformer behaviour, switching losses, ringing, device stress and power-stage operation are separate layers.Keeping those boundaries explicit is more valuable than claiming a single headline frequency.
The engineering lesson: programmed is not measured
One of the most reusable lessons from this work is a simple one: a configured waveform, a calculated waveform and a measured waveform are different evidence classes. The software can know the exact timer state it accepted. It cannot infer edge quality, overshoot, propagation delay or jitter from that state alone. Those properties require measurement.
That rule now influences how we design the rest of the FermiLabs measurement stack: keep configuration provenance, timing metadata and physical observations separate, then connect them explicitly when evidence exists.
Freshness is part of the evidence contract
A later source review exposed another way an engineering UI can become misleading even when the underlying timer is correct: an asynchronous status request started before a page is hidden can complete after the page is restored. If that old response is rendered, the dashboard can show or mirror stale hardware state. The Waveform LAB now suspends polling during page hide, advances a generation token, rejects responses from older generations before render or Matrix synchronisation, and resumes one fresh polling loop when the page returns.
The transferable lesson is broader than this one LAB. Once a dashboard presents engineering state,response freshness becomes part of the evidence boundary. “Programmed versus measured” is not enough if the programmed state itself may be stale. The lifecycle correction has focused source/host test evidence; native browser back/forward acceptance remains a separate gate.
Projects affected
- Arduino-EFBus— owns the reusable waveform capability, accepted state model, LAB presentation and freshness guard.
- SpeedCircuits— can reuse the same semantics for stimulus, timing and educational experiments without copying the low-level timer implementation.
- Arduino-OpenDAQ— provides the natural measurement/verification path when waveform configuration needs to be compared with acquired evidence.
Other projects should be added only when they have a real consumer relationship. FermiLabs.it is the Engineering Journal that connects these project stories, but the technical repositories remain the authority for versions, limits and qualification evidence.
Sources and evidence
What comes next
The next useful step is not to chase a larger headline frequency. It is to connect the accepted waveform state to repeatable measurement evidence: timing, phase spacing, non-overlap, jitter and eventually the behaviour of the real gate-drive path. That will let us compare what was requested, what the MCU programmed and what the electrical system actually produced.
Claim boundary:this article describes the software/hardware-timer work, focused host/source lifecycle correction and bounded UNO Q pin-level observations available in the project evidence. It does not claim native-browser lifecycle acceptance, qualification of a complete half-bridge, GDT, MOSFET stage or RF power system. The UNO Q timing evidence is platform-specific and must not be treated as VENTUNO qualification.
