Bench — Hardware in the loop

Your hardware, tested like software.

The bugs that survive to the field are the physical ones — a board that boots nine times in ten, a long-press that trips at the wrong threshold, a setting that doesn’t survive a hard power cut, Bluetooth that goes flaky after thirty reconnects. Nobody reproduces those by hand on every build. Bench does: a rig that power-cycles, presses, measures, and connects to your device, driven from your test suite.

For hardware and firmware teams who want the regressions caught on the bench, not by the first customer.

§ 01 — What it is

Three layers,
one closed loop.

Not just firmware. A physical fixture wired to your device, the ESP32 that runs it, and the Python framework your tests speak to — one product, from the relay to the assertion.

The fixture

Relays and optocouplers wired to your device power it and press its buttons; calibrated ADC and digital sense lines read it back. The physical half of the loop — a real bench, not a simulation.

The firmware

An ESP32 runs the rig over a line-based serial protocol — millisecond-accurate timed pulses off a hardware timer, a safe power-on state, and BLE plus Bluetooth Classic to stand in as the phone or peer a device connects to.

The test framework

A Python library, a CLI, and a pytest plugin, with ready-made recipes and typed accessors — rig.relay[1].pulse(500), rig.adc[1].millivolts() — so tests read like tests, not like wire protocol.

One loop, closed

Actuate, measure, and connect from a single test run, so a hardware fault surfaces as a failing test with a trace — not a note that says the tester could not reproduce it.

Part of our embedded and cloud engineering →Source and schematics under NDA.
§ 02 — What it catches

The tests worth
running overnight.

The checks that are tedious, timing-sensitive, or statistical — the ones people skip under deadline. Each ships as a recipe pointed at your device.

Power-cycle boot regression

Cycle power N times and assert the device reaches its boot banner within a deadline every time. Catches the intermittent boot a single manual power cycle never will.

Brownout recovery

Drop power for 10 to 500 ms in steps and assert a clean recovery at each. Repeatable to the millisecond — the kind of test that is effectively impossible by hand.

Long-press timing boundary

Hold a button either side of its threshold and assert the right action fires on each side. Timed by a hardware timer, not a thumb and a stopwatch.

Persistence across a hard cut

Write a setting, cut power mid-operation, restore, and assert it survived. Tests the failure mode that actually loses data, not the graceful reboot that always works.

BLE reconnection stress

Connect and disconnect dozens of times and assert the device re-advertises and reconnects each round — finding the handle and pairing-table leaks that only show after tens of cycles.

§ 03 — How it reaches your bench

Built around
your device.

A rig is only useful wired to a real board. We adapt Bench to yours — channels, connectors, and test cases — in the same shape as the rest of our embedded work.

№ 01 — Scope the device

Map the board

We map your board’s power, buttons, signals, and radios onto the rig’s channels, and agree the test cases actually worth automating. If your board doesn’t need a rig this size, that is a fine answer too.

№ 02 — Wire and encode

Build it around your board

We build the fixture around your device and encode your cases as recipes — power-cycle, brownout, timing, persistence, reconnection — that run from your CI or on the bench beside it.

№ 03 — Hand over, or keep running

Yours to run

You get the rig and the tests, documented. We can maintain and extend them on a retainer as the product changes — new firmware, new failure modes, new checks.

§ 04 — Contact

Put your board
on the bench.

We read every enquiry ourselves and reply within two working days. Quick chats, long briefs, half-formed ideas — all welcome.

Tell us about the device — what it does, how it’s powered, the buttons and radios, and the failures you’re chasing. Prototype or in production, we’ll scope a rig around it. If an NDA needs to come first, say so and we’ll start there.