Scryglass beta · invitations by phase

Every log line, bus transaction, GPIO edge and microamp on one timeline — not five windows.

Scryglass captures everything your device under test does. It's for firmware and hardware engineers, and it replaces the window pile: a terminal emulator here, a logic-analyzer GUI there, a power profiler in a third, and a wall clock to correlate them by hand.

Because every signal shares one timebase, you can make deductions across them. The current trace says something is wrong, the log says everything is fine, and the GPIO edge tells you which one is lying.

Four tiers. Free opens and replays sessions; Maker adds the hardware for personal projects; paid work needs Professional or Commercial. Compare tiers →

Download
One chart carrying current, GPIO edges, bus and UART channels together, with two recipe annotations and a cursor readout pinning a current value to an exact timestamp
Six channels, two recipe results and a cursor reading — one timebase.
01

Everything is a channel, and every channel is on disk

A UART, a bus, a current probe, even an annotation — all the same primitive: a channel, timestamped on arrival and written straight into indexed session files.

The UI holds no data. Widgets are windows onto that store, so live tail, scrolling back an hour, and jumping to an exact timestamp are one operation over the same records. Nothing lives only in a scrollback buffer that dies with the window.

Acquisition and UI are one binary, so capture doesn't depend on which window has focus or how far back you've scrolled. If the session is running, it's on disk — closing a widget never costs you data.

A current trace dropping to zero and recovering, with the UART pane below showing the device's boot log at the same timestamp
The current goes to zero at 17:35:32; the UART shows the boot log from the same instant.
02

Channels don't just watch. They act.

Fire an I2C read, clock a SPI transfer, set a GPIO, switch a power rail — and the response lands on the same timeline as the stimulus. Cause and effect are measured, not inferred.

Recipes automate the loop: an event on any channel — a GPIO edge, a power threshold, a pattern in the UART stream — triggers a defined action sequence, and every execution writes its own success-or-failure record back into the capture. Automation is as observable as the hardware it touches.

Observe-only tools and control-only vendor GUIs are each built around one direction and one signal. Putting stimulus and response on a shared timebase across five protocols is an architecture, not a feature you bolt on.

A current trace with M1 and M2 markers measuring a 2.577 second interval, a recipe annotation reading Recipe Blue Button Pressed succeeded, and a statistics row below
A recipe's own execution record, annotated on the trace it fired against.
03

A test you can walk away from

Debugging and regression-testing are the same setup, because the capture never depends on you watching it. Leave the app running against the rig overnight: recipes keep working the device — stimulus on a schedule or on an event, success or failure logged every run — while every signal streams into the session on disk.

When something breaks at 3 a.m. you don't get a red X and a prayer. You come back to the full timeline — UART lines, bus traffic, current trace for the minutes either side — and scroll to the moment it went wrong.

The setup an engineer built while chasing a bug is already the fixture that guards against its return. The project bundles the channels, dashboards and recipes, so re-running the test is opening the file.

A thirty-minute window of a session with three recipe execution records annotated along the trace
Thirty minutes at a time is as far as the chart zooms out — pan left to reach any moment in the session.
04

An assistant with the same hands you have

There's an MCP server and an assistant built in, pointed at whichever LLM you configure. Both work through the same interface you do: if you can read it, query it, or change it, so can they — no second-class API that lags behind the app.

So you can hand over the tedious half of debugging. Ask what happened in the ninety seconds before the fault, have it correlate a current spike against the bus traffic, or point your own agent at a live session through MCP.

Writing to hardware is off until you turn it on. Out of the box the AI can observe everything and touch nothing; setting GPIOs, sending I2C, switching rails — that's Allow direct hardware control on the Settings page, a switch you flip deliberately, and it stays where you left it.

The assistant panel, with a model picker reading Local176 / qwen3.6:35b-mlx and a notice that responses can be wrong
Point it at whichever model you run — including a local one.
Settings, Integrations: an MCP server toggle with its port, and a separate Allow direct hardware control toggle
Reading data and touching hardware are two separate switches, on the Settings page.
05

The debugger is an instrument too

Plug in a debug probe and Scryglass finds it. Flash firmware, halt the CPU, step, set breakpoints, read memory and registers — from Visual Studio Code, or from a debug shell inside the app if you'd rather not leave it.

There's no separate debug toolchain to assemble and keep working — Scryglass talks to the probe itself, and your editor talks to Scryglass. Configure the launch once and press F5. On modern ESP32 chips you don't even need a probe: they debug over their own USB port.

And because firmware logs arrive as ordinary channels, they land on the same timeline as your current measurements, GPIO edges and bus captures. What was the code doing when the current spiked stops being two tools and a guess — it's one scroll.

Debug probes, in depth →

In more depth

CAPABILITY PAGES
RUNS ON
macOS · Windows · Linux
YOUR FILES
On your machine. Only.
CLOUD
No sync today. Usage counts only.
VERSION
——

The beta is open, in phases.

BETA · PHASE 1

Ask for an invitation

Five questions. They decide which phase you land in — we open to a few kinds of user at a time so support stays fast.

What's your work?
How many people would use it?
Which platform?
Would this be personal or paid work?
No newsletter. We write once, when your phase opens.