Roger Mendoza
← All notes

Inside SolveBlock Core Rev C: a custom ESP32-S3 board, and the checkmarks we had to take back

From a dev board on a breadboard to a custom ESP32-S3 PCB — the layout, the manufacturer checks, the firmware architecture that runs on more than one board, and an honest milestone list.

3 min read SolveBlock PCB ESP32
3D render of the SolveBlock Core Rev C board in the manufacturer's DFM viewer

SolveBlock started on off-the-shelf boards: first a bare ESP32 dev board with a small SPI display and physical buttons, then an all-in-one ESP32 touchscreen board. Both were the right way to prove the idea. Neither is a product. SolveBlock Core Rev C is the first board designed around the device rather than borrowed for it — an ESP32-S3, kept deliberately minimal.

The Rev C board rendered in KiCad's 3D viewer
Rev C in KiCad's 3D viewer. The silkscreen says it plainly: ESP32-S3, minimal.

What's on the board

Rev C carries only what SolveBlock needs:

  • The ESP32-S3 module, with its antenna end at the board edge.
  • USB-C for power and programming.
  • A jack for the timer cable, so the StackMat plugs straight in.
  • Two small wire-to-board connectors and a header for the display.
  • Boot and reset switches, because a board you can't force into download mode is a board you'll eventually have to rework.
  • Four corner mounting holes that the enclosure is built around.

"Minimal" is a feature. Every part not on the board is a part that can't fail, can't be mis-placed at assembly and doesn't need a footprint checked.

The routed copper in KiCad's PCB editor
Routing in the PCB editor: the module's pins fanned out to the display header on the right.
The routed board in wireframe, both copper layers
The finished layout in wireframe, as the manufacturer sees the Gerbers.

Letting the manufacturer check it

Before ordering, the Gerbers and assembly files went through the manufacturer's own DFM viewer — the 3D view at the top of this note. Its assembly analysis checks things that are easy to miss in your own tools: component collisions, spacing, parts too close to the board edge, pins without pads, through-hole leads near other holes. On Rev C every category shown came back clean.

That's not the same as the board working. It means the board can be built as drawn. The first is proven on the bench; the second is cheap to prove before you spend money.

One firmware, more than one board

The firmware was designed for this from the start. Its architecture document has one rule above all: each module owns exactly one concern.

Timer UART  →  Timer (decode packets)  →  Session (history, undo, PBs)
            →  Modes (Ao5, Ao12, Mo3)  →  Display (render)  →  Screen
  • Timer decodes the StackMat's serial stream — 1200 baud, inverted — and reports state and times. It never computes an average.
  • Session stores the history, handles delete and undo, and persists to flash. It never touches hardware.
  • Modes are stateless: give one a list of solves and it returns an average. Nothing else.
  • Display only draws what it's handed, and redraws only the regions that changed.
  • Boards hold pin definitions and initialisation — no application logic at all.

That last rule is why supporting a new board — Rev C included — is designed to be a new board file, not a rewrite. The timer decoder, session engine and averaging code are shared; only the pins and the display driver change.

The checkmarks we had to take back

The most useful section of the architecture document is the one that admits a mistake.

Its milestone list was written before implementation, and used ✓ to mark planned deliverables. Over time, those checkmarks were read as done. When we audited them, some had never been compiled, never rendered on a screen, or never met real hardware. So the list was rewritten with one rule: [x] means verified by something that was run; [ ] means written but never exercised — and each line says which.

The same audit found and repaired ten defects in earlier code, and put the logic under a real host test harness built with every warning treated as an error. The averaging modes alone have 53 checks against the WCA rules. The record of the correction lives in the repo, next to the code it corrected.

SolveBlock firmware host checksall host checks132averaging vs WCA rules53button debouncing21
Logic tested on the host with every compiler warning treated as an error, so the averaging engine is verified before it ever meets a board. Source: SolveBlock architecture document.

It's the same lesson as auditing 113 research findings: a checkmark is a claim, and a claim needs evidence you can re-run.

What's next

Rev C still has to earn its place on the bench: bring-up against the checklist I use for every board, the decoder confirmed against a real timer, every screen legible on the panel, and hundreds of solves surviving a power cycle. Then it goes into the enclosure that wins the shape vote.