Linköpings universitet
Linköping University | Department of Computer and Information Science
Bachelor’s thesis, 16 ECTS | Datateknik
2020 | LIU-IDA/LITH-EX-G--20/027--SE
What is draining the ba ery on
the PineTime smartwatch?
–
Final thesis
Vad tömmer ba eriet på PineTime-smartklockan?
–
Kandidatarbete
Lukas Berglund
Supervisor : John Tinnerholm Examiner : Jonas Wallgren
Upphovsrätt
De a dokument hålls llgängligt på Internet - eller dess fram da ersä are - under 25 år från publicer-ingsdatum under förutsä ning a inga extraordinära omständigheter uppstår.
Tillgång ll dokumentet innebär llstånd för var och en a läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och a använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrä en vid en senare dpunkt kan inte upphäva de a llstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För a garantera äktheten, säker-heten och llgängligsäker-heten finns lösningar av teknisk och administra v art.
Upphovsmannens ideella rä innefa ar rä a bli nämnd som upphovsman i den omfa ning som god sed kräver vid användning av dokumentet på ovan beskrivna sä samt skydd mot a dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens li erära eller konstnärliga anseende eller egenart.
För y erligare informa on om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years star ng from the date of publica on barring excep onal circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educa onal purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are condi onal upon the consent of the copyright owner. The publisher has taken technical and administra ve measures to assure authen city, security and accessibility.
According to intellectual property law the author has the right to be men oned when his/her work is accessed as described above and to be protected against infringement.
For addi onal informa on about the Linköping University Electronic Press and its procedures for publica on and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Abstract
Power management is an important part when developing a smartwatch to meet user expectations of battery lifetime and functionality. To develop a good power management structure, measurements of the device is crucial to understand the behavior and power consumption of hardware and software.
In this thesis, measurements have been made to hardware connected to the PineTime smartwatch to get knowledge of its behavior and power consumption. A structure for hardware and software was developed to enable the possibility to debug, flash, and perform measurements. The purpose of the measurements is to find possible areas of improvement that have the potential to lower the overall power consumption of the device. From the measurements, the st7789V display driver and the hardware design was detected to have a high power consumption. Bluetooth was also found to have an odd behavior in terms of power consumption. From these findings, suggestions on how to lower the power consumption are presented.
Acknowledgments
I would like to show appreciation for the help I received during the work of this project. John Tinnerholm and Jonas Wallgren from Linköping University for being my supervisor and examiner. From Endian Technologies AB, I would like to thank Tord Andersson who has been my supervisor and Albin Söderqvist and Benjamin Lindqvist for guidance and help with development.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vi
List of Tables vii
1 Introduction 2 1.1 Background . . . 2 1.2 Motivation . . . 2 1.3 Aim . . . 3 1.4 Research questions . . . 3 1.5 Delimitations . . . 3 2 Theory 4 2.1 PineTime . . . 4 2.2 Zephyr . . . 4 2.3 Energy efficiency . . . 5 2.4 Power management . . . 5
2.5 Power management in an Android smartwatch . . . 5
2.6 Energy hungry components of a smartwatch . . . 6
2.7 Power saving strategies . . . 6
3 Method 8 3.1 PineTime setup . . . 8 3.2 Experimental setup . . . 9 3.3 Method of measurement . . . 10 4 Results 12 4.1 Measurements . . . 12 4.2 Possible improvements . . . 16 5 Discussion 18 5.1 Results . . . 18 5.2 Method . . . 19
5.3 The work in a wider context . . . 20
6 Conclusion 21
List of Figures
3.1 The four debug ports (red) and the charging ports (blue) on the PineTime moth-erboard. . . 8 3.2 The position of the charging ports used to measure with Otii. . . 11
List of Tables
4.1 Benchmark measurements of the Experimental environment and the PineTime
Hypnos project. . . 12
4.2 Power consumption when connecting hardware to the SOC. . . 13
4.3 Power consumption when configuring hardware in prj.conf. . . . 13
4.4 Power consumption when implementing hardware in main.c. . . . 14
4.5 Power consumption when disabling hardware by software in main.c. . . . 14
Acronyms
BT Bluetooth. 7
CPU Central Processing Unit. 4, 6, 9, 10, 18 GND Ground. 9
IoT Internet of Things. 2 mA Milliampere. 12 OS Operating System. 4
RTOS Real time operating system. 4 RTT Real-time text. 11, 15
SOC System on a Chip. vii, 4, 5, 10, 11, 13, 14, 20 UI User interface. 6, 7
1
Introduction
This work summarizes a candidate thesis from Linköpings University that has been carried out at Endian Technologies AB. Endian Technologies is a company working with Internet of Things (IoT) in Gothenburg.
1.1 Background
Endian Technologies AB is a company in Gothenburg that designs and develops products and services for the connected world. They have recently started a proof of concept project to develop software for the PineTime smartwatch using Zephyr as the operating system. With the capabilities of the smartwatch, there are great opportunities to develop custom systems that fit different markets. The smartwatch is said to have a battery life of 7 days [1], but from experiences in the PineTime Hypnos project [2] that is not the case. From measurements on the current version [3], the battery life is experienced to be 22 hours instead of the claimed 168 hours. This is not optimal considering the potentials of this device and system. To find the source of the problem, measurements of the individual components and overall power consumption must be considered.
1.2 Motivation
For battery-driven devices in general, high power consumption has a bad impact on many things. The most obvious is the risk of downtime, perhaps more importantly the additional costs and the bad effect on the environment. With a high power consumption, a device needs to be charged more often, this means a higher number of charging cycles. Each charging cycle shortens the expected lifetime of a battery as a component [4][5]. So, with a higher number of charging cycles, the battery will wear out faster. The materials required in the making of a battery have a bad effect on the environment, with a high contribution to greenhouse gases [5]. To by a new one will impose a cost on the user, and with the hardware design of the PineTime smartwatch, it is hard to change the battery. So, if the battery dies the smartwatch dies.
The current version of the PineTime Hypnos project does not meet the expectations in terms of battery life. So, to have the possibility to continue the work, the problem with the
1.3. Aim
high power consumption needs to be identified and resolved. For that reason, measurements have to be made on both hardware and software to locate the source of the problem. The measurements will also be useful in the further development of the smartwatch.
1.3 Aim
This thesis aims to give an understanding of the power management structure in the PineTime smartwatch, show how hardware can be implemented and how it affects power consumption. This is done with the help of measurements on the overall and individual power consumption for hardware on the device. The purpose of the measurements is to show how power is distributed between components and based on these measurements find a set of possible improvements. The measurements will be performed using an Otii [6] (measurement unit) with code from a test environment that isolates individual components.
1.4 Research questions
The research questions for this thesis are based on performing measurements on the power consumption of the PineTime smartwatch, and to find areas that can be improved to lower the overall power consumption. The goal is to show how components affect the overall power consumption in different use cases.
The questions this thesis will answer are:
1. How can a good test-bed for hardware and software on the PineTime smartwatch be developed to enable the possibility to do power measurements?
2. What is the overall and individual power consumption by hardware on the PineTime smartwatch in different use cases?
3. Based on measurements, what areas of improvements can be found that have the poten-tial to lower the overall power consumption?
1.5 Delimitations
For this thesis, some delimitations were made to be able to focus on the research questions. • Measurements will only be made to usable hardware on the PineTime
smart-watch. The heart rate sensor can only take part in the hardware-related measurements
due to a proprietary driver, witch is not supported by Hypnos.
• Five different test cases with a sufficient number of measurements will be
made to each hardware. This is to limit the number of measurements and to get
data that is relevant to each other.
• Prioritize measurements, defer improvements. The main purpose of this work is to do measurements and to locate possible areas of improvement. Some improvements may be made, but considering the complexity of the system most of them will be left as future work.
2
Theory
To perform power consumption measurements on a device, it is necessary to have basic knowledge of how it works and why it is important. This chapter presents the concepts that
are related and important to this work.
2.1 PineTime
PineTime is an open source development kit smartwatch that is capable of running self made and custom built operating systems. The devices have a System on a Chip (SOC) design where most of the components can be found on the same board using the same Central Processing Unit (CPU). The SOC is an nRF52832 general purpose multiprotocol design from Nordic Semiconductor with high functionality and low power consumption. The CPU belongs to the ARM Coretex-M family and is developed to be efficient with energy and resources. It has an CPU speed of 64MHz, access to 64 KB RAM, and 512 KB flash.
2.2 Zephyr
The task of an Operating System (OS) is to manage a system combined with hardware and software. Operating systems can be found in many forms depending on the task and the purpose of the system. Linux, Windows and macOS are operating systems that often can be found in computers for daily use. The PineTime smartwatch on the other hand, can only run a lightweight operating system due to the limitations on memory, CPU speed and amount of power. Zephyr is a Real time operating system (RTOS) that can be applied to resource-constrained and embedded devices, including the PineTime smartwatch.
Power management on Zephyr is designed to be independent of the knowledge of which SOC it runs on. This is done with the use of a smart device tree that describes the hardware, for pin position and connection of any usable device, instead of having a description for all devices. This simplifies the implementation process of a component.
2.3. Energy efficiency
2.3 Energy efficiency
Energy efficiency is one of the main parts of a good power management structure [7]. The power management structure has the purpose to manage power across a device, intending to be energy efficient and to use as little energy as possible for a task [8]. To achieve this goal, all waste of energy must be found with the help of measurements and eliminated by modifying hardware and software. Waste of energy can be described as the extra amount of energy consumed by a system when performing a non-optimal task.
In battery driven devices, higher power consumption means more charging cycles. A charg-ing cycle is the process of chargcharg-ing a battery when required. Each chargcharg-ing cycle affects the health of a battery, so a large quantity of charging cycles have a bad impact on the lifetime of a battery [4][5]. Replacing the battery on devices is in some cases possible, but in other not. On the PineTime smartwatch it is close to impossible to change the battery without technical knowledge. The materials required in the making of a battery have a bad effect on the environment, with a high contribution to greenhouse gases [5].
Work has been done on optimizing the energy use in a system. Ikeyama et al. [9] have done a work to try and lower the energy use in food plants, Liu et al. [10, 11] have successfully designed a structure that will save energy in an Android smartwatch by modifying the behavior of functionality.
2.4 Power management
Power management is one of the most important aspects in the development of a device [12][13][11][14]. The structure is part of the operating systems with the purpose to allow users and programmers, to control how power is distributed across the system, without affecting the performance [15]. Controlling power means to control when a function is enabled and disabled based on if the functionality is performing a task or not. This also applies to hardware connected to the system if it has access to the same power resource. For example, a component that is connected to a system is disabled when there is no work to be performed, and enabled when there is work to do.
Zephyrs power management subsystem provides the possibility to take full advantage of the power saving strategy on the SOC, with the use of APIs. The structure is divided into three parts [16].
1. Tickless Idle. This is an event-based power saving strategy that is divided into two modes. When at least one thread is active the system runs on timer intervals, but when no work is scheduled and no threads are active, the timer disabled to save power. 2. System Power Management. This part decides how power management is handled
when the kernel has no work to perform and has entered the idle state. In this case, sleep states are useful to lower the power usage by the system. Two kinds of sleep states can be selected with the difference of allowing the system to lose execution context, or not, during the sleep period.
3. Device Power Management. This part decides how power management handle de-vices on the system. This is done by assigning dede-vices to different power management aliases depending on what state they are in and the purpose of the work.
2.5 Power management in an Android smartwatch
Liu and Qian [10] have in their research measured and optimized the energy use of an Android smartwatch. The data for the tests and development was collected from 30 smartwatches on daily use to get a real understanding of the power consumption. Before any modifications of
2.6. Energy hungry components of a smartwatch
the smartwatch, they observed three things standing out when it comes to power management. The two first observations are related to the display and illustrate how it makes up the largest part of the power consumption when the screen is active and inactive. The third represents a comparison between the smartwatch and a smartphone, where the observations are that the radio, Bluetooth and WiFi, for the smartwatch has a much smaller effect on the power consumption compared to the smartphone. The authors propose some improvements to make the smartwatch more energy efficient. Considering that the screen stands for the largest portion of the power consumption for the smartwatch, an improvement is needed. The first suggestion is to use and inform about a power friendly design for the User interface (UI). For an o-led display, as in this case, a darker UI is more power friendly than a bright one. The second suggestion is to optimize and lower the time the smartwatch display is enabled by changing the behavior for the display. The last suggestion is to send notifications to the smartwatch in a chunk, to reduce the total power consumption for managing notifications.
2.6 Energy hungry components of a smartwatch
A smartwatch is known for having a display, fast CPU, and a small battery. Compared to a smartphone, the battery of a smartwatch is usually more than ten times smaller, making the total amount of available energy limited. Still, smartwatches are expected to have long battery life.
Liu et al. [10] have done a study to show the usage of a smartwatch in the wild. The energy hungry components for a smartwatch are mostly the same as for a smartphone, because of the similarity of components and usage. In the study, the authors discover that the screen stands for the largest impact on power usage. This is the same discovery as Liu and Qian’s [11] made in their work of an Android smartwatch. The reason why the display uses a lot of energy is related to the behavior and the size of the component. The display of an Andriod device is enabled in two out of three states, not including the charging state, which is the awake and dozing state. The awake state is when the device is fully awake and can interact with the user. In the dozing state, all applications are suspended but the user can still see the time with a simplified timer interface on the display. The dozing state itself stands for 50.6% of the total power use making it the most power consuming state, while the awake state stands for 27% power use with only 2% awake time. The overall power consumed by the display is 30% over all states.
The second most energy hungry component is the CPU [10]. In the dozing or sleep state the CPU has a low power consumption, though in the active state the power consumption is higher. The overall consumption of the CPU is 29% with most of the power used in the active state.
Compared to smartphones, the radio of a smartwatch does not have a big impact on the overall power consumption. This is mostly because of two reasons. The first reason is that the amount of data transferred is a lot less and in smaller volumes. The second reason is that most of the smartwatches are not equipped with a cellular interface, which is more energy hungry than other radios. Smartwatches are instead using short-range radio to communicate, such as Bluetooth or WiFi. The radio on a smartwatch stands for 3.4% of the overall power consumption.
The components identified with high power consumption are Display, CPU, and Radio (Bluetooth/WiFi).
2.7 Power saving strategies
Liu et al. [10, 11] propose some techniques on how to save energy in a smartwatch based on measurements of the most energy hungry components. The proposed improvements are listed below:
2.7. Power saving strategies
1. Reduce the awake time. By default, the awake time for the Android smartwatch is 5 seconds. This can be reduced by lowering the default value to x < 5 seconds or by developing a smart sensor function that, based on the movement of the watch, can turn it on or off. Using a timer from 1 to 4 seconds the total saving is between 4-9%, which in time equals 1.7 to 3.8 hours depending on the usage.
2. Improve the sleeping mechanism. The smartwatch is consuming the least amount of energy when in sleep mode. It is therefore important to use sleep mode as frequently as possible. By default an Android smartwatch enters sleep mode after an idle period of 35 min. This can easily be modified to a timeout time of, for example, 5 to 10 min and will give a total power saving of 9-13%, which equals 3.8 to 5.4 hours in total time savings.
3. Energy efficient User interface (UI). Considering that the display stands for 30% of the total power consumption, there is room for improvements. This can be done by finding a combination of display brightness and UI colors that will lower the total power consumption. For the Android smartwatch a color transformation to black and red results in reducing the wake-up display energy by 41.4%.
4. Delay-tolerant push notification. Notifications sent from the smartphone can be bundled together and delayed to lower the awake time of the radio (Bluetooth (BT)), with the effect of a lowered power consumption.
3
Method
This chapter describes the method used to answer the research questions. First the structure for the measurement method on hardware and software is described. Then a description of
how the measurement methods are performed is presented.
3.1 PineTime setup
Figure 3.1: The four debug ports (red) and the charging ports (blue) on the PineTime moth-erboard.
When working with hardware, it is essential to have a good test-bed that is user-friendly and durable. To achieve this test-bed with the ability to flash, debug, and do measurements,
3.2. Experimental setup
some hardware modification was made on the PineTime smartwatch. The smartwatch is equipped with 4 debug ports, in the order SWDIO, SWDCLK, 3.3V, and GND, that can be found under the battery. A cable was attached from the debug ports to the corresponding outputs on a J-Link EDU mini [17] to be able to flash and debug. To make the structure even stronger, some holes were drilled in the chassis for the cables to run through. It is now possible to connect the smartwatch to a computer with the ability to flash and debug, but in order to do measurements some further modifications were needed. To get the possibility of doing measurements, two cables, 5V and Ground (GND) were connected to the charging ports, found on the right side of Figure 3.1. These were later connected to the Otti Arc [6] for performing measurements.
3.2 Experimental setup
The purpose of the environment is to do measurements of hardware on the PineTime smart-watch, where each hardware can be implemented separately. The environment itself is the most power-efficient implementations for the PineTime smartwatch, making it the benchmark for the lowest possible power consumption. At startup, the CPU enters idle mode to be power efficient.
Listing 3.1: Code from the experimental setup.
#include <zephyr . h> void main ( void )
{
//
// Add code h e r e f o r i m p l e m e n t a t i o n and e n a b l e d / d i s a b l e hardware // b e f o r e t h e CPU e n t e r s i d l e mode . // while ( t r u e ) { k_cpu_idle ( ) ; } }
3.3. Method of measurement
In the experimental environment Listing 3.1, software for the specific measurement is imple-mented before the CPU enters idle mode. This ensures that the individual power consumption from a measurement is the difference between the benchmark and current consumption, with no effect of other functionalities. The measurement parts are divided into different use cases in order to simulate all possible scenarios and to make it easier to find areas that can be improved. The experimental environment is the foundation for each measurement to build upon.
1. Connected. Some of the hardware has a physical connection to the SOC that that can be easily detached. In this test, hardware will individually be disconnected and connected again to see the effect on power consumption.
2. Configuration, no implementation. When building a Zephyr application, the com-piler needs to know which hardware and functionality the program is expected to use to get access to them. This is done with the use of a provided configuration file called
prj.conf, in the Zephyr environment. The measurement in this part is supposed to show
whether or not the included driver is optimal, by measuring the hardware before and after it is configured in the configuration file.
3. Configuration and implementation. This part use the configuration from the previ-ous part and combines it with implementing hardware in the software with the provided functionality from the driver. The purpose of this test is to see if implementing but not enabling hardware will affect power consumption.
4. Hardware disabled by software. The purpose of this test is to see how disabling hardware by software will affect power consumption. This is done using the disabling functionality from the provided driver. This part is important for developing an idle mode with lower power consumption.
5. Hardware enabled by software. When hardware is enabled by software, it is active and ready to be used. This is the most power-consuming state and can be seen as the awake mode. Measurements will be made on the hardware when it is enabled by software and active.
The division of the measurements is designed to make it easier to understand the behavior of power consumption for each hardware and to gain knowledge on how possible improvements can be made to lower the power consumption. If possible, improvements will be made on the implementation of the hardware. Otherwise the knowledge will be used to create improvement proposals for future work.
3.3 Method of measurement
The measurements are performed using an Otii Arc [6] as the measurement tool. Otii Arc is a small device, connected to a computer, that can supply power for a device and measure its power use. The measurement of the PineTime is performed on the 5V charging port, with the battery disconnected, to receive a true power use for the whole device.
3.3. Method of measurement
Figure 3.2: The position of the charging ports used to measure with Otii.
3.3.1 Hardware to measure
In the design of the PineTime smartwatch, some components have an external connection to the SOC while the other has a permanent connection. The measurements will be performed on the hardware and functionalities listed below.
• Display (LCD, st7789V) • Backlight (st7789V) • Touch (CST816S)
• Bluetooth (bluetooth 5 LE) • Logging (Real-time text (RTT)) • Heart rate sensor (HALS3300)
Note: The heart rate sensor can only take part in the hardware-related measurements and not in software-related ones due to a proprietary driver. The backlight and display are from the same component but have there own connections to the SOC and driver. Hence the measurements are separated from each other.
4
Results
This chapter presents possible improvements and outlines the measurements described in the method chapter.
4.1 Measurements
Before the individual measurements of hardware, two benchmark measurements of the Pine-Time smartwatch are made. The first is to show the lowest possible power consumption, with disconnected hardware running the software from the experimental setup. The second bench-mark measurement is the actual power consumption of the PineTime Hypnos project as it stands right now with functionality for the display, touch, battery, button, and Bluetooth.
Benchmark measurements
Measurement Idle mode (mA) Awake mode (mA)
Test environment 0.899 0.899
PineTime Hypnos project [2] 8.57 16.30
Table 4.1: Benchmark measurements of the Experimental environment and the PineTime Hypnos project.
4.1.1 Connecting
In this test, the software used is the benchmark described in section 3.2. When measuring the individual power consumption each hardware is separately connected and disconnected from the smartwatch. By using the benchmark measurement and the new measurement, the actual power consumption of each hardware is calculated.
Not all components can be physically disconnected from the device. The accelerometer sensor, vibrator actuator, and Bluetooth cannot be disconnected. They are therefore attached to the device for all measurements, including the benchmark.
The overall power consumption is the total amount of power used in the whole device, and individual consumption is the calculated power consumption for specific hardware in relation to the benchmark Table 4.1.
4.1. Measurements
Measurements of connecting hardware
Measurement Overall consumption (µA) Individual consumption (µA)
Benchmark 899 899
Backlight 914 15
Display and Touch 907 8
Heart rate sensor 1010 111
Everything connected 1040 141
Table 4.2: Power consumption when connecting hardware to the SOC.
The test shows that the hardware design of the PineTime smartwatch has room for im-provement, Table 4.2. Each component has direct access to the power source, regardless of the CPU:s awareness. An experimental measurement was made on a Nordic development board using the same SOC, nRF52832, but with no connected components. The purpose of this experiment is to see the power consumption from the SOC alone running the same code. This measurement showed a power consumption of 242 µA.
4.1.2 Configuration
In this test, measurements are made on the selected hardware when it is configured in the Zephyr configuration file. The configuration file proj.conf is used by the compiler to know which dependencies and drivers the system is requiring. It is important to have a correct configuration for the system to work.
The purpose of this test is to show if the included drivers, for each hardware, are optimal and have a suitable implementation. A non-optimal driver can affect the functionality and power consumption of hardware.
From now on, all components are connected to the device to give a true and realistic power consumption. So the benchmark for the remaining parts represents the lowest power consumption when everything is connected to the device (subsection 4.1.1).
Listing 4.1: Example from prj.conf in Zephyr.
# # Example c o n f i g u r a t i o n i n p r j . c o n f # CONFIG_SPI=y CONFIG_DISPLAY=y CONFIG_ST7789V=y CONFIG_ST7789V_RGB565=y
Listing 4.1 is an example of how configuration is made in prj.conf using Zephyr. The configuration in this example enables the use of the display and the driver st7789V.
Measurements of configuring hardware
Measurement Overall consumption (µA) Individual consumption (µA)
Benchmark 1040 1040 Display without st7789V 1040 0 Display with st7789V 4030 2990 Backlight 1040 0 Touch 1050 10 Bluetooth 1040 0 Logging 1040 0
4.1. Measurements
Power consumption should not increase when components are configured. However, if that is the case, something is wrong with the included driver. Most measurements in Table 4.3 show no effect on the power consumption of the device, only the measurement of Display with
st7789V show a significant increase.
The display attached to the PineTime smartwatch is an st7789V, which has its driver separate from the general implementation of a display in Zephyr. For that reason two mea-surements are made to the configuration of the display, one with the driver for st7789V and one without, to show the behavior of both drivers.
4.1.3 Implementation
In this test, measurements have been performed on hardware when they are connected to the SOC, configured, and implemented in the software. Implemented, in this case, means that the hardware is initialized and ready to be used but has not been enabled or disabled by software. Each measurement is separated from each other and only the required configurations and implementations are included.
Measurements of implementing hardware
Measurement Overall consumption (µA) Individual consumption (µA)
Benchmark 1040 1040 Display without st7789V 1040 0 Display with st7789V 6510 5470 Backlight 7290 6250 Touch 1040 0 Bluetooth 1180 140 Logging 1040 0
Table 4.4: Power consumption when implementing hardware in main.c.
In this test (Table 4.4), the Display with st7789V and Backlight stands out with high power consumption. It seems like the backlight is enabled when implemented because of the screen lighting up. The display, using st7789V, is not enabled by default.
4.1.4 Disabled by software
The hardware is ready to be used by the software when connected and configured. To lower the overall power consumption, components, and functionalities that are not in use should be disabled by software and enabled again when expected to be used. This is a good practice for minimizing energy wasted in a system.
In this test, measurements have been made on hardware when these are disabled by software to see whether or not the power consumption is lowered as expected.
Measurements of disabling hardware by software
Measurement Overall consumption (µA) Individual consumption (µA)
Benchmark 1040 1040 Display without st7789V 1120 80 Display with st7789V 6500 5460 Backlight 1040 0 Touch 1050 10 Bluetooth 1180 140 Logging 1040 0
4.1. Measurements
With the hardware disabled by software, the backlight and touch functionalities are dis-abled as expected, resulting in almost no individual power consumption (Table 4.5). However, the driver for the display once again has a high power consumption. This time with power consumption that is five times higher than the combined consumption for all other measure-ments.
4.1.5 Enabled by software
The earlier measurements are important for developing a low idle mode power consumption. The opposite of idle mode is when the device is fully awake and ready to be used, this is the awake mode and it stands for 2% of the usage period [11].
In this test, measurements have been performed on hardware to see the power consumption when awake and used by a user. Each measurement is separate from each other and the hardware is configured, implemented, and enabled by software. This test is showing the highest amount of energy consumed by hardware.
Measurements of enabling hardware by software
Measurement Overall consumption (µA) Individual consumption (µA)
Benchmark 1040 1040 Display without st7789V 1120 80 Display with st7789V 7150 6110 Backlight 7290 6250 Touch 3630 2590 Bluetooth 1130 90 Logging 4350 3310
Table 4.6: Power consumption when enabling hardware by software in main.c.
The measurement Display without st7789V is not important in this test and may give a faulty reading considering that the display needs the st7789V driver to work.
How the measurements were made in Table 4.6:
• Display with st7789V: This measurement shows the power consumption of the dis-play, using the driver for st7789V when it is enabled by software. Before entering sleep mode in main.c the display was configured, implemented, and enabled using the included functionalities from the driver. This made the power consumption constant making it easy to get a good reading.
• Backlight: The backlight can be described as an illumination behind the display to light up the content printed by the display functionality. Without the backlight it is impossible to see anything on the display. The measurement of the backlight was performed in the same way as with the display.
• Touch: When pressing on the display an interrupt will activate the touch functionality for around 2 seconds. To measure the maximum power consumption of the touch func-tionality, reading is performed on the 2-second interval. Five measurements were made to get the average reading from the intervals.
• Bluetooth: In the Bluetooth measurement, the smartwatch is connected and paired to a smartphone. The reading is the power consumption from when the smartwatch and smartphone is paired together.
• Logging: Logging is necessary when developing software for the smartwatch, but it is important to disable when not needed, to save power. In this project an Real-time text (RTT) J-link EDU mini, connected to the smartwatch debug ports section 3.1, was used
4.2. Possible improvements
to flash and debug. For this measurement the smartwatch is printing log messages from
main.c to a Linux command line RTTLogger using the J-Link described in section 3.1.
4.2 Possible improvements
With input from the measurements some problems in the power management structure have been identified.
4.2.1 Display driver
The largest problem for not reaching a low power consumption on the PineTime smartwatch is caused by the driver for the display (st7789V) not being optimal. The driver cannot fully disable the display by software, which alone makes the overall power consumption high (sub-section 4.1.4). To find a solution to this problem, an experiment was performed on modifying the driver. The goal was to find a way to implement the ability to fully disable the display.
In the driver for the st7789V display, two functions are responsible for enabling and disabling the display st7789v_blanking_on disables the display and st7789v_blanking_off enables it. By default, these functions are using ST7789V_CMD_DISP_ON and
ST7789V_CMD_DISP_OFF as aliases to turn the display on and off. Considering that the measurements show no difference in the power consumption when using the
ST7789V_CMD_DISP_OFF alias and the fact that the datasheets [18], for this
dis-play, refers to it as a power saving strategy something must be wrong. An experiment was performed to see the effect of using sleep alias instead of the default display aliases. The alias ST7789V_CMD_SLEEP_IN was used to let the display into sleep mode and
ST7789V_CMD_SLEEP_OUT together with ST7789V_CMD_DISP_ON to exit sleep
mode. The experiment was successful, showing the potential of lowering the idle mode power consumption of the PineTime smartwatch. With this approach, the overall idle mode power consumption is lowered from 7150 µA to 1040 µA for the st7789V display without sacrific-ing functionality. To convert the experiment into a correct implementation for the st7789V driver, a more advanced approach is needed. This experiment was performed together with Albin Söderqvist [19][20].
Helped by the measurements in this work, Albin Söderqvist was able to resolve the problem with the excessive power consumption of the display by patching the driver. His patch is now included in upstream Zephyr and can thus be used by any Zephyr project. [16][19].
4.2.2 Hardware design
The second problem is caused by the hardware design of the PineTime smartwatch not being optimal. When a component is connected to the device, it has direct access to the power resource, which implies that components are using power regardless of the CPU:s awareness. This is obvious in the test where hardware is connected to the device (subsection 4.1.1), and for the fact that the power consumption on the developing board is 4.3 times lower running the same software. With this hardware design, it is difficult to reach a really low power consumption because no matter how optimal the software is, the hardware is always going to consume the same amount of energy. Power domains could be the solution to this problem. A power domain divides a system into different areas to get the possibility to manage the power supply for these areas. The control of power can be done by adding digital switches between the hardware and power resource.
4.2.3 Bluetooth behavior
The Bluetooth functionality is energy efficient through all tests. But still, an odd behavior has been found using the software from the PineTime Hypnos project [2]. The Bluetooth
4.2. Possible improvements
functionality is supposed to use less power when disabled by software, but this is not the case. It is using more power when supposed to be power efficient. A solution to this could be to always have the Bluetooth functionality enabled, but this feels like the wrong solution. Given the small change in power consumption with this odd behavior, no further investigation has been made.
4.2.4 Heart rate sensor
Having components connected to the smartwatch that cannot be used is pointless. The heart rate sensor has a driver that is proprietary, which means that it cannot be used in this project. In the connecting measurement (subsection 4.1.1), the heart rate sensor was found to have the highest individual power consumption of all components. This means that it will use power when connected, even if it is implemented and used in the software or not. So with that in mind, a smart way to save 111 µA of power is to disconnect the heart rate sensor from the smartwatch.
4.2.5 Backlight
The backlight shows no odd behavior in the measurements but has a high power consumption when activated. The high power consumption is probably related to the brightness level of the backlight. From the software in the PineTime Hypnos project, only one brightness level is considered. In the documentation for the PineTime smartwatch [21], three brightness levels should be possible to use. So, to solve the problem with the high power consumption of the backlight when activated, the three brightness levels should be considered. To see the effect on the power consumption measurements and experiments must be performed on the brightness levels. This part is left for future work.
5
Discussion
This chapter discusses the method and results of this work and how it can be put in a wider context.
5.1 Results
The purpose of this thesis is to get an understanding of the power consumption for hardware on the PineTime smartwatch and use the knowledge to develop power friendly software. The measurements are separately made in an enclosed environment to minimize the risk of error. This is the first work to show the power consumption of hardware connected to the PineTime smartwatch, so before the measurements were made it was hard to know what to expect. Instead, with the knowledge from previous work [10] [11], the expectations were that the display and radio would have high power consumption, but that was not all true. From the measurement of the PineTime Hypnos project, it was obvious that something was wrong considering the significant difference in the power consumption compared to the benchmark measurement.
5.1.1 Measurements
Among other things, it was found that the hardware design has a flaw that allows components to have direct access to the power resource. From a power management perspective, this is not an optimal design considering that the CPU cannot control where energy is spent and by which component. The solution to this could be to redesign the hardware or add switches between components and the power resource that the CPU can control.
From the measurements of the software (subsection 4.1.2 - subsection 4.1.5), the driver for the display st7789V is the component with the highest power consumption. It seems like the functionality, in the driver, that is supposed to disable the display is incomplete and sub-optimal. This is obvious in the measurement of disabling hardware by software (subsec-tion 4.1.4) where all components except the display were able to provide a low power con-sumption. An experiment was made to find the problem, and if possible correct it. Finding the source of the problem was considerably easy. It turned out to be caused by a sleep alias that did not work as intended. When changing this alias to another sleep alias, the power consumption dropped. The problem was located and a possible improvement was found.
5.2. Method
The measurements show that the power consumption for the radio is low. Usually, the radio stands for a large part of the power consumption in a device, considering the energy needed to turn the radio module on [11]. But in this case, the radio (Bluetooth) was one of the most power efficient components through all measurements, even in awake mode. This is probably favored by this smartwatch being equipped with a low energy Bluetooth [21]. From the measurements an odd behavior in the power consumption was detected for the Bluetooth functionality. Strangely enough, Bluetooth uses more power when implemented or disabled by software than when enabled by software. As the Bluetooth functionality was deployed in the PineTime Hypnos project [2], it is using less power when advertising than not. But considering the small effect on power consumption, no further investigation was made.
Without the help of measurements the problem with the Bluetooth, display, and hardware design would never have been found.
5.1.2 Possible improvements
Given that the battery life is 22 hours for the PineTime Hypnos project, it was essential to find areas that can be improved to lower the high power consumption. The possible improvements observed with the help of measurements should all be able to lower the individual and overall power consumption. The software related improvements should be considerably easy to fulfill, but the hardware related is more complicated. Modifying hardware is more complex than modifying and testing software. To solve the problem with components having direct access to the power resource it is necessary to redesign the hardware structure. For that reason, it is easier to solve the software related problems. With a power consumption of 1040 µA when all components are connected to the PineTime smartwatch, it is possible to reach a battery life of around 170 hours. This is calculated by dividing the power usage (1040µA) with the battery capacity (180 mAh). By solving the software related problems and disconnecting the heart rate sensor, it should be possible to get close to the claimed battery life of 168 hours.
5.2 Method
The method part described how to perform measurements on the PineTime smartwatch to answer the research questions.
5.2.1 Test-bed
The modifications to the hardware worked out well. The test-bed was strong, practical, and still allowed you to wear the smartwatch on your wrist. The button, that is connected to the battery, turned out to be crucial for software development as the system sometimes needed a hard reset to work. The principle of the software environment is to use a minimal amount of code on the same foundation for each measurement. This worked well when doing experiments, but it was sometimes hard to minimize the amount of software needed. In some cases, it was difficult to know exactly what code was necessary for a specific test, so there is a small risk that more software than needed was included. Regardless of this risk, the internal validity should be rather high because measurements have shown that software not related to hardware is not affecting the power consumption. Before measurements, the implemented code had to be verified to ensure that everything was working as intended. This was done using the logger and other hardware to test the implementation. The extra software needed for testing was later removed before the measurement was made. For example, the backlight had to be enabled to test that the implementation of the display was working.
The software and hardware modifications described in this work should allow other people to receive the same result from measurements, as long as the same hardware and software are used. The PineTime Hypnos project is an ongoing project. In order to receive the same result, it is crucial to use software from the same git commit [3].
5.3. The work in a wider context
5.2.2 Division of measurements
The division of the measurements made it easier to find odd behaviors and areas that can be improved. Having measurements related to hardware and software was the right thing to do, considering that problems were located in the hardware and software design. The selected measurements in this work are designed to match the research questions and the PineTime smartwatch. This means that the division of measurements are unique to this work and may not be suitable for other devices.
The measurements for enabling and disabling hardware by software are also essential in the development of an idle and awake mode in future work. These measurements show the behavior, in power consumption, of hardware when they are expected to be enabled or disabled.
5.2.3 Hardware to measure
Measurements were performed on all essential components and functionalities of the PineTime smartwatch. The selection of hardware was straightforward. All components except the vibra-tor were selected because, as it stands right now, it is not included in the PineTime Hypnos project. But, it would still be helpful to know the behavior of the vibrator for the future development of the smartwatch. So, the principal made in this work can be used to perform the same measurements on the vibrator.
5.3 The work in a wider context
Power management is an important part when developing devices today, so a lot of the knowl-edge from this work can be put in a wider context. Not only the measurements and the test-bed but the knowledge of how to do measurements and why it is important. Without measurements, it is impossible to know and understand how power is distributed between processes and components. This was the case before the measurements were made on the PineTime smartwatch, nobody knew of how power was distributed and the effect of the power management structure.
With the help of measurements, possible improvements have been proposed with the pos-sibility to lower the overall power consumption. One can learn from someone else’s mistakes. The possible improvements in this work can be taken into consideration when developing other similar systems to reduce the risk of making the same mistake.
Components on the PineTime smartwatch, including the nRF52832 SOC, can be found in other devices and systems. The measurements in this work show the actual behavior and power consumption for individual components and drivers. This means that the measurements are not unique to the PineTime smartwatch. The component will have similar behavior and power consumption in other systems when using the same driver.
6
Conclusion
The purpose of this work was to use measurements to show how different components impact the overall and individual power consumption on the PineTime smartwatch, and based on the result find areas of improvement. With this in mind, it is time to conclude this work based on the research questions.
1. How can a good test-bed for hardware and software on the PineTime smartwatch be
developed to enable the possibility to do power measurements?
This question is answered in section 3.1. Modifications to the hardware that enables the possibility to flash, debug, and do measurements were successfully and deployed. 2. What is the overall and individual power consumption by hardware on the PineTime
smartwatch in different use cases?
Measurements on the overall and individual power consumption can be found in sec-tion 4.1. Measurements were made on Bluetooth, Display, Logging, Backlight, and Touch in five different use cases that simulate different behaviors in the functionality. The five measurements were Connecting, Configuration, implementing, disabled by soft-ware, and enabled by software and were performed a sufficient number of times to receive a credible value.
3. Based on measurements, what areas of improvements can be found that have the potential
to lower the overall power consumption?
An investigation to answer this question have been done in section 4.2. The measure-ments showed that the hardware design, Display driver, and Bluetooth functionality have the potential to be improved because of high individual power consumption and odd behaviors.
For future work, more experiments can be performed on the identified problems from this work. A successful experiment was performed on the problem related to the display driver. But to reach a really low power consumption, the hardware must be modified. This can probably be made in the ways described in subsection 4.2.2.
Bibliography
[1] “PineTime”. In: url: https://www.pine64.org/pinetime/ (visited on 03/23/2020). [2] “PineTime Hypnos project”. In: url:
https://github.com/endian-albin/pinetime-hypnos (visited on 05/08/2020).
[3] “Current version of the Hypnos project”. In: url: https://github.com/endian-albin/ pinetime-hypnos/commit/c55151b23e610e7725bb248a9a9ad27cce8e9880 (visited on 04/23/2020).
[4] Sheng Shui Zhang. “The effect of the charging protocol on the cycle life of a Li-ion batter”. In: Journal of Power Sources 161.2 (2006), pp. 1385–1391. issn: 0378-7753. doi: https : / / doi . org / 10 . 1016 / j . jpowsour . 2006 . 06 . 040. url: http : / / www . sciencedirect.com/science/article/pii/S0378775306011839.
[5] M.C. McManus. “Environmental consequences of the use of batteries in low carbon systems: The impact of battery production”. In: Applied Energy 93 (2012). (1) Green Energy; (2)Special Section from papers presented at the 2nd International Enery 2030 Conf, pp. 288–295. issn: 0306-2619. doi: https://doi.org/10.1016/j.apenergy. 2011 . 12 . 062. url: http : / / www . sciencedirect . com / science / article / pii / S0306261911008580.
[6] “Otii”. In: url: https://www.qoitech.com/ (visited on 05/12/2020).
[7] Horace Herring. “Energy efficiency—a critical view”. In: Energy 31.1 (2006). The Second Biennial International Workshop ”Advances in Energy Studies”, pp. 10–20. issn: 0360-5442. doi: https://doi.org/10.1016/j.energy.2004.04.055. url: http://www. sciencedirect.com/science/article/pii/S0360544204002427.
[8] F. Katiraei and M. R. Iravani. “Power Management Strategies for a Microgrid With Multiple Distributed Generation Units”. In: IEEE Transactions on Power Systems 21.4 (2006), pp. 1821–1831.
[9] T. Ikeyama, H. Watanabe, S. Isobe, and H. Takahashi. “An approach to optimize energy use in food plants”. In: SICE Annual Conference 2011. 2011, pp. 1574–1579.
[10] Xing Liu and Feng Qian. “Measuring and Optimizing Android Smartwatch Energy Con-sumption: Poster”. In: Proceedings of the 22nd Annual International Conference on
Mo-bile Computing and Networking. MobiCom ’16. New York City, New York: Association
for Computing Machinery, 2016, pp. 421–423. isbn: 9781450342261. doi: 10 . 1145 / 2973750.2985259. url: https://doi.org/10.1145/2973750.2985259.
Bibliography
[11] Xing Liu, Tianyu Chen, Feng Qian, Zhixiu Guo, Felix Xiaozhu Lin, Xiaofeng Wang, and Kai Chen. “Characterizing Smartwatch Usage in the Wild”. In: Proceedings of the
15th Annual International Conference on Mobile Systems, Applications, and Services.
MobiSys ’17. Niagara Falls, New York, USA: Association for Computing Machinery, 2017, pp. 385–398. isbn: 9781450349284. doi: 10.1145/3081333.3081351. url: https: //doi.org/10.1145/3081333.3081351.
[12] Manish J. Gajjar. “Power management”. In: url: https://www.sciencedirect.com/ topics/computer-science/power-management (visited on 05/11/2020).
[13] Xiaomeng Chen, Ning Ding, Abhilash Jindal, Y. Charlie Hu, Maruti Gupta, and Rath Vannithamby. “Smartphone Energy Drain in the Wild: Analysis and Implications”. In:
SIGMETRICS Perform. Eval. Rev. 43.1 (June 2015), pp. 151–164. issn: 0163-5999. doi:
10 . 1145 / 2796314 . 2745875. url: https : / / doi - org . e . bibl . liu . se / 10 . 1145 / 2796314.2745875.
[14] Songtao He, Yunxin Liu, and Hucheng Zhou. “Optimizing Smartphone Power Con-sumption through Dynamic Resolution Scaling”. In: Proceedings of the 21st Annual
International Conference on Mobile Computing and Networking. MobiCom ’15. Paris,
France: Association for Computing Machinery, 2015, pp. 27–39. isbn: 9781450336192. doi: 10.1145/2789168.2790117. url: https://doi.org/10.1145/2789168.2790117. [15] “Techopedia explains Power Management”. In: url: https://www.techopedia.com/
definition/2116/power-management (visited on 05/11/2020).
[16] “The Zephyr Project”. In: url: https : / / docs . zephyrproject . org / latest / reference/index.html (visited on 05/12/2020).
[17] “J-Link EDU Mini”. In: url: https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/ (visited on 05/09/2020).
[18] “Datasheets for st7789V”. In: url: https://www.newhavendisplay.com/appnotes/ datasheets/LCDs/ST7789V.pdf (visited on 05/13/2020).
[19] “Albin Söderqvist from Endian”. In: url: https://github.com/endian-albin (visited on 05/08/2020).
[20] “Improvement for display driver”. In: url: https : / / github . com / endian - albin / pinetime-hypnos/issues/29 (visited on 05/07/2020).
[21] “PineTime wiki”. In: url: https://wiki.pine64.org/index.php/PineTime (visited on 03/23/2020).
