Project 23: Ultra-Low-Power Battery MIDI Node (<5mA Idle Target)

Transform NeoTrellis firmware into a measured, battery-aware controller profile with strict idle-current and wake-latency targets.

Quick Reference

Attribute Value
Difficulty Level 5: Master
Time Estimate 2-3 weeks
Main Programming Language C/C++
Alternative Programming Languages Bare-metal C
Coolness Level Level 4: The “Whoa, You Built That?”
Business Potential 2. The “Micro-SaaS”
Prerequisites sleep modes, timers, peripheral clocks, measurement tooling
Key Topics power modes, clock scaling, peripheral gating, brownout handling, runtime estimation

1. Learning Objectives

By completing this project, you will:

  1. Define explicit power modes with measured current budgets.
  2. Implement mode transitions with deterministic wake behavior.
  3. Gate clocks/peripherals to reduce idle current below target.
  4. Integrate brownout-safe persistence and reset policy.
  5. Produce runtime estimates from measured current profiles.

2. All Theory Needed (Project-Scoped)

2.1 Mode-Based Power Design

Power engineering starts with mode contracts, not ad hoc register toggles.

2.2 Current Measurement Discipline

Segment measurements by mode and event profile; avoid relying on single averages.

2.3 Clock and Peripheral Policy

Dynamic scaling and peripheral gating provide major power wins with controlled tradeoffs.

2.4 Battery and Brownout Behavior

Voltage sag and load spikes demand safe commit and reset strategies.

2.5 User Experience Constraints

Low power is only useful if wake latency and control response remain acceptable.

3. Project Specification

3.1 What You Will Build

A portable firmware profile with:

  • active/idle/deep-idle mode table
  • wake-on-input behavior
  • current telemetry by mode
  • brownout-safe config handling

3.2 Functional Requirements

  1. Deep-idle mode achieves <5mA average current.
  2. Wake from pad input with bounded latency.
  3. Brownout events trigger safe, non-corrupting behavior.
  4. Runtime estimate output based on measured profile.

3.3 Non-Functional Requirements

  • Performance: wake p99 latency within UX target.
  • Reliability: zero config corruption in low-voltage tests.
  • Usability: mode transitions are understandable and observable.

3.4 Real World Outcome

$ power_profile --battery lipo_1200mah --scenario idle_10min
[MODE] active_play=62.4mA
[MODE] idle_dimmed=8.7mA
[MODE] deep_idle=4.6mA (PASS)
[WAKE] pad_to_ready_ms p50=11.4 p99=19.8
[BOD] events=3 safe_resets=3 config_corruption=0
[RUNTIME_EST] 1200mAh -> ~260h deep-idle equivalent
PASS: power and safety targets met

4. Solution Architecture

4.1 High-Level Design

Input inactivity timer --> mode manager --> clock/peripheral policy --> current profile
                                 |                    |
                                 |                    +--> wake source config
                                 +--> brownout policy +--> safe commit gating

4.2 Key Components

Component Responsibility Key Decision
Mode manager transition between power states explicit transition table
Resource policy clock/peripheral enable matrix per-mode capability set
Power telemetry measured current and wake stats periodic summarized reports
Brownout handler safe reset and persistence policy block unsafe writes below threshold

4.3 Mode Contract (Pseudocode)

mode ACTIVE: full clocks, full IO
mode IDLE: reduced clocks, dim LEDs, no display refresh
mode DEEP_IDLE: wake on key/RTC, minimal peripherals

5. Implementation Guide

5.1 Phases

  1. Baseline current profiling in current firmware.
  2. Implement explicit power state machine.
  3. Add wake-path optimization and latency metrics.
  4. Add brownout tests and safe commit guardrails.

5.2 The Core Question You’re Answering

“Can this device be truly portable while preserving responsive interaction and safe state handling?”

5.3 Questions to Guide Design

  1. Which peripherals are mandatory in each power mode?
  2. What wake latency is still musically acceptable?
  3. What is your degradation order under low battery?

5.4 Thinking Exercise

Create a per-component current budget and compare predicted vs measured current for each mode.

5.5 Interview Questions They Will Ask

  1. How do you design power modes for interactive instruments?
  2. Why is mode-based measurement better than single average current?
  3. How do you validate wake responsiveness objectively?
  4. How do brownout policies prevent corruption?
  5. Which tradeoffs were required to hit <5mA idle?

5.6 Hints in Layers

  • Hint 1: Define mode contracts before touching registers.
  • Hint 2: Gate one subsystem at a time and measure delta.
  • Hint 3: Build a fast wake path separate from cold boot path.
  • Hint 4: Automate repeated low-voltage test cycles.

5.7 Common Pitfalls and Debugging

Problem Why Fix Quick Test
Idle current too high forgotten peripheral clock full peripheral audit disable-by-disable current test
Wake feels sluggish heavy reinitialization on wake split quick-wake and full-init wake latency histogram
Corrupted state after low battery unsafe write under voltage sag BOD-gated transactional write repeated brownout write test

5.8 Definition of Done

  • Deep-idle current measured below 5mA target.
  • Wake p99 latency documented and acceptable.
  • Brownout tests complete with zero corruption.
  • Mode transitions and degradation policy are documented.

6. References