Začíname už za

Low Power

Created by Miroslav Biňas / mirek

### IoT Challenges * security * ergonomy * technologies for communication * low energy

### Low Power

### Device as Electric Circuit 

### Operating Cycle 

### Instantaneous Current 

### Charge per Operating Cycle 

### Electric Charge $$ Q = \int_0^T i(t) \mathrm{d}t $$ * $Q$ – electric charge (mAs, mAh) * $i(t)$ – instantaneous current * $T$ – length of operating cycle

### Battery Life dependes on * battery capacity * device consumption


### Battery Capacity * the energy stored in a battery * measured in either watt-hours (Wh), kilowatt-hours (kWh), or ampere-hours (Ahr) * the number of hours for which a battery can provide a current equal to the discharge rate at the nominal voltage of the battery Notes: * http://pvcdrom.pveducation.org/BATTERY/capacity.htm

### Real Battery Capacity depends on * **discharge current** – the higher the current, the lower the capacity * Energizer EN91 (AA): ~2850 mAh at 25 mA, ~1400 mAh at 500 mA * **cut-off voltage** – the device may stop working sooner * **temperature** – the capacity drops in the cold

### Rechargable Batteries * self discharge over the time * **don't use them in your _IoT_ solutions!**

### Undervoltage (Brown-out) * battery voltage drops under load due to its **internal resistance** * Energizer EN91 (AA): 150–300 mΩ, increases while discharging * voltage below the MCU minimum → **reset** or unpredictable behavior * typical symptom: random resets when connecting to **WiFi**

### Preventing Undervoltage * **brown-out detector** in the MCU keeps it in reset * capacitor near the communication module * battery with low internal resistance * measure battery voltage, limit activity when low

### Average Current and Battery Life $$ \bar{I} = \frac{Q}{T} \qquad t = \frac{C}{\bar{I}} $$ * $\bar{I}$ – average current * $Q$ – charge per operating cycle * $T$ – length of operating cycle * $C$ – battery capacity

### Battery State Why should the device know its battery state? * to **report** that the battery needs to be replaced * to **limit its activity** when the battery is low

### Battery Discharge Curves 

### Battery Reporting * send battery state as a **metric** (V or %) * **low** battery – warn, keep working * **critical** battery – limit activity (longer interval, no flash writes) * use several measurements or **hysteresis**

### General Approaches for Low Power * when **designing software**, and * when **designing hardware**

### Additional Low Power Approaches * lower power supply (at least _3.3V_) * lower the work of microcontroller (e.g. sleep mode, frequency) * use CMOS with low power when idle

### Power Consumption of CMOS $$ P \approx C \cdot U^2 \cdot f $$ * $C$ – capacitance of switched circuits * $U$ – supply voltage * $f$ – clock frequency

### Energy per Message | Technology | TX current | Time to send a message | Sleep between messages | |:----------------|:----------:|:---------------------------:|:----------------------:| | WiFi | high | long (connect, IP, TLS) | no (reconnect) | | BLE | low | very short | yes | | Zigbee | low | short | end devices only | | LoRaWAN | high | short, rare messages | yes | | NB-IoT / LTE-M | high | medium | yes (PSM) |

### Managing Energy Consumption with Software

### Motivation

 – Donkey, _Shrek 2_ (2004)

### The Polling > Actively sampling the status of an external device by a client program as a synchronous activity. > ([Wikipedia](https://en.wikipedia.org/wiki/Polling_%28computer_science%29))

### Features of Polling * simple, sufficient for most problems * high potential of data loss * synchronous activity - needs more resources


### The Interrupts > Interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention. > ([Wikipedia](https://en.wikipedia.org/wiki/Interrupt))

### Polling vs Interrupts * **polling** – *software* repeatedly asks, whether the event occurred (synchronous) * **interrupt** – *hardware* lets the microcontroller know about the event (asynchronous)

### Similar Approaches * event-driven architecture * event-driven programming * _Observer_ design pattern

### Reasons to use Interrupts * **immediate reaction** – no missed events * **CPU is not busy** with polling * **energy saving** – interrupt wakes the MCU up from sleep

### Interrupt Service Routine > An interrupt service routine (ISR) is a special block of code associated with a specific interrupt condition. > ([Wikipedia](https://en.wikipedia.org/wiki/Interrupt_handler))



### ISR Features * no return value * no params * only way, how to communicate with the rest of the system from within ISR, is with *global variables*

### Recommendations for ISR When writing an _Interrupt Service Routine_ (ISR): * Keep it short * Don't use `delay()` * Don't do serial prints * Make variables shared with the main code `volatile` * Variables shared with main code may need to be protected by _"critical sections"_ * Don't try to turn interrupts off or on

### Types of Interrupts * **hardware** interrupts * **external** (pin change) – button, rotary encoder, PIR sensor, RTC alarm * **internal** – timers, watchdog, UART/SPI/I²C, ADC * **software** interrupts – triggered by a special instruction

`pin.irq(trigger, handler)`


### Timer > In computing and in embedded systems, a programmable interval timer (PIT) is a counter that generates an output signal when it reaches a programmed count. The output signal may trigger an interrupt. > ([Wikipedia](https://en.wikipedia.org/wiki/Programmable_interval_timer))



### Low-Power Modes > (Low-power modes) are designed to reduce power consumption when the chip doesn’t need to operate at full capacity. They do this by turning off certain parts of the chip while keeping others running. > > — [Last Minute Engineers](https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/)


## Questions?

 (**http://bit.ly/2u1sPBh**)