Standby current: the number that decides a desk pet's battery life

A desktop pet’s battery life is decided while it appears to be doing nothing. The visible behaviours — expressions, sounds, movements — are bursts; the bill accumulates in standby. Every desk-pet programme we run starts with a standby current target, because everything else follows from it.

Where the microamps go

The wake engine is the biggest architectural choice: a hardware wake-word engine drawing a steady trickle, versus button-wake at essentially zero. Radios in their idle states still poll; Bluetooth sleep profiles vary by an order of magnitude between platforms. Displays that hold an image without refresh cost nothing; panels that need multiplexing cost real current every second. Regulators leak, and the difference between a good quiescent current and a bad one shows up precisely where the product sleeps.

The lever hierarchy

First, sleep aggressively: the deepest power states are only reachable if the firmware is willing to tear down and rebuild its context, which is a firmware architecture decision. Second, gate the radios: connectivity that only matters when the owner interacts can poll rarely. Third, choose the panel for the duty cycle. Motor and speaker draw are visible-burst problems, not standby problems.

Why the number is contractual

We write the standby target into the proposal — microamps at battery, not “long battery life” — because it changes component selection, firmware architecture and, ultimately, the battery size the shell has to hide. A product that misses its standby target by 2x cannot be rescued by a battery that fits the tooling.

The test that predicts the review

We measure standby on real units with real firmware: average current over a day of the product’s actual idle behaviour. That single number predicts the owner’s experience more accurately than any datasheet total.