"It was supposed to last a year and it lasts three weeks" is one of the sentences we hear most often. The battery life of a BLE device is not a lucky outcome discovered at the end: it's a chain of design choices. Here's how, on our SailSensor products, we get years of operation from a coin cell — and how we apply the same method to our clients' projects.
Know-how applied to Moxá Design's proprietary products · Domain: embedded ultra-low-power / IoT.
A CR2032 holds a few hundred mAh: very little. To last years, the device's average consumption must be in the order of microamps, not milliamps. The margin for error is zero.
Transmitting is the action that consumes the most. Every BLE packet, every connection handshake, every retransmission adds up. The right question is not "how much does the radio consume" but "how often does it really need to turn on".
In a well-designed sensor, the microcontroller is awake for a few milliseconds and sleeps 99.9% of the time. It's the sleep current, multiplied by that 99.9%, that decides the real lifetime — not the peaks.
A sensor left permanently powered can undo all the work done on the radio. They must be chosen for low consumption and switched off or put into standby when not needed.
Where the use case allows it, we transmit data via BLE advertising instead of maintaining a connection. No handshake to renegotiate, no connection to keep alive: the device wakes up, transmits and goes back to sleep. It's the choice that cuts consumption the most.
Use of the microcontroller's ultra-low-power states (system ON idle and OFF), wake-up on RTC or on event, code that minimises active time. Every millisecond less spent awake is more battery life.
The transmission frequency is tuned to the real application need: transmitting every second or every ten radically changes the lifetime. Where needed, it adapts dynamically to context.
Transmission power set to what is necessary, sensors chosen for low consumption and managed in standby. We optimise the entire energy budget, not just one block.
Consumption is verified with dedicated instruments (power profiler), measuring the real currents in every phase: sleep, wake-up, transmission. What you don't measure you can't optimise.
Battery life is a design requirement like any other: you start from the target (e.g. "three years on a CR2032") and design backwards, instead of hoping the numbers add up at the end.
By applying this chain of choices, SailSensor sensors reach years of battery life on a coin cell, with average consumption in the order of microamps. The user rarely changes the battery — often forgets about it — and that's exactly the goal.
SailSensor BoomAngle applies this low-power approach to a difficult measurement problem: the boom angle to better than 0.5° with two IMUs, over BLE advertising and with years of battery life. It's power draw designed in from the start, not discovered at the end.
For many sensors that send small amounts of data at regular intervals, advertising is more efficient: no connection to establish and maintain, the device transmits and immediately goes back to sleep. A connection is preferable when frequent bidirectional exchanges or substantial data transfers are needed. The choice depends on the use case.
It depends on the duty cycle (how often it transmits) and on the sensors, but with advertising, aggressive sleep and low-power components it's realistic to reach years of battery life on a CR2032. The lifetime is calculated from the measured average consumption and the battery capacity, not guessed.
The most common causes: a sleep current that is too high (a component that doesn't really sleep), a sensor left permanently powered, a transmission interval that is too tight, or hidden retransmissions. They are identified by measuring consumption phase by phase with a power profiler.
Yes. We often work on devices that are already built: we measure the real consumption, identify where the charge goes and propose changes to firmware and, if necessary, to hardware to get back within the battery-life budget.
Whether it's designing a sensor with years of battery life from scratch or saving a device that consumes too much, it's the kind of problem we tackle every day. We measure, identify and optimise. The initial discovery is free.
Let's talk about your power draw