We lost a week to a board that had nothing wrong with it. Every part was in spec, every part did its job, and it still ate a battery in six days. That week changed what we think hardware is. The notebook is below. What we believe comes after.
NOTEBOOK 3 · PP. 41–46If you've built hardware, you know the moment. The board is on the bench, the number on the screen is wrong, and you're staring at it, waiting for it to mean something. Sometimes there's a person you can call who looks for ten seconds and says "oh, that's the pull-up." Most of the time there isn't, and you spend the week finding out what she would have said.
We used to think that was just the price of working with atoms. We don't anymore. The physics isn't slow. The reading is: the moment a number turns into a cause happens in a few heads, on a few benches, and nowhere else. It was never written down, so nobody ever built it.
We think that's the last big thing in hardware that still runs on luck. And we think it's fixable.
Three support tickets, same complaint: the unit stops reporting after about a week. It's rated for a year on a coin cell. The bench unit has never run on a coin cell. It has been on a USB cable since the day it was built. Put a fresh cell in one of the returned units and left it logging.
Put a returned unit on the power profiler. Awake, it draws 14 mA for a fifth of a second every ten minutes. That's fine. Asleep, it should be about 12 µA. It's 1.5 mA. A coin cell holds about 220 mAh; 220 over 1.5 is six days. That's the ticket. It isn't dying. It's never actually asleep.
The 12 µA on the spec sheet was measured on the first prototype, before the accelerometer went on. Nobody measured it again.
Went through it part by part. Radio asleep: 3 µA at its own pin. MCU in its deepest sleep from a test build: no change. Lifted the accelerometer with the iron: 14 µA. Put it back: 1.5 mA. So it's the accelerometer. Except the datasheet says it sleeps at 2 µA, and a fresh one from the reel does exactly the same thing. The part that causes it isn't the part that draws it.
Ordered a different accelerometer anyway, because ordering something felt like progress. Mara is off this week.
Mara's back. Showed her the schematic. She asked what the pull-up on the accelerometer's interrupt line was. 2.2 kΩ. She asked what the accelerometer does with that line when it has data nobody has read. Holds it low. Three volts across 2.2 kΩ is 1.4 mA, through a resistor, into a sensor, all night. The firmware only reads the data on wake, so the line is high for a fifth of a second every ten minutes and low the rest of the time.
The resistor is fine. The accelerometer is fine. The firmware does what we told it. Together they're a 2.2 kΩ resistor across the battery.
Clear the interrupt before sleep. Changed the resistor to 100 kΩ while we were in there. 16 µA.
A profiler will tell you to the microamp what a board drew. A scope will show you a glitch a nanosecond wide. Neither has ever had an opinion about why. For fifty years the picture got sharper and the reading stayed exactly where it was: in someone's head.
Mara isn't cleverer than the rest of us. She has seen a pulled-up line held low before, and we hadn't. That kind of seeing takes years to grow, can't be hired in a hurry, and most teams on earth don't have it. The ones that do have one of her, and some weeks she's off.
Here is the thing that changed: we can now build a board in software, break it in one specific way, and see exactly what the instruments would show, ten million times before lunch. A model raised on that has seen more broken boards than any one career could. That's what we mean by physical AI. Not a chatbot that read the datasheets, but something trained on the physics itself, before it ever touches a real board.
Half the hardware in the world is being brought up for the first time: a fresh design, a first prototype, a number that's wrong on day one. The other half was designed years ago by someone who has since left, and it's now failing in the field with nobody around who remembers why. DebugBoard doesn't mind which. A capture and a schematic are enough. It gives the new board a Mara on day one, and gives the old board back the person who left.
We are not trying to replace the person at the bench. We want to stand next to them and say what Mara would have said, on Tuesday, with the one measurement that proves it. Judgement stays human. Waiting doesn't have to.
So we're building the thing that reads it. DebugBoard is a physical AI for electronics. We build circuits in simulation, break them every way they can break, record what the instruments would show, label every capture with its cause, and do it millions of times. Then it reads yours: the capture, the schematic if you have one, and the number you expected. Back comes a finding, causes in order, each with the one measurement that settles it. Not a dashboard. A finding.
We're starting with the faults that eat the most weeks: batteries that drain too fast, boards that reset when the motor starts, sensors that read right on the bench and wrong in the field. We'll keep going until there isn't a shape on a screen it hasn't seen. Software got tools that understand code twenty years ago, and software got faster. Hardware is next.
DebugBoard is our first step.
Send one capture that's out of spec. You still hold the probe. We'll tell you where to put it.