The central trick
Most battery-powered sensors have very little to do. They need to take a measurement and send it, which may take a second or less, and then there is nothing to do until the next reading. The way to make a small battery last for years is not a bigger battery; it is spending almost all of the time doing almost nothing.
That is duty cycling: the device alternates between a short active period and a long sleep period. The duty cycle is the fraction of time it spends awake. A device awake for one second out of every 600 has a duty cycle of about 0.17 percent.
What sleeping actually means
A processor can run in several power states. Names differ between chip families, but the idea is common:
- Active. Everything is running. The highest consumption.
- Light sleep. The processor stops executing but memory and many peripherals stay on, so it can wake in a very short time.
- Deep sleep. Most of the chip is switched off. Only a small timer and perhaps a few pins remain powered. Consumption can be thousands of times lower than active, though memory contents may be lost, and the device restarts more like a reboot when it wakes.
Microcontrollers designed for low power make these states cheap and quick to use, which is one reason they are preferred over general-purpose computers for battery sensors.
The radio and the sensors have their own on and off states too. A well-designed device powers down each part when it is not needed, not only the processor.
What wakes the device
- A timer. The simplest approach: wake every so many seconds or minutes, measure, report, sleep.
- An interrupt. A sensor or switch signals the processor when something happens, such as a door opening or motion being detected, and the device wakes only then. This is how contact sensors and leak sensors can stay asleep for months and still react instantly.
- A threshold. A low-power comparator watches a signal and wakes the device only when it crosses a limit, so the processor stays off the rest of the time.
Combinations are common: a timer for a periodic heartbeat plus an interrupt for events.
A worked example (hypothetical numbers)
Suppose a sensor draws 20 mA while awake and 0.005 mA (5 microamps) while asleep. These figures are made up for illustration. Assume a battery with 2,000 mAh of usable capacity and ignore self-discharge and aging.
Case A: wake for 1 second every 10 minutes (600 seconds).
- Awake for 1 s at 20 mA: 20 mA-seconds.
- Asleep for 599 s at 0.005 mA: about 3.0 mA-seconds (599 x 0.005 = 2.995).
- Total per cycle: about 23.0 mA-seconds.
- Average current: 23.0 / 600 is about 0.038 mA.
- Battery life: 2,000 / 0.038 is roughly 52,000 hours, or close to 6 years.
Case B: the same device waking for 1 second every minute (60 seconds).
- Awake for 1 s at 20 mA: 20 mA-seconds.
- Asleep for 59 s at 0.005 mA: about 0.3 mA-seconds (59 x 0.005 = 0.295).
- Total per cycle: about 20.3 mA-seconds.
- Average current: 20.3 / 60 is about 0.34 mA.
- Battery life: 2,000 / 0.34 is roughly 5,900 hours, about 246 days, or roughly 8 months.
Reporting ten times as often cut the life by roughly a factor of nine, from about six years to under a year. In both cases nearly all of the energy went to the one active second, not to the long sleep. That is typical, and it points at where to optimize: shorten the active period or lengthen the interval before worrying about the sleep current. Once the active part is small enough, the sleep current becomes the next thing to reduce.
Real devices are messier, with cold weather, retries and self-discharge all shortening the figure; see our article on what drains sensor battery life for those effects.
Making the active period short
Because the awake time dominates, designers work hard to trim it:
- Fast wake-up. Avoid long start-up delays. Sensors that need warm-up time cost extra.
- Quick measurement. Take a reading, then turn the sensor off at once.
- Efficient radio use. Join, send and leave the network quickly. Protocols designed for short messages, such as Bluetooth Low Energy or low-power networks, are built around this. Re-establishing a full Wi-Fi connection each time is much more costly.
- Batching. Collect several readings and send them in one transmission.
- Skip unneeded work. Skip the transmission if the reading has not changed meaningfully, and send a heartbeat now and then.
Trade-offs of sleeping
- Latency. A sleeping device cannot respond to commands instantly. If you need to switch it on from a phone, it may have to wake on a schedule and check for instructions, so response times are slow. Devices that must react quickly, such as actuators, often use mains power instead.
- Missed events. A timer-only sensor that wakes every ten minutes can miss a brief spike between readings. Interrupt-driven wake-up helps.
- Clock drift. Sleeping clocks are inexpensive and imprecise, so timing may wander. Systems that need aligned timestamps correct them when connected.
- Updates and management. Sleeping devices are hard to reach with over-the-air updates or for device management. Designs often include a periodic listening window.
- Debugging. A device that sleeps is harder to observe, which makes failures harder to diagnose.
Common mistakes
- Leaving a peripheral or pin in a state that leaks current during sleep, so the real sleep current is far above the datasheet value.
- Using a voltage regulator with a high idle draw.
- Failing to enter sleep after a failed connection, so the radio keeps trying until the battery is empty.
- Setting a short reporting interval because it seemed harmless.
Measure your device’s sleep current with a suitable meter rather than trusting calculation alone. A surprising number of products are found to sleep far less deeply than designed.