Starting the logs where the project started: with the thing that annoyed me enough to build hardware.

The problem, stated plainly

Every diagnostic session I run lands in one of two bad places.

Place one: SSH into a headless box and squint at a terminal. Fine if you already know the exact command and the exact flag. Miserable when you're standing at a bench with one hand on a probe.

Place two: carry a laptop to the bench, open the full GUI, and navigate a tool built for someone doing everything, when you are doing one thing.

The observation that turned into a project: for any single diagnostic question, I use roughly two controls and watch roughly two numbers. Consistently. Across CAN, I2C, serial, Wi-Fi, SDR. The tools aren't wrong — they're general-purpose, and general-purpose means the 90% you're not using is between you and the 10% you are.

The three annoyances that made it concrete

Getting a headless Pi onto a network. You pull one off the rack and you have two bad options: hook up a screen and keyboard for the sole purpose of joining Wi-Fi, or go hunting for an Ethernet cable — and then arp-scan into a forest of identical "Raspberry Pi Foundation" MACs and SSH in blind. This costs me hours a year.

Port roulette. Half these tools ship a browser UI. Which port did it land on? Is it actually serving, or did it just spawn and die? You find out by trying.

Bitrate guessing. Unknown CAN bus, unknown rate. You try 250k. You try 500k. You get nothing and can't tell whether the bus is silent or you're just wrong.

None of these are hard problems. They're all friction problems. Friction problems don't get solved because each one individually isn't worth solving.

The approach

A Raspberry Pi 5 and a 3.5" touchscreen that boots straight to a tile grid. Tap a tile, get an answer, tap Back. No desktop, no keyboard, no mouse.

The rules I'm building to, stated up front so I can be held to them:

• Front-end existing tools, don't reinvent them. Underneath it's arp-scan, i2cdetect, candump, gpsd, rtl_433 — software that's already trusted and already debugged. I'm building the panel, not the tool.
• Render to the framebuffer, not through a display server. Straight to /dev/fb0, touch straight off evdev. Nothing in the stack that can lose the display device. This one was learned the hard way and gets its own log.
• Don't fake interactions the hardware can't do. Resistive touch cannot reliably distinguish a horizontal swipe from a vertical drag. So there are no swipes. Every navigation is a discrete tap. Home is a grid, every screen has a Back button, long lists get real scroll buttons.
• Contract first. Any coupling point between components gets a written spec before either side is built. Contracts are the only coupling point.
• Prove it headless before it touches hardware. Software gets verified without the board, then the board bring-up is its own gated phase. Debugging a logic error and a wiring error at the same time is a bad afternoon.
• Fail safe by default. Anything unconfigured resolves to the restrictive behavior, never the open one.

Scope, declared up front

It runs Kali, so let me get ahead of the obvious question. Scope is strictly diagnostics. No offensive or attack tooling. Not "discouraged," not "behind a warning dialog" — the UI is built so it cannot express an offensive operation. Enforced in code, not convention.

The one exception is CAN bus, which does normal TX and RX. That's not a loophole, it's a requirement: heartbeats and replies are how you diagnose a bus. A listen-only CAN tool can't tell you whether a node is deaf or merely quiet.

This is a shop multitool, not a gadget.

Next

Next log: why I threw out the X server, and what an ILI9486 panel does to you before you figure that out.