Power Budgeting for Battery IoT: Keep Radios Running

Your sensor is dead in the field. Again. You budgeted for two years of operation, but the device lasted eight months. The culprit? Radio transmission consumed far more power than the datasheet promised, and you never accounted for duty cycle reality.

Power budgeting for battery-operated IoT devices isn't optional—it's the difference between a working system and an expensive brick. The radio is almost always the power hog, and understanding how to constrain it is fundamental to shipping products that actually stay deployed.

The Radio Reality Check

Datasheet specifications lie by omission. A LoRaWAN module might consume 120 mA during transmission and 8 µA in sleep mode. Sounds great until you realize your device transmits every 5 minutes, not every 24 hours. Suddenly that "efficient" module burns through a battery in months.

Start with the brutal math:

pythonCopy
# Simple power budget calculation
tx_current_ma = 120  # Transmission current (mA)
tx_duration_ms = 100  # Time on air per message (ms)
rx_current_ma = 15   # Receive window current (mA)
rx_duration_ms = 200  # Listening window (ms)
sleep_current_ua = 8  # Deep sleep current (µA)

# Cycle time
cycle_seconds = 300  # Transmit every 5 minutes

# Energy per cycle (mWh)
active_time_s = (tx_duration_ms + rx_duration_ms) / 1000
active_energy = (tx_current_ma + rx_current_ma) * active_time_s / 3600
sleep_time_s = cycle_seconds - active_time_s
sleep_energy = (sleep_current_ua / 1000) * sleep_time_s / 3600

total_per_cycle_mwh = active_energy + sleep_energy
monthly_mwh = (total_per_cycle_mwh * 24 * 30)

print(f"Monthly consumption: {monthly_mwh:.2f} mWh")
print(f"2500 mAh battery life: {2500 / monthly_mwh:.1f} months")

That 5-minute interval might look reasonable on a feature list. Mathematically, it's your enemy.

Practical Constraints

Interval Discipline

Don't negotiate with physics. If your application can tolerate 15-minute intervals instead of 5, battery life jumps 3x. Document the interval as a hard constraint from day one. At LavaPi, we've found that a single product requirement change—"measure every 5 minutes instead of 15"—has destroyed more battery budgets than any hardware miscalculation.

Start conservative. You can always increase transmission frequency if users demand it. You cannot recover battery life after manufacturing.

Transmit Power Tuning

Radios let you dial down transmission power. A 20 dBm transmission uses roughly 4x the energy of 10 dBm, but you might still reach your gateway. This is site-dependent, not universal.

typescriptCopy
// Example: LoRa power control (Semtech SX1276)
const setTransmitPower = (dbm: number): void => {
  // Typical range: 2–20 dBm
  // Every 3 dB reduction ~ 50% power savings
  if (dbm < 2 || dbm > 20) {
    throw new Error('Invalid power setting');
  }
  
  const paConfig = 0x80 | ((dbm + 3) & 0x0F);
  writeRegister(0x09, paConfig);
};

// Use lowest power that maintains coverage
setTransmitPower(10);  // Often sufficient

Measure RSSI (Received Signal Strength Indicator) at your gateway. If you're seeing -80 dBm with 20 dBm transmit power, try 10 dBm and measure again.

Sleep States Matter

Deep sleep is non-negotiable. A microcontroller drawing 100 µA in "idle" mode will drain a battery in weeks. You need genuine sleep—CPU off, oscillators off, memory retention only.

bashCopy
# Verify sleep current with a multimeter
# Place device in deep sleep mode
# Measure current between battery and device
# Should read single-digit microamps, not milliamps

The Real Constraint: Your Protocol

Many standard protocols demand receive windows. LoRaWAN requires the device listen for 1–2 seconds after every transmission. NB-IoT has similar overhead. You cannot escape this without changing protocols entirely.

Accounting for these windows is non-optional. They're often a larger power sink than transmission itself.

Close the Loop

Power budgeting isn't a prediction exercise—it's a constraint you enforce. Document your assumptions, test prototypes in the real deployment environment, and measure battery voltage every week for at least a month. The gap between theory and practice will teach you things no datasheet can.

Getting this right means your devices stay in the field. Get it wrong, and you're replacing batteries in Year 1 instead of Year 2.