aioscilloscope

CH1Phase 1: NovaOS on Rigol DHO800/900 and MHO900

These scopes pair a Rockchip RK3399 with a Xilinx-class FPGA over PCIe, the same recipe as the LED video processors we work with every day. Stock, they run Android 7.1 on a Linux 4.4 kernel with a Java app on top. NovaOS replaces all of it: the Rockchip 6.12 BSP kernel (Linux 6.12.112, a long-term kernel supported until December 2028, and the newest with Rockchip's Mali GPU driver; why not 7.2), a minimal Yocto and systemd system, and a scope stack written from scratch in Rust: the acquisition engine, a GPU-drawn UI, SCPI, Webcontrol, VXI-11 and LXI.

It is our own engine talking to the FPGA directly, so everything the hardware can do is available. The stock firmware stays on the scope, one menu item away.

There is no Android, no Java, no X server and no compositor: the UI draws with OpenGL ES on the Mali GPU straight to the display through DRM/KMS, samples arrive by PCIe DMA into a shared-memory ring the UI reads without copying, and remote view uses the SoC's hardware H.264 encoder. A running scope uses about 217 MB of RAM. How the stack fits together.

Measured on our units

What it adds

• Analysis: eye diagram and jitter (TIE, RJ/DJ/PJ, bathtub, mask templates fitted to the signal), Bode plots, mask testing, counter and DVM, histograms, user math, power analysis.
• Identify: names what is on screen, such as a clock, a UART at its baud rate or I²C, and offers the right decoder, trigger or measurements in one tap.
• Decoders: the full stock set, with more coming: DMX512, Modbus RTU, 1-Wire, SWD/JTAG and USB-PD.
• Remote view: the screen streamed to another display, paired with a 6-digit code, with touch control.
• Maintenance: signed updates with automatic rollback; the factory calibration partition read but never written; essentially no flash writes at idle; 10 UI languages; a built-in self-check.
• Compatibility: SCPI follows the stock command tables, so existing scripts and Rigol's Webcontrol keep working.

DHO900 and MHO900 side by side

CH2Phase 2: the FPGA

Rigol's FPGA design is solid: it fills most of the chip with triggers, filters and interleave correction. What it leaves on the table is getting data out: capture and read-out take turns, read-out runs at about one sample per clock, and there is no density map in the FPGA. On a DHO at 20 ns/div we reach about 30k waveforms a second, a quarter of what the record length allows.

First we are squeezing the driver side, since part of the per-trigger cost may come from how the image is driven. A rewrite only makes sense where the community wants the speed.

CH3Phase 3: an instrument of our own

Everything learned in phases 1 and 2 goes into our own design: no screen, no knobs, no phone operating system. Plug it in over Ethernet with PoE or USB, and an AI agent, or any program, connects and drives it. It is also an FPGA bring-up bench: logic inputs, JTAG, a console, two supplies and a generator, all on one timebase.

A built-in MCP server (Model Context Protocol) serves these calls; the same calls work as JSON over HTTP and WebSocket, and SCPI stays for existing tools. We are prototyping the same agent interface on the phase 1 scopes first.

Safety lives in hardware. A physical generator-output switch means an agent cannot drive a circuit until a person turns it on. Updates are signed, FPGA images are signed and checked before they load, and nothing listens without a token.

Every figure in this section is a design target until a measurement replaces it.

CH4Tell us what you want