How we measured and optimized the power consumption of our IPS engine.
With the introduction of our smart workplace solution Senion at Work, our IPS is going from predominantly be used in the smartphones foreground mode, to the background mode.
In apps such as Mall of America and The Dubai Mall consumer apps, the IPS engine (the Senion SDK) is running at full speed when the users are using the app. Between app sessions, the SDK enters a standby mode where it’s not scanning for beacons, and consequently not consuming any battery.
In contrast to the apps mentioned above, the main features of Senion at Work depend on the smartphone constantly knowing where it is in the office. This means the SDK need to scan for beacons more or less continuously in order to update its position throughout the day. Since the SDK is running in the background for 8-10 hours a day it’s paramount that energy consumption is kept to a minimum.
Scanning for beacons?
In order for the smartphone to calculate its position, the Senion SDK uses the smartphone’s Bluetooth sensor to scan for nearby Bluetooth beacons. Different scanning strategies includes modifying variables such as how long and how often the SDK should scan for beacons.
Generally speaking, there is a trade-off between power consumption and responsiveness of the SDK. It’s possible to have ultra-responsive positioning performance but that would come at a high cost of energy. The opposite is also true, a near-zero consumption of power would lead to a dramatically drop in responsiveness. Our aim is to find the sweet-spot in between, an optimal balance between use of energy and responsiveness. To be a bit more exact, there are several sweet-spots. For example, when the user is moving more responsiveness is required. On the contrary, when the user is still we don’t need as many updates per second.
At any rate, in order to improve the power consumption, we first need to know the base line – how much the SDK is consuming in the background mode of a smartphone. The simplest and most rudimentary method of determining this is to simply let a phone run the SDK for a long while and for each set time interval, for example an hour, take note of the battery percentage left (as reported by the phone’s operating system).
However simple it may be, there are a few drawbacks with this method. Firstly, this method is imprecise in the sense that we can only measure in integer percentage points left in the battery. Secondly, it’s a quite tedious approach as it can take several hours to get enough data points to derive a measure of power consumption.
In order to get closer to the source, we designed and engineered a custom device for a more precise, continuous and quicker sampling of power consumption in smartphones. This is what it looks like:
With this Power Measurement Device (PMD) we can address all the flaws with the previous method. The device is connected between the smartphone and the battery which means it measure the power consumption in a granular and continuous manner. Measuring digitally also means we can study the data and plots with more detail. And last but not least, the feedback loop is drastically reduced.
Using the first simple method, it would take hours and hours to measure if a certain change in the beacon scanning strategy of the SDK had an actual effect on the consumption. In contrast, evaluating a new scanning strategy with the PMD cuts this time down from several hours to seconds.
As a result of this setup, we can dig closer to the real question; which underlying processes consumes the most power and why?
After trying out and evaluating several different approaches to the scanning strategies, we were able to reduce the power consumed by the IPS SDK (in background mode) with about 50%. While we can’t disclose the exact nature of our new improved power strategies, it’s sufficient to say that power consumption has been drastically reduced.
We can now confidently say that the energy used by our SDK is limited to a few percentage points over the course of a normal day. Obviously, mileage may vary since factors such as degraded battery health and/or older phone models both have a significant effect on the overall energy capacity in a smartphone.
* * *
While this research and corresponding results are based on iOS smartphones, we are currently looking into strategies for saving energy for Android devices running our SDK.
David Törnqvist, CTO and Co-founder
David received his PhD in 2008 and in his research, the main focus has been on statistical estimation and detection methods. Applications studied are Simultaneous Localization and Mapping (SLAM) as well as disturbances to inertial navigation systems.