One team for the full board lifecycle, with the hardware to support it
High-speed PCB design for AI hardware, board and Linux bring-up, EMI pre-compliance, and hardware-in-the-loop testing in CI. Four stages that usually mean four vendors and three handoffs.
Every engagement ends with your board on a BenchPod, our test bench that both your pipeline and an AI agent can drive. You can try one on your own board, too.
Free sample board. Every request is reviewed case by case.
BenchPod: our compact instrument that makes target hardware CI ready, with digital I/O and 16-bit analog I/O (400 kSPS, ±30 V).
Engineering services
Need help with your board?
Bring us in for the whole board or the one stage that is blocking you.
- High-speed PCB design
- Board and Linux bring-up
- EMI / EMC pre-compliance
- HIL testing in CI
Product
Need a test bench?
The BenchPod puts power control, SWD flashing, a UART console, a logic analyzer and a 16-bit analog front-end in one networked box next to your board. Two ways to drive it:
BenchPod AI HIL: an ai agent driving a real bench over mcp.
BenchPod PyTest SDK: hardware-in-the-loop tests in python and ci.
What we do
Four stages of the board lifecycle, one team
Integrating AI hardware (NPUs, accelerator modules and SoMs) is our specialty. For each stage, hire us, or use the tooling we built for it yourself.
01
High-speed PCB design
Schematic, stackup and layout for boards that carry AI silicon: NPUs, accelerator modules and SoMs.
Use it yourself: PCB Trace Length Analyzer, free: length matching for DDR, USB, PCIe and Ethernet
02
Bring-up and Linux BSP
First power-on through to a booting system: bootloader, device tree, drivers and a reproducible image.
Use it yourself: BenchPod, flashing, the UART console and power sequencing from the first power-on
03
EMI / EMC pre-compliance
Find the emissions problems on the bench, while a fix is still a layout change rather than a respin.
Use it yourself: EMI Analyzer, free: EMI and EMC checks on your own board files
04
Test, CI and iteration
Hardware-in-the-loop tests wired into your pipeline, so every change is measured on the real board.
Use it yourself: BenchPod AI HIL, an AI agent drives the bench; BenchPod PyTest SDK, the same bench from pytest and CI
Founders with more than 20 years in Linux, CI, CD and reliability engineering. Two decades of established software practice, brought to hardware.
The product
BenchPod: the test bench behind every engagement
We built the BenchPod because we kept rebuilding the same rig from a Raspberry Pi and assorted adapters. Now it is the bench our engagements end on, and you can use it on its own: try one without hiring us, or hire us without one.
BenchPod typical CI: emulate sensors and power rails by playing arbitrary analog waveforms into your target.
BenchPod AI HIL
Give Claude, Cursor or your own agent the bench as MCP tools. It flashes, power-cycles and probes the board, and closes the loop the way an engineer would.
See BenchPod AI HIL →
BenchPod PyTest SDK
pip install embeddedci and write hardware tests as ordinary pytest tests. The same suite runs against a pod on your desk and in GitHub Actions on every push.
See BenchPod PyTest SDK →
Try a BenchPod on your own board
Tell us what you want to test. We review every request case by case, and if you have a use case to evaluate it on, we send you a sample board free of charge.
1
Tell us your use case
Which board you want to test, and what you want to find out.
2
We review it
A person reads every request, usually within a few business days.
3
We send a sample
Free of charge, when the BenchPod fits what you are evaluating.
An evaluation board: a bare board with breakouts and jumper wires, and firmware and docs that are still moving.
Best practices that get skipped
None of it is controversial. It is just the first thing cut when a date slips.
What usually happens
- The layout house does not talk to the firmware team.
- Bring-up findings live in a notebook and are never measured again.
- EMC is discovered at the accredited lab, after the layout is frozen.
- CI stops at “it compiles.” The hardware regressions ship.
How we work instead
- Design-for-test and EMC are schematic review inputs, before layout is frozen.
- Bring-up becomes the first automated suite, and the baseline to regress against.
- Pre-scans happen on the bench, months before the lab.
- Every commit is flashed, booted and measured on the real board.
How we engage
Four ways to work with us
Start with the bench, bring us in for the stage that is blocking you, or hand us the whole board.
Start with the bench
Request a free BenchPod sample and try it on your own board. No engagement needed.
Request a free BenchPod →A single stage
A layout review, a Linux BSP, an EMC pre-scan, or the test rig on its own.
The whole board
All four stages, from a blank schematic to a board under test in CI.
Rescue an in-flight project
A board that will not boot, will not pass EMC, or will not stay fixed.
Resources
Technical write-ups from our own work
Driving the BenchPod with Claude
AI HIL end to end: connect Claude to the BenchPod MCP server and ask it, in plain English, to flash a board, power-cycle it, watch the UART and emulate a sensor.
Read it →
Building a solar panel simulator
A bench supply cannot stand in for a solar panel. A closed-loop emulator with a real I-V curve, and what the knee looks like on hardware.
Read it →
Power sequencing and brown-out testing
Gating the target through protected eFuses, monitoring current per rail, and sagging the supply on purpose.
Read it →
Build your own HIL, or buy a pod?
Where the Pi-and-relays path leads, and when it is genuinely the right call.
Read it →
Where are you starting from?
A blank schematic, a board back from the fab, or a pipeline that stops at the build step. The first conversation is the same: what are you shipping, and how do you know it works?
Free sample board. Every request is reviewed case by case.