Project 12: Power Budgeter - Battery Life and Low-Power Modes

Measure system current draw, build a power budget, and validate battery life predictions.

Quick Reference

Attribute Value
Difficulty Level 2: Intermediate
Time Estimate 10-20 hours
Main Programming Language C++
Alternative Programming Languages C
Coolness Level Level 3: Genuinely Clever
Business Potential 2. The “Product” Model
Prerequisites C/C++ basics, Teensyduino setup, basic electronics, ability to use a multimeter/logic analyzer
Key Topics power measurement, sleep modes, battery modeling

1. Learning Objectives

By completing this project, you will:

  1. Explain the core question for this project in your own words.
  2. Implement the main workflow and validate it with measurements.
  3. Handle at least two failure modes and document recovery.
  4. Produce a deterministic report that matches hardware behavior.

2. All Theory Needed (Per-Concept Breakdown)

Power Budgeting, Measurement, and Low-Power Modes

Fundamentals Power budgeting accounts for current draw of all subsystems so the total stays within supply limits. Teensy current draw changes with clock speed, peripherals, and I/O loads. Low-power modes reduce consumption but affect clocks and wake-up behavior. This project makes power a measurable, testable property.

Deep Dive into the concept Current draw is dynamic: the MCU core, peripherals, and external loads each contribute. A proper power budget lists each subsystem’s current in each state and multiplies by duty cycle to estimate average current. Battery life is then capacity divided by average current. Measurement is key: a USB power meter gives coarse values; a shunt resistor and scope give detailed profiles. Low-power modes reduce current but can disable peripherals or change clock domains. Wake-up sources must be configured correctly or the system may never wake. The tradeoff is latency vs power; deeper sleep saves more power but increases wake time. This project measures current in multiple states, builds a budget, and validates predictions with a timed run.

How this fit on projects This concept directly powers the implementation choices and validation steps in this project.

Definitions & key terms

  • Duty cycle (power): Fraction of time a subsystem is active.
  • Sleep mode: Low-power state with reduced clocks.
  • Quiescent current: Baseline current draw when idle.
  • Power budget: Total current draw across all subsystems.

Mental model diagram (ASCII)

Battery -> Regulator -> MCU + Peripherals -> Loads

How it works (step-by-step)

  1. Measure idle and active current for each subsystem.
  2. Compute average current using duty cycles.
  3. Validate predicted battery life with timed run.
  4. Test low-power modes and wake-up behavior.

Minimal concrete example

// pseudo: reduce clock and sleep
set_arm_clock(150000000);
enter_sleep();

Common misconceptions

  • USB power is unlimited.
  • Sleep mode always saves power regardless of peripherals.
  • Battery life is linear with capacity.

Check-your-understanding questions

  • How do you compute average current with duty cycles?
  • Why can sleep mode break UART or USB?
  • What is a safe current margin?

Check-your-understanding answers

  • Sum each subsystem current multiplied by its active fraction.
  • Clocks may stop, disabling those peripherals.
  • At least 20-30% headroom to cover peaks.

Real-world applications

  • Battery-powered sensors
  • Wearables
  • Remote loggers

Where you’ll apply it

References

  • MCU power management chapter
  • Battery datasheets

Key insights

Power behavior must be measured and modeled, not guessed.

Summary

A good power budget is a testable model of your system’s current draw.

Homework/Exercises to practice the concept

  • Measure current for three system states and compute a budget.
  • Compare predicted vs measured battery life over 4 hours.

Solutions to the homework/exercises

  • Use a USB meter or shunt resistor and log current values.
  • Run a timed discharge test and compute error percentage.

3. Project Specification

3.1 What You Will Build

Measure system current draw, build a power budget, and validate battery life predictions.

3.2 Functional Requirements

  1. Measure current draw for multiple system states.
  2. Compute average current using duty cycles.
  3. Estimate battery life and compare to real run.
  4. Document low-power mode behavior.

3.3 Non-Functional Requirements

  • Performance: Meet the target timing/throughput for the project.
  • Reliability: Detect errors and recover without undefined behavior.
  • Usability: Provide clear logs and a repeatable workflow.

3.4 Example Usage / Output

./P12-power-budgeter-battery-life-and-low-power-modes --run

3.5 Data Formats / Schemas / Protocols

CSV with columns: state, current_ma, duty_cycle

3.6 Edge Cases

  • Brownout under peak load
  • Sleep mode disables required peripheral
  • Battery voltage sag under bursts

3.7 Real World Outcome

You will run the project and see deterministic logs and measurements that match physical hardware behavior.

3.7.1 How to Run (Copy/Paste)

cd project-root
make
./P12-power-budgeter-battery-life-and-low-power-modes --run

3.7.2 Golden Path Demo (Deterministic)

Use a fixed input configuration and a known test signal. Capture output for 60 seconds and verify it matches expected values.

3.7.3 If CLI: exact terminal transcript

$ ./P12-power-budgeter-battery-life-and-low-power-modes --run --seed 42
[INFO] Power Budgeter - Battery Life and Low-Power Modes starting
[INFO] Report saved to data/report.csv
[INFO] Status: OK
$ echo $?
0

Failure Demo (Deterministic)

$ ./P12-power-budgeter-battery-life-and-low-power-modes --run --missing-device
[ERROR] Device not detected
$ echo $?
2

4. Solution Architecture

4.1 High-Level Design

Inputs -> Acquisition -> Processing -> Output/Log

4.2 Key Components

Component Responsibility Key Decisions
Acquisition Configure peripherals and capture data Use stable clock settings
Processing Convert raw data to meaningful values Apply calibration/filters
Output/Log Emit reports and logs CSV for reproducibility

4.3 Data Structures (No Full Code)

struct Sample {
    uint32_t timestamp_us;
    uint32_t value;
    uint32_t flags;
};

4.4 Algorithm Overview

Key Algorithm: Measurement + Report

  1. Initialize hardware and verify configuration.
  2. Capture data and record timestamps.
  3. Compute metrics and write report.

Complexity Analysis:

  • Time: O(n) in samples
  • Space: O(n) for log storage

5. Implementation Guide

5.1 Development Environment Setup

# Arduino IDE + Teensyduino must be installed
# Optional CLI workflow
arduino-cli core update-index
arduino-cli core install teensy:avr

5.2 Project Structure

project-root/
├── src/
│   ├── main.ino
│   ├── hw_config.h
│   └── measurements.cpp
├── tools/
│   └── analyze.py
├── data/
│   └── samples.csv
└── README.md

5.3 The Core Question You’re Answering

“How long will my system run, and what is the evidence?”

5.4 Concepts You Must Understand First

Stop and research these before coding:

  1. power measurement, sleep modes, battery modeling
  2. Data logging and measurement techniques
  3. Basic timing math and error analysis

5.5 Questions to Guide Your Design

  1. How will you measure current accurately?
  2. Which peripherals must stay active in sleep?
  3. What safety margin will you include?

5.6 Thinking Exercise

Compute battery life with and without sleep modes.

5.7 The Interview Questions They’ll Ask

  1. What is a power budget?
  2. How do duty cycles affect average current?
  3. Why do regulators matter?

5.8 Hints in Layers

  • Measure idle and active states separately.
  • Use a power meter or shunt resistor.
  • Document wake-up sources before sleep.

5.9 Books That Will Help

| Topic | Book | Chapter | |——-|——|———| | Power basics | Making Embedded Systems | Ch. 9 | | Battery modeling | Battery University | Article series | | Embedded design | Practical Electronics | Ch. 11 |

5.10 Implementation Phases

Phase 1: Foundation (4 hours)

Goals:

  • Measure idle/active current
  • List subsystems

Tasks:

  1. Measure idle/active current
  2. List subsystems

Checkpoint: Power table

Phase 2: Core Functionality (8 hours)

Goals:

  • Compute budget
  • Test low-power modes

Tasks:

  1. Compute budget
  2. Test low-power modes

Checkpoint: Budget validated

Phase 3: Polish (4 hours)

Goals:

  • Long run test
  • Document results

Tasks:

  1. Long run test
  2. Document results

Checkpoint: Final report

5.11 Key Implementation Decisions

| Decision | Options | Recommendation | Rationale | |———-|———|—————-|———–| | Buffering | Single buffer, double buffer | Double buffer | Avoids data loss during processing | | Logging format | CSV, binary | CSV | Human-readable while still scriptable | | Clock speed | Default, overclock | Default | Keeps peripherals in spec |

6. Testing Strategy

6.1 Test Categories

| Category | Purpose | Examples | |———-|———|———-| | Unit Tests | Validate math, parsing, and conversions | Timer math, CRC checks | | Integration Tests | Verify peripherals and pipelines | DMA -> buffer -> log | | Edge Case Tests | Handle boundary conditions | Brownout, missing sensor |

6.2 Critical Test Cases

{test_cases}

6.3 Test Data

Use a fixed test input pattern and record outputs to data/report.csv

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

| Pitfall | Symptom | Solution | |———|———|———-| {pitfalls}

7.2 Debugging Strategies

{debug_strats}

7.3 Performance Traps

Large buffers improve stability but increase latency. Measure both throughput and jitter to choose the right size.

8. Extensions & Challenges

8.1 Beginner Extensions

{ex_begin}

8.2 Intermediate Extensions

{ex_inter}

8.3 Advanced Extensions

{ex_adv}

9. Real-World Connections

9.1 Industry Applications

{industry_apps}

{open_source}

9.3 Interview Relevance

{interview_rel}

10. Resources

10.1 Essential Reading

{resources}

10.2 Video Resources

  • Embedded systems timing walkthrough (YouTube)
  • Teensy hardware deep dive (Conference talk)

10.3 Tools & Documentation

  • Teensyduino: Toolchain for Teensy boards
  • Logic Analyzer: Timing verification
  • Multimeter: Voltage and current measurement

{related_projects}

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain the main concept without notes.
  • I can explain why the measurements match (or do not match) expectations.
  • I understand at least one tradeoff made in this project.

11.2 Implementation

  • All functional requirements are met.
  • All critical test cases pass.
  • Logs and reports are reproducible.
  • Edge cases are handled.

11.3 Growth

  • I documented lessons learned.
  • I can explain this project in a job interview.
  • I identified one improvement for next iteration.

12. Submission / Completion Criteria

Minimum Viable Completion: {comp_min}

Full Completion: {comp_full}

Excellence (Going Above & Beyond): {comp_ex}