Movesense Sensor Power Optimization

This section contains information on:

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.

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.

(To keep device low power it is a good idea to disconnect bluetooth connection when not needed and optimize advertising settings.)

Adv. Fast Adv. Slow Connection (no data stream)
Min 156uA 7uA 86uA
Max 309uA 158uA 116uA
Avg 230uA 59uA 93uA

BLE current consumption chart

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

Measurement - example application flow

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. battery_characteristic_IR_to_percent.png 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 G1 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 1.9.3):

Mode
Sensor consumption when sensor INACTIVE (BLE advertising OFF):
Sleep 6
Idle, median 9
Idle, avg 18
-
Sensor consumption when sensor INACTIVE (BLE advertising ON):
Slow advertizing 24
Fast advertizing 92
BLE connection 44
-
Sensor consumption when sensor ACTIVE (BLE advertising OFF, no BLE connection):
Acc 13Hz 43
Acc 26Hz 45
Acc 52Hz 55
Acc 104Hz 74
Acc 208Hz 136
Acc 416Hz 252
-
Acc+Gyro 13Hz 224
Acc+Gyro 26Hz 236
Acc+Gyro 52Hz 260
Acc+Gyro 104Hz 305
Acc+Gyro 208Hz 424
Acc+Gyro 416Hz 605
-
Acc+Magn 13Hz 206
Acc+Magn 26Hz 213
Acc+Magn 52Hz 227
Acc+Magn 104Hz 255
Acc+Magn 208Hz 324
Acc+Magn 416Hz 448
-
HR 106
Led 600

Typical current consumption declared by sensor component manufacturers

Case Datasheet value [uA]
Acc 13Hz 10.0
Acc 26Hz 15.0
Acc 52Hz 25.0
Acc 104Hz 44.0
Acc 208Hz 85.0
Acc 416Hz 150.0
Acc+Gyro 13Hz 240.0
Acc+Gyro 26Hz 260.0
Acc+Gyro 52Hz 290.0
Acc+Gyro 104Hz 360.0
Acc+Gyro 208Hz 450.0
Acc+Gyro 416Hz 650.0
Acc+Magn 13Hz 260.0
Acc+Magn 26Hz 265.0
Acc+Magn 52Hz 275.0
Acc+Magn 104Hz 294.0
Acc+Magn 208Hz 335.0
Acc+Magn 416Hz 400.0