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
Top Related