I’ve been working with IoT for about 8-ish years and the one thing that has rang true for across platforms, designs, customers, and use-cases is that you can only squeeze so much performance from a setup that wasn’t properly optimized for low power consumption.

I’ve had customers approach me desperately to me trying to make IoT device survive just one night on a small LiPo battery, enough so the sun in the morning will charge it up again, but their solution was a cobbled together mess with a ESP32 looking for their administration network to connect to, a uBlox modem powering up and sending off a 4MB packet every 5 minutes. Turns out, it would have more power efficient to leave the modem powered on and connected to the cell network as you need to exchange something like 25-50 packets per handshake or 2 packets per minute if you’re just idling.

I’ve had the curse of the guy who just fixed everything because I have a background in both hardware and software in addition to knowing cell networks at a low level and TCP/IP stack (usually DTLS, in this case). When I optimize stuff, I will attack it from all directions. For example, it costs more power to receive messages so for anything nonsensical (such as a periodic data packet) I use a non-confirmable UDP packets, i.e. fire and forget. I try to avoid using heavy RTOSes on my devices and opt for a simple messaging library to properly format data for optimal transfer over the cell network. My devices I build have low powered MCUs with a restart timer to wake up periodically. I managed to make a solar powered environment sensor with only an super capacitor as reserve power.

This went on a bit, but I think my point is that for well-architected, low-power devices, you need to start from the ground up, and sometimes that means ditching your IoT platform and spinning your own hardware and firmware. My last observation is that many hardware engineers are not the ones who install or test the solutions they design and are unaware of the power consumption outside of the specs in the data sheet.

Nice job.

Effective capacity also drops with load for many batteries, and there can be subtleties. Read all the data sheets and applications manuals from your suppliers.

Even very good firmware engineers can need reminders that everything you do with a battery operated device drains the battery.

Keysight, R&S, and Tektronix/Keithley all have nice battery test devices and battery test simulators. You can rent one if buying one takes your breath away.

Also IoT devices can require you to use very fast ammeters or sourcemeters to correctly measure net current or power. The RMS reading on your multimeter might not even register fast spin-up and spin-down on a BLE device. That's another use case for the Qiotech tool. Again, the big instrument makers make even nicer stuff. Call an FAE.

Use a CR2032 battery or be prepared for a life of misery. :)

To a first, second, and third approximation: CR2032 is the largest coin cell that exists. Anything else has terribly weird quirks and may not actually be better than a CR2032.

Basically, there are only three battery choices:

1) Alkaline

2) CR2032

3) Full blown LiPol rechargeable

Any divergence is pain. Lots and lots of pain.

We're building a bicycle product involving loadcells, and one of the issues with them is that strain gauges typically have pretty low resistance. As we need readings at a relatively high sample rate (measuring pedalling dynamics) it's a lot of fun waking up loadcells, getting the sigma delta ADCS to get nicely-settled 24-bit results across multiple channels and synchronising the whole thing across 4 separate sensor nodes. Basically we have to pedaL and chew minimal joules at the same time.

Latest hardware has coulomb counters to keep track of charge state; you probably already know it but the nPM1100 has some good press.

* https://www.nordicsemi.com/products/npm1100

Whats wrong with using grafana?