Low Power Embedded Design and Solar Harvesting
Closing an energy budget so a device runs unattended, on harvested power, indefinitely.
Context
The requirement is almost always the same sentence: it has to run out there on its own, and nobody is going to drive out to visit it. Low power embedded design gets asked for by name, and on its own it does not answer that sentence, because this is an energy balance problem and the failure mode is silent. A device that is merely low power works fine through the summer and then dies in the field in December, when the panel sees a fraction of the light it saw in June and the load has not changed at all. Nothing warns you. The only way to know in advance is to profile the real draw on the bench, size the harvest against the worst month rather than the average one, and let firmware spend energy against a state of charge it actually reads. That budget gets closed before the hardware ships, not after the first winter.
Scope
What this covers
- 01Battery fuel gauging over I2C for coulomb counted state of charge, voltage and current, read by firmware at runtime rather than estimated from a voltage curve.
- 02MPPT solar charge control, sized to the panel and the cell chemistry.
- 03Power budgeting across sensing, radio duty cycle and deep sleep states, expressed as a number that can be defended.
- 04Bench current profiling, the measurement low power embedded design has to start from, because what is actually drawing is regularly not what the datasheets predict.
- 05Firmware-level duty-cycle decisions driven by measured state of charge, so a device throttles its own reporting rate before it browns out.
- 06Solar energy harvesting sizing against worst-case seasonal insolation, not annual average.
- 07Deep sleep architecture and wake-source design, including which peripherals stay powered through sleep and which do not.
- 08Power path hardware: harvest, storage, charge control and load switching designed as one subsystem with the firmware that governs it.
- 09Defensive firmware for unattended deployment: watchdogs, safe restart, and recovery paths that do not require a site visit.
Record
Work behind this
Delivered work, stated as facts rather than claims. Programs and employers are named where naming them is what makes the record checkable. Clients are not.
Questions
Questions technical buyers ask
Can you tell us whether our existing design will survive a winter?
That is a measurement, not an opinion, and it is one of the more common first engagements. It means profiling the real current draw of the device in each of its states on the bench, building the energy budget from those numbers, and sizing the harvest against the worst month at the deployment latitude. The output is a written budget showing whether harvest exceeds consumption, and if it does not, which term in the budget to attack first.
Do you cover firmware as well as hardware on this?
Both, and on this particular problem the two cannot be separated. An energy budget only closes when the charge controller, the fuel gauge and the duty-cycle logic agree with each other. Hardware that can measure state of charge is wasted if firmware never reads it, and firmware that throttles on a guess instead of a reading is the design that dies in December.
What does a first engagement usually look like?
An energy audit of what exists: bench current profiling, a written power budget across every device state, harvest sizing for the actual deployment site, and a ranked list of what to change. It is scoped and short, and it produces a document that a technical reviewer can check line by line against their own measurements.
Start a technical conversation
Describe the system, the constraint and the deadline. An engineer answers.
Tools and platforms we work with: Coulomb counting I2C battery fuel gauges. MPPT solar charge controllers. Nordic nRF52 and nRF9160 low power and deep sleep modes. Bench current profiling instrumentation across sleep, sense and transmit states.