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