Power consumption characterization

cc1350lp deadleaf

Method

• Stock cc1350 Launchpad• Stock Thingsquare fw v2.0.1• High-side shunt resistor for

current measurements• 10 ohm, 0.1%• Measure voltage drop across ->

current through U=IR

DUT

Vcc

Method

• Shunt voltage drop -> current. Current * input voltage = power. Power * time = energy.

• Mostly interested in blunt approx relative impact, not absolute numbers

• So, shortcut: voltage drop integrated over time for comparison per event (”one LED blink vs one BLE tx”). Divide with the period for comparison over time (”halving the period gives room for...”)

Cc1350 Launchpad

JTAG, UART, power jumpers• remove all except RST (needed for operation)• Connect RX to GND (to avoid spurious UART rx interrupts)• Connect to GND and 3.3V from external, low-noise PSU

• With shunt resistor in series, high-side

Error sources• Low oscilloscope resolution (8 bit, picoscope 3206b), while

interesting range is 10uA to 100mA (100uV to 1V)• Very low voltage drop over R – signal to noise not very nice• Difficult zero-offset calibration, and drifting• Hard to correlate observed events to the corresponding

event in the firmware• EMI and current peak suppression capacitors reduce

accuracy and smoothes out mainly fast, low-energy events (low-pass filter)

• Again, noisy

unbonded

CC1350LP unbonded, deadleaf• Before bonding with a gateway• Energy is conserved mainly through radio

power cycling• When bonded, will connect to remote server• When done, will enter deadleaf mode• Verify radio (duty cycling, BLE), find and

identify possible energy spenders

CC1350LP unbonded, deadleaf• Power consumption, P, is sum of– Static draw– BLE beacon transmissions– Radio wakeups/channel sampling– CPU wakeups for various reasons– LEDs and indicators– Others, eg sensors (none in this case)

10k mile view, 2+0.125 secondsvery noisy

Same, but more signal filtering(zoom slightly different though)

Static draw, CPU short/long, channel sample

• Channel sample: 8 ms, 90 mV -> 720, period 125ms -> 5.76• BLE: 22.2 ms, 20.6 mV -> 457.32, period 1000ms -> 0.457

No, that’s not really correct – from later measurements, BLE does not take that long

First, a channel sample (red)Then, we should sleep but the next timer timeout is too soon, so can’t do deep sleepFinally, BLE beacons on three channels, then deep sleepThus: BLE: 17 ms, 20.6 mV -> 350.2, period 1000ms -> 0.350

LED: 125 ms, 25-ish mV -> 3125, period 2000ms-> 1.5625

Long CPU wakeups, not very strict periodCa 7ms, ca 10.4mV->72.8, ca 100ms -> 0.728

Very short CPU wakeups0.8ms, 24.83 mV, -> 19.86424 on 2500ms, so 100ms-ish -> 0.19864

– Static draw, ca 100uA– Channel sample 720/5.76– BLE 350/0.350– LED 3125/1.5625– Long CPU 72.8/0.728– short CPU 19.9/0.199

due to imperfect o’scope zeroing, noise, etc the values are not comparable with later measurements, just within this particular.

Eg, “how does a BLE tx compare to a LED blink” in terms of power consumption.-> no LEDs -> four times as many beacons on the same power budget.What are the long CPU wake-ups? Impact > 2*BLE.

Impact comparison tableper event/with current periodicity

bonded, steady-state

Behavior is now more conservative• P is sum of– Static draw– BLE– Master polling– Mucha synching– Sensor value/nw stats transmissions– LEDs– Others, eg sensors (none in use here)

Before – waiting for bondradio duty cycling, BLE beacons, LED blink every 2s, CPU wakeups

During bonding – TLS connection

After bond – much quieter

Bonding: broadcast with wake-up frames

Bonding: tx packets (fragments), rx ACK

Bonding, deadleaf conditions fulfilledTransition to steady-state

Before – after(improper zeroing on oscilloscope)

Steady-state, mostly CPU wakeups

Large spikes, period 400 ms, mucha

Mucha wake-up compared to other wake-ups3.9ms, 58.33mV-> 227.5; 400ms -> 0.56875

Differences across BLE events21.1, 20.78, 28.75, 28.71 mVDue to noise? Static draw shifts due to caps and leakage? ....?

Corresponding duration for the event17.03, 17.21, 16.85, 16.85 msDifferent time to boot up and stabilize RF?359.3 to 483.8, 1000ms -> 0.36 to 0.48

BLE and mucha timers, then little elseBLE red, mucha green

Send-event (master poll)

Blue are radio wakeups

Static power draw

Static power draw

• Extremely low, if nothing is running• Here, at least timers are running• Very easy to misconfigure (GPIOs, timers, serial

hw peripherals etc) and get leakages in hundreds of uA, to mA even

• For low-sendrate applications, static draw can be the largest energy spend

Static power draw

• Method: measure with DMM when device is in deep sleep

• Device enters deep sleep as part of normal operations, if the next wake-up is far enough away– Takes time to wake up, hence can’t sleep if too close

• Here, tweak fw: when steady state, turn all timers off (mucha etc) so they don’t disturb the measurement

• Result: ca 50-100uA

Conclusions• Behavior is verified, the firmware is behaving as

intended– Radio is shut off accordingly, state transitions, timer

timeouts reduced etc etc• Room for improvement– Mucha timers in steady-state– Use of LED– CPU spikes when unbonded

• But not present when bonded, which is the most important case

Conclusions• Impact comparison numbers, making it easier

to tune the application at hand– Eg decrease channel sampling rate to gain power

budget means to blink more, or vice versa• Static power draw confirmed low– Perhaps the most important factor for long

battery-sourced lifetime