Low-power IoT device design for battery-powered products.
A battery-powered device spends most of its life asleep, and its power design decides whether it can be left alone. Our four-channel LoRaWAN node, running as a single trial unit, is where we have worked through it.
Just want monitoring deployed, not a custom build? See Paqett →
The problem
Power is where small devices go wrong quietly. A gauge that reports the wrong voltage or a radio that retries too eagerly after an outage can each flatten a battery or silence a device. We would treat battery measurement, sleep behaviour and radio retries as one design problem and not three. Sleep and recovery are covered on our embedded firmware page, and joining behaviour on our LoRaWAN sensor design page. This page is about the power side.
The decisions we would settle with you are how often the device must wake and report, what it needs to know about its battery, whether the supply is a primary cell, a rechargeable pack or a vehicle supply, and what the device should do when the supply runs low. We would choose the battery and the measurement together, because a gauge that is hard to read correctly is worse than none.
Power also shapes the rest of the design. A sensor that needs a long warm-up costs more battery than one that does not, a radio that sends often costs more than one that sends rarely, and a mechanical choice such as a sealed case limits how the battery can be changed or charged. We would list those trade-offs for your device before choosing parts, and keep the list as the design develops. Where a figure matters, such as how long the device should run between charges or battery changes, we would measure it on the real hardware and state the result with the conditions it was measured under, and not quote a number in advance.
What we'd build
Power design for a battery-powered device
Our LoRaWAN node reads its battery with a fuel gauge. It is a trial of one unit. The rows show where our own work stands and what we would settle with you for your device.
| Layer | What we'd do | Detail |
|---|---|---|
| Battery measurement | Our node uses an STC3100 fuel gauge to read its battery. | A read returned a stale register: 3.91 V while a meter showed 3.83 V. Reading after a 5 s settle gave 3.862 V |
| Reporting interval | How often the device wakes and reports, set against what you need to know and how the battery is to be sized. | |
| Supply and charging | Whether the device runs from a primary cell, a rechargeable pack or an external supply, and how it is charged or replaced. | |
| Low-battery behaviour | What the device does as its supply falls, including what it reports before it stops. |
How working with us goes
- 01 Scope We agree what has to be built, where it lives and where the data goes.
- 02 Prototype Working hardware and firmware on your bench, tested against real conditions.
- 03 Pilot A small batch on real sites, with fixes folded back into the design.
- 04 Production Design for manufacture, a production run, and support once it is in the field.
Related
LoRaWAN sensor design ·Embedded firmware development ·Wildlife tracking ·Asset and vehicle tracking · All sectors →
Need a device that lasts on a battery?
Custom hardware, firmware and software, from first sketch to production.
Talk to us about your project alessio.grespi@gmail.comWant it deployed, ready to run?
Not every project needs a new device. Ask us whether Paqett, our white-label monitoring business, already covers what you need to measure.
See Paqett →