Introduction: Why Power Optimization Matters

Power is a first-class constraint in almost every computing context, yet it is often the last thing engineers think about. A firmware developer may spend weeks optimizing code speed only to ship a product that drains its battery in two days instead of two months. A system administrator may carefully tune application performance while their home server quietly draws 40 W around the clock — costing more per year than the hardware itself.

This book is about changing that reflex. Power optimization is not a final polish step. It is a design discipline with its own measurement techniques, mental models, and toolchains.


The Stakes Across Device Classes

The consequences of poor power design differ by device, but the cost is always real.

Embedded microcontrollers: A temperature sensor node running on three AA batteries should last years. If the firmware never enters deep sleep, it may last days. The difference is not exotic hardware — it is a single function call and a few configuration registers.

Laptops: A well-tuned Linux laptop can run four hours longer per charge than an out-of-the-box installation on the same hardware. That difference comes from CPU frequency governors, TLP, and fixing a handful of wakeup offenders that fire hundreds of times per second.

Small servers and NUCs: A NUC drawing 15 W instead of 6 W costs roughly €50–€80 more per year in electricity (at European rates). Over five years that is the price of the machine itself. Proper BIOS C-state configuration and service hygiene can close most of that gap.


The Measurement-First Principle

Every chapter in this book follows the same discipline: measure before you optimize, measure after you optimize.

Intuition about power consumption is almost always wrong. The WiFi radio on an ESP32 draws about 240 mA during a transmission burst — far more than the microcontroller core. A single printk debug statement can prevent a CPU package from entering its deepest C-state, adding watts to the entire system’s idle draw. A poorly tuned systemd timer that fires every minute keeps a disk spinning that would otherwise be parked.

You cannot fix what you cannot see. Chapter 2 is dedicated entirely to measurement tools and techniques before we touch a single optimization.


How This Book Is Organized

The book is divided into four parts:

Part I — Foundations covers the concepts that apply everywhere: battery chemistry, measurement tools, and the basics of power electronics. Even if you only care about laptops, reading Chapter 1 will give you a clearer mental model of what a battery actually is and why certain charging habits degrade it.

Part II — Embedded Devices covers ESP32 and Arduino/AVR in depth. Chapter 4 goes through every ESP32 sleep mode from modem sleep to hibernation, with the duty-cycle energy budget formula you will use for every battery-life estimate. Chapter 5 does the same for the AVR family. Chapter 6 covers the peripheral layer — how to duty-cycle sensors, manage radios, and control display backlights.

Part III — Laptops and Small Servers covers the Linux power management stack. You will learn how CPU frequency scaling actually works under the hood, how to configure TLP without cargo-culting options you do not understand, and how to use powertop and turbostat to find and fix wakeup offenders. The small server chapters cover BIOS C-state tuning, tuned profiles, and systemd service hygiene.

Part IV — Monitoring and Case Studies ties everything together. Chapter 12 builds a unified power monitoring pipeline using INA219 sensors, MQTT, and Python. Chapter 13 walks through four real-world scenarios end to end.


What You Will Need

None of the software requires paid tools or proprietary platforms. Everything runs on open-source Linux tooling and standard Python 3.


Table of Contents Chapter 1: Battery Chemistry and BMS →