A look at how power measurements has traditionally worked — and why the way engineers build products today calls for a software-first instrument.

A modern battery-powered product is a moving target. In deep sleep it might draw a few hundred nanoamps. A fraction of a second later, when the radio transmits, it pulls hundreds of milliamps — a swing across six to nine orders of magnitude, and it can happen in tens of microseconds. Engineers writing about low-power IoT design describe exactly this: current that jumps from hundreds of nanoamps to hundreds of milliamps almost instantly, in devices expected to run for ten, twenty, sometimes thirty years on a single cell.

Measuring that well is hard. But here is the part the industry has been slow to admit: it is no longer only a hardware problem. It is a software problem. And most power measuring instruments come from a hardware-first tradition — one where the software followed the hardware rather than leading it.

How power measurements are traditionally done

To see why, it helps to look at where test-and-measurement instruments come from.

The instruments themselves are impressive. The source measure unit — the SMU — is the tool most often reached for when you need to both power a device and measure what it draws. A modern SMU is marketed, accurately, as five instruments in one: a precision multimeter, a power supply, a current source, an electronic load, and a pulse generator, in a single tightly integrated box. It can source and measure across a remarkable range — picoamps to tens of amps, nanovolts to kilovolts, with six-and-a-half digits of resolution. This is superb hardware.

But it was built to give you a snapshot. You put a probe on and read a value on the front panel, in the moment. When you want to actually analyze what happened — study a transient, compare runs, work through a long recording — the data has to come off the instrument first, exported to an SD card or a USB stick and carried over to a computer, where the real work happens after the fact. There is no live analysis while the measurement runs, and the user experience was never designed for one. The instrument measures; the thinking happens later, on another machine.

It is also expensive hardware, and that collides with how engineers work now. A common single-channel Keithley SMU lists at around $7,000; a dual-channel model runs closer to $15,000. But modern low-power development is rarely one measurement of one thing — you are weighing several radios or connectivity options, comparing a handful of dev kits and reference designs, characterizing different battery chemistries, often in parallel. With traditional instruments that means one costly box per channel, and at $7,000 to $15,000 each, putting an instrument on every bench or running ten measurements at once isn’t feasible. (The budget alternative — stitching together a multimeter, an oscilloscope, a current sensor, and a supply — only trades the cost for complexity.) The tool doesn’t scale to the number of questions engineers now need to ask.

That fit the world it was built for: an engineer at a bench, characterizing a part, reading a number off a screen. For that world, it fits well.

What changed

Two things changed, and they changed together.

#The devices changed. A wide dynamic range of current, captured accurately, over long periods, across many operating modes, correlated with what a radio or a network is doing — that is the measurement modern low-power design actually needs, and the trade press says so plainly. The hard part isn’t the raw span; a precision instrument can be set to resolve picoamps, or set to carry amps. It is doing both at once, continuously, while the current races between them in microseconds. Instruments measure one range at a time, and autoranging can’t switch fast enough to follow a signal that jumps from microamps of sleep to hundreds of milliamps of transmit without gaps or glitches on the fast edges. Stay on a single range instead and you have to choose: a high range takes the active spikes but buries the sleep current in noise; a low range resolves the sleep current but clips the spikes. A shunt and an oscilloscope hit a noise floor and a burden voltage; a clamp-on current probe can carry more than a milliamp of noise. The job outgrew the tool.

#The teams changed. So why is this shift happening at all? Because R&D itself has been restructured. Not long ago, a hardware team was a bench of deep specialists: RF engineers who had spent years mastering antenna design, power-electronics experts, analog designers building custom signal chains by hand. They were craftspeople, and their craft was the product. Hardware was the differentiator.

That same team looks nothing like that today. One or two systems engineers select modules instead of designing circuits. The hardware increasingly comes from reference designs. And the software team is two or three times the size it used to be, because that is where the product now lives — in the firmware, the user experience, the connection to the cloud. The differentiation moved into software.

We watched this happen from the inside; our own team evolved the same way, from hardware-focused to software-focused. And it changed who reaches for our tools. The engineer trying to shave microamps off a sleep current is rarely a power-electronics PhD anymore. They are an embedded software developer trying to understand what their code is doing to the battery.

This is not a subtle evolution. It is a fundamental restructuring of how products get built — and a team built around software wants tools that behave like software: scriptable, automatable, able to sit in a CI pipeline like everything else they ship. To that engineer, a bench instrument that has to be driven by hand, or scripted through a decades-old text protocol, is not a tool that fits the workflow. It is a bottleneck that has to be babysat.

A software-first instrument for low-power measurements

This is the gap Otii was built for, and we built it from the software in.

We treat the software not as a wrapper around the hardware but as an equal peer to it — and, for the people using Otii, it is the part they actually work in and where the value comes from. It is built by software engineers, as a discipline of its own, not as a side task for the hardware team. The hardware still has to be excellent: Otii powers your device and measures current and voltage at high precision, doing in one affordable instrument the work you would otherwise split across a programmable supply, an SMU, and a dedicated analyzer. It both sources and sinks current, so that same instrument also profiles, emulates, and tests real batteries — turning measured consumption and real cell behavior into a grounded estimate of the battery life your product will actually get. But the reason it earns its place on the bench is what the software makes possible.

Everything that makes it worth having grows out of one thing traditional instruments were never built to do well.

#Above all, it collects and analyzes data — robustly, and at scale. A long power measurement is a firehose: high sample rates, a wide dynamic range, running for hours, days, or weeks, often unattended. The software has to capture every sample without dropping data, losing sync, or slowing as the recording grows — and then let you work with that data freely: scroll a week-long capture, zoom from the whole run down to a single microsecond transient, and measure across millions of points without grinding to a halt. The difference underneath is architectural. Traditionally, your computer talks to the instrument — a command channel to the box, one reading at a time. With Otii, the software owns the data and gives you an API into it, so you work with the measurement itself: programmatically and in real time as it streams, scaling from one channel to many running in parallel, across files that hold weeks or months of continuous recording. That pairing — robust long-run collection and a software layer built to handle the data — is what Otii is built around, and it is not what a traditional instrument was built for. A bench meter was made to show a reading, not to be a data platform you can trust to run all weekend, survive hour 68 of a 72-hour test, and still be responsive on Monday morning.

Everything else grows out of that foundation.

#You analyze in real time, while it runs. You don’t wait for the capture to finish, export a file, and only then discover you asked the wrong question. You watch and measure as the data streams in — zoom into a transient, read the energy of a wake event, see a running average settle — in the middle of the measurement.

#You compare measurements, not just take them. Overlay recordings and the difference becomes the answer: this firmware build against last week’s, sleep mode A against B, the same device before and after an optimization. Comparing many captures this way is native to the tool, not a manual export-to-spreadsheet chore — and it is how you actually prove a change helped instead of hoping it did.

#You sync power with what the device is doing — and find the real drain. A current trace on its own tells you the device pulled 40 mA. It doesn’t tell you why. Otii puts the power measurement and the device’s own logs and events — UART, GPIO — on one synchronized timeline, so you can point at a spike and see the operation, state, or event behind it, and set it against how a real battery is responding. That correlation is how you find what is actually draining the energy in your device — and it is exactly what you could never get cleanly when power and behavior lived on separate instruments.

#Your work is a project you can share, not a screenshot you email. Traditionally a measurement was disposable: read the number, grab a screenshot, paste it into an email, move on. Otii keeps your work as a project — many recordings, gathered over a test campaign, labeled, kept together, and revisited — an organized body of evidence you return to, not a folder of PNGs nobody can interpret later. And because the software is a free, standalone viewer, that evidence travels: a colleague, a customer, or a supplier can open the actual recording and analyze it themselves, with no instrument required. You discuss the measurement, on the real data, instead of trading screenshots and descriptions over email.

#And it fits how you work now. Because the intelligence lives in software rather than a front panel, the workbench comes to you instead of tying you to the box in the lab: it runs on every major operating system, and it exposes a clean API — with Python, C#, Java, and MATLAB clients — so the very same measurement can run unattended inside a CI pipeline. Versatile enough to be one engineer’s bench tool and the whole team’s automated regression check, from a single instrument.

None of these is a headline hardware number. Every one is a software capability — and together they are the difference between an instrument you read and an instrument you build on. This is the part of power measurements that has been left for last for decades. We put it first.

The point

None of this is a knock on the hardware the industry has built, ours included. A precision SMU is a beautiful instrument, and for characterizing a part at a bench it is exactly right. But the instrument is only half the product. For the way electronics are developed now — across multidisciplinary teams that know batteries, write code, run automated, data-driven measurements over long periods, and integrate hardware and software into products — the other half matters just as much.

Power measurement became a software problem. We built the instrument that treats it like one.