A sensor sits in a pump housing at the edge of a plant. No mains power, no ethernet, no technician scheduled to visit for three years. It has one job, a battery the size of a coin, and a promise attached to it: still reporting when someone finally walks out to check. That promise is not a firmware problem or a radio problem. It is an energy problem, and it is decided before a single line of code is written.
The energy budget is the first spec
We treat the energy budget the way a bridge engineer treats load. Add up every microamp the device will spend in a day, multiply by the years it must last, and that number is the size of the battery you are allowed to use. Everything else negotiates against it. That framing changes the parts you pick. You do not choose an MCU or a radio for its headline throughput or its peak clock. You choose it for its sleep current and how fast it can get back to sleep. A chip that draws two hundred nanoamps idle and wakes in microseconds beats a faster part that leaks milliamps between jobs, every time, over three years.
Sleep is the product, waking is the exception
A field device that lasts is asleep almost always. The whole design is built around duty cycling: wake, take a reading, maybe transmit, go back to deep sleep, and stay there. If the device is awake one second in a thousand, that awake second can afford to be expensive; the other nine hundred ninety nine must cost almost nothing. So the hard engineering is in the transitions. What clocks are still running in sleep, what peripherals forgot to turn off, whether a pull-up resistor is quietly burning current through a pin all night. Those are the leaks that turn a three year battery into a six month one, and none of them show up in a demo on the bench.
The datasheet is a promise; the field sends the bill
Datasheet numbers are measured in ideal conditions the field never provides. Sleep current is quoted at room temperature; your device sits at minus ten in winter and forty in a sealed enclosure in summer, and leakage roughly doubles for every ten degrees. The radio is rated at nominal voltage; yours runs off a battery that sags under transmit load. So we never trust the sum of datasheet lines. We build the real duty cycle, put a current probe across the whole board, and capture the actual profile — the sleep floor, the wake spikes, the transmit bursts — over hours, across temperature. The number that comes off that bench is the one we design the battery to, and it is almost never the number on paper.
The datasheet tells you what the part can do. The field tells you what it will cost. Only one of them signs the invoice.— Protocore · Hardware engineering
The last piece is refusing to let a bad radio day become a bad data day. Coverage drops, gateways reboot, interference spikes; a device that retries forever will drain itself defending data it could have simply held. So we store and forward — log to flash, back off, and send when the link returns. A blackout then costs a little power, not a batch of readings. This is the discipline behind the field devices we have carried from prototype to certified OEM hardware at volume: measure the energy first, spend it deliberately, and the promise on the battery holds long after the technician has stopped checking.
Have a system to build?
Tell us the problem. We'll come back with an architecture and a plan.
Start a project