How should I choose the battery for a connected device?
Four things drive the decision: the physical form factor (button cell vs. cylindrical vs. lithium-polymer), the voltage architecture (step-up, step-down, or direct connection — step-down generally allows a wider choice of higher-capacity batteries), and critically the peak current the battery can deliver, since LPWAN radio transmissions need current peaks around 50–120 mA that not every battery chemistry handles well. Temperature matters too: cold reduces deliverable current and voltage, heat above 40°C accelerates capacity loss and raises the risk of thermal runaway (fire, explosion).
Can I trust the battery autonomy a manufacturer announces?
Not blindly — real-world testing has shown batteries rated at 900mAh delivering only around 400mAh, and others rated 2800mAh delivering as little as 350mAh in practice. Modeling consumption from theoretical constant-current figures is also risky, because LPWAN devices draw power in short high peaks rather than a steady current. Always validate actual capacity and consumption on your specific hardware before committing to an autonomy figure.
What are the most common mistakes when prototyping a connected object’s hardware?
The two recurring ones are trusting a battery datasheet’s capacity without testing it on the real device, and extrapolating power consumption from lab/constant-current measurements instead of the device’s actual peak-based usage pattern. Both lead to an autonomy estimate that looks good on paper and fails in the field. The recommended approach is to work with battery vendors and validate at the expected operating temperature rather than relying on intuition alone.
Should hardware be built in-house or with a specialized integrator?
Battery and power design in particular is described as an area where it pays to work with experts rather than rely on lab intuition alone, because the gap between a datasheet and real-world behavior (capacity, peak current, temperature) is where projects most often go wrong. The same logic extends to radio integration in general: getting it right the first time avoids costly redesigns once devices are already deployed in the field.