Movesense Sensor Power Optimization
This section contains information on:
- power saving features of the Movesense sensor
- average current consumption per feature
- Bluetooth current consumption
Overview
Movesense core software architecture has been designed to be asynchronous and event based. That naturally leads to good results for power saving under normal operation. If there are no active subscriptions, the processor sleeps and the sensor enters "power OFF" mode. The sensor will be enabled as soon as there is data request, either internally or over Whiteboard communication. While the basic architecture is designed for power saving, there are a few things that must be taken into account to achieve good power consumption figures.
Features and their power use
Movesense core library contains lot of different features and their individual power consumption varies. Some don't use any extra power when IDLE while others consume quite a bit. Following sections describe the power consumption impact of some of the most important Movesense features. Note: All power figures listed below are measured on the most recent Movesense software and hardware available in March 2018.
UART / serial communication
Movesense sensor supports serial communication via the debug pins on the PCB. These can be used with the Movesense programming JIG which maps to a normal USB serial port on computer. However, the UART is very power hungry even when not in use (about 1.2mA when IDLE). Therefore it makes sense to always disable UART when it's not needed.
Serial communication can be controlled in two ways:
- default factory settings for Movesense sensor disable serial communication. To enable serial, it needs to be turned on using Movesense Settings API. This acts as a master switch for serial communication
- application's App.cpp file also contains setting for turning serial communication on or off: SERIAL_COMMUNICATION(true | false). However, this application specific setting will not override the master setting controlled via Settings API
RTT debug log messages
Movesense software stack is configured to enable debug logging / tracing over RTT debug lines of the programming JIG.
RTT debug logs can be enabled by using debug variant of the Movesense library (use build switch -DCMAKE_BUILD_TYPE="Debug").
Running RTT terminal takes about 700uA, but if JLink is not connected it doesn't use extra power.
BLE Communication
Bluetooth communication is the most common way of receiving data from Movesense sensor. Since Bluetooth Low Energy (BLE) is one of the most power consuming peripheral it is good to use it only when needed. Note: Look into best practices chapter.
- BLE Advertising. There are two advertising types: fast and slow. Fast is turned ON when device boots up or after BLE disconnection and it is active for 1 minute. After that time device switch to slow advertising.
It is good practice to turn OFF advertising and disconnect with Bluetooth when not needed to reduce power consumption. Movesense API allow to turn on/off advertising with different settings
(example: After every hour turn on advertising, connect with BLE, send some calculated data, turn off advertising and disconnect)
There is also possibility to change advertising settings. Take a look into current table below - slow advertising average current consumption is 59uA. This is true only for default settings (default is: 500ms period). It could be changed for example to 1 second period to reduce current consumption.
Note: In areas with a lot of Bluetooth devices good pratice is to keep slow advertising at its default value. Slower advertising than 500ms can lead to jams because there are not enough time slots for all devices.
- BLE connection. While there is some difference between streaming big data and not sending any data during connection, even keeping the BLE connected uses quite a bit of power.
(To keep device low power it is a good idea to disconnect bluetooth connection when not needed and optimize advertising settings.)
| BLE Advertising Fast | 119.6 | | BLE Advertising Slow | 30.9 | | BLE Advertising Off | 10.5 | | BLE Connection | 88.5 |
Sensors
Different sensors use a different amount of power. Please look at the current consumption table on the bottom of this page. here
Current consumption reasults are calculated as a differential measurement of "Sensor on - Idle current" which means that precision of measurement depends on idle current stability (about +-2uA) as well as other fluctuation during measurement. If measurement was taken in long time avarage we can assume that idle = 10uA.
There is no possibility (Hardware limitation) to use magnetometer or gyroscope without turning on accelerometer. Accelerometer is responsible for data transfers from IMU.
Here is a simple diagram application flow to measure current consumption
Battery level measurements
There is a possibility to check battery level using Movesense API. Please notice that measurement method is based on voltage measurement under specific load. For most batteries it gives proper values only when battery is almost empty (last 20% or so). It is a good idea to use the measured battery level to inform end-users that battery needs to be replaced in couple of days. Battery level is provided in 10% steps except last 10% which are divide into 1% steps. For more information please refer to API documentation
For version 1.5.0 and higher:
There is new battery measurement method implemented in FW version 1.5.0. Capacity calculation is based on voltage and battery internal resistance. For this FW version path system/energy contains also internal resistance information provided in ohms. With every calculation, battery measurements accuracy is getting higher, so good practice is to measure battery periodically to have better view of battery capacity. New battery measurement utilizes different kinds of battery loads. In consequence a short LED's blink (about 20ms) can be noticed during battery level measurement.
There are two different ways of getting measurement. The first is to get or subscribe capacity from system/energy/level path. In this method real measurement will be trigered 10 minutes after last measurement. It is standard method to receive left battery capacity. Since battery measurement is using special load on it 10 minutes timer has been introduced to reduce power consumption. Battery measurement takes about 2mA during 40ms measurement. The second method (more precise) is to use get on path system/energy and receive battery capacity, actual battery voltage measured under load of 1.5mA and actual battery internal resistance in ohms. Using this system path is not blocked by any timer and there is a possibility to measure battery even several times per second.
To have the most precise values from battery, measurement has to be performed without any additional load. Good practice is to unsubscribe all power consuming features before getting battery level (example: accelerometer, gyroscope, magnetometer).
Example internal resistance characteristic. Data collected by Movesense by using get on system/energy every 10 seconds.
Note: Temperature and dynamic movements of Movesense (like hits and shakes) have big impact on battery voltage and internal resistance. Battery is using chemical processes to generate power and needs time to stabilize. As an example, new battery exposed to extreme low temperatures will behave as empty battery (in terms of voltage measurement), but internal resistance will show that it is full.
Battery warning subscription
It is possible to subscribe on system state called 'BatteryStatus' (system/states.yaml). During subscription system will constantly trigger battery measurement every 10 minutes and monitor battery behavior. Battery warning threshold is setup on 15% of battery capacity. For more information about how to subscribe to system states please refer to system states
Movesense sensor power consumption measurements
Table below provides current measurements for different sensor components at multiple sampling rates. Values are reported for most recent firmware (ESW) releases. All measurements were done with latest H1 hardware variant of Movesense sensor and values are reported in microamps (uA).
When estimating the current consumption of your own sensor application, please keep in mind that the extra current consumption caused by Bluetooth transmission is not taken into account in the figures below, unless explicitly mentioned in the Remarks column.
RESULTS (ESW version 2.2.0):
| Mode | Current [uA] | Change from 2.1.x [%] | |
|---|---|---|---|
| Sensor consumption when sensor INACTIVE (no BLE): | |||
| Idle (BLE advertising off) | 10.4 | ||
| -- | |||
| Sensor consumption when sensor INACTIVE (BLE advertising/connection ON): | |||
| BLE Advertising Fast | 128.1 | ||
| BLE Advertising Slow | 31.8 | ||
| BLE Connection | 96.8 | ||
| -- | |||
| Sensor consumption when sensor ACTIVE (BLE advertising OFF, no BLE connection): | |||
| Acc 13Hz | 46 | ||
| Acc 26Hz | 50 | ||
| Acc 52Hz | 60 | ||
| Acc 104Hz | 79 | ||
| Acc 208Hz | 144 | ||
| Acc 416Hz | 268 | ||
| -- | |||
| Acc+Gyro 13Hz | 227 | Acc is always enabled when Gyro is on | |
| Acc+Gyro 26Hz | 239 | ||
| Acc+Gyro 52Hz | 262 | ||
| Acc+Gyro 104Hz | 308 | ||
| Acc+Gyro 208Hz | 429 | ||
| Acc+Gyro 416Hz | 617 | ||
| -- | |||
| Acc+Magn 13Hz | 66 | -68 % | Acc is always enabled when Magn is on |
| Acc+Magn 26Hz | 88 | -59 % | |
| Acc+Magn 52Hz | 152 | -34 % | |
| Acc+Magn 104Hz | 259 | ||
| Acc+Magn 208Hz | 333 | ||
| Acc+Magn 416Hz | 466 | ||
| -- | |||
| ECG 125Hz | 138 | ||
| ECG 128Hz | 140 | ||
| ECG 200Hz | 157 | ||
| ECG 250Hz | 170 | ||
| ECG 256Hz | 171 | ||
| ECG 500Hz | 227 | ||
| ECG 512Hz | 230 | ||
| -- | |||
| HR | 106 | ||
| Led | 600 | ||
| - | |||
| Sensor consumption when sensor is in FullPowerOff mode: | |||
| FullPowerOff (no wakeup) | 5.19 | ||
| FullPowerOff (HR Wakeup) | 5.30 | ||
| FullPowerOff (Movement wakeup) | 9.40 | ||
Notes:
-
The accuracy of the measurements is about +-1 uA and repeatability +- 2%.
-
The accuracy of the measurements for spiking current (such as BLE Advertising) is about +- 10%.
-
The Change -column only includes cases where change was significant.