Functionality vs. Size of Wearables
Updated: Feb 9
Options for Power Optimization One of the big debates that makers of smart wearables engage in frequently is on the size versus functionality issue. There is an ongoing trend wherein a reduced size and extended battery life seem to be the norm, and any wearable improving upon these will have a leg up on the competitors. While there is definite appeal to a smaller form factor and less frequent charging need , it does put some constraints on the output from the wearable and how broad a canvas is available to the makers for future development. This is where the conversation shifts to the cloud and how potent a tool it can be, provided it has the right input parameters. But before we delve into the role of cloud, let us unpack the methods by which devices can achieve a smaller form factor and a longer operating time. If the functionality is to stay the same, the primary way to reduce the form factor is by reducing power consumption, and hence the required battery size. The other option is to use components (processor, clock, memory, sensors…) which have substantially lower form factor and power consumption. The latter is addressed by wearable makers by using the most power and size efficient state-of-the-art components. Selection of these size and power efficient components levels the playing field and shifts the focus to tweaking the operation of the devices to achieve size and power optimization. Duty Cycle
An important term to understand when we think about methods of power saving is 'duty cycle'. Duty cycle is simply the duration for which the device is operating in its normal mode(regular power consumption) relative to the total operating time. As an example, if the device is operating in normal mode for half the time and goes into a power saving mode(PSM) for the remaining half, the duty cycle is 50 percent. Similarly, if the device operates for one fourth the time in normal mode and goes into the PSM for the remaining three-fourth duration, the duty cycle equals 25 percent. The reason duty cycle becomes an important parameter is because a reduction will directly translate to a decrease in the overall power consumption, allowing the use of a smaller battery in an application. Below is an example of how these calculations work. Let us assume a device uses a Lithium polymer battery of 100 milli-Ampere-hour(mAh) capacity at 3.7 Volts. In the normal operating mode, let us assume the device consumes 10 milli-Amperes(mA) of current. Below is the equation to derive the operating time of the device. 100 mA x 1 hour = 10 mA x operating time Operating time = 10 hours Now let us introduce a power saving mode in which the device only consumes 1 mA. If we alter the duty cycle to 50 percent, it will mean the device is consuming 10 mA half the time. For the other half, the current consumption is only 1 mA. We can derive the operating time again as shown below 100 mA x 1 hour = 10 mA x 0.5 x operating time + 1 mA x 0.5 x operating time Solving the above we get, operating time = 18.18 hours The big takeaway from the above example is that a change in duty cycle and implementation of the PSM can radically alter the operating time of the device. We can change the percentages and even the current consumption values in the PSM to arrive at longer operating time periods. The above might seem like a very appealing prospect, and in many cases it indeed is. When we look at some of the well-known wearables out there in the market, the primary method of operation will have the device being active and collecting data only when some motion (accelerometer + gyroscope) threshold value is reached. The radio technology (mostly Bluetooth Low Energy), being used for synchronization of data, will activate occasionally to send data in bursts to keep the duty cycle at a low value. This is the main reason why despite the use of sensors and radios that normally consume a lot of power relative to the low capacity batteries in wearables, the operating time of these wearables still extends to days and sometimes weeks. This is also the reason why a majority of the consumer fitness wearables will focus on only the basic motion related data and its derivatives. Their focus is mostly on capturing the peaks when a user is undergoing some motions like walking, running, climbing, and working out. The data is then translated into metrics like steps, distance covered, flights climbed and maybe calorie count. Similarly, no, or minimal motion can easily be used for sleep tracking.
The common feature observed is the implementation of the power saving mode when there is lack of noticeable data peaks that would yield useful outputs. To understand the extent to which the threshold based activation is effective in power saving, all we need to do is monitor the motions of our wrist, chest, waist or wherever the device is worn and observe the frequency at which there is noticeable motion that could be deemed worth recording. The results might be surprising to some as you will notice that most time of an average user falls below the motion threshold. This verifiable fact related to lack of frequent motion is the main factor allowing the wearables to operate at extremely low average power consumption and low data requirements. Cloud If the focus is completely on size and operating time, the above methods will seem very appealing and always preferable. However, it does introduce a downside, limiting the extent to which data can be used from the devices. The big advantage that cloud computing provides users is with running complex machine learning and AI models that can churn out useful insights. The input data required to run those models has to be consistent and at a high frequency. As an example, for a data model to detect activities like bending or twisting and break them down based on angles and speed, the data from the motion sensors must be collected at a frequency of 10-20 Hz or else the activity can be missed. This is where the wearables operating in power saving modes will fail. Implementing the power saving mode would take a few milliseconds in entering and exiting the mode, and considering 10-20 data points are required per second, there could be loss of data which would affect the efficacy of the data models. Conclusion Ultimately it boils down to a matter of preference and use case. If all that a user requires is basic motion related data and the derivatives of it like walking, running, calorie burn and additional data like heart rate, the power saving modes can be implemented. Only motion above a certain threshold will be captured and the low duty cycle will result in major power savings. Similarly, for the heart rate, considering that in static modes the variations are minimal, collecting it once every few minutes is acceptable. The result will be a device with a small form factor and a long operating time. On the other hand, if the goal is to delve into some deeper insights and allow for future flexibility, it would require moving data to the cloud at a specific frequency without interruptions. This can allow the user to run multiple data models and heuristics. With the cloud, in addition to deriving metrics beyond what are available in the commercial wearables, there will be options to try new things all the time and expand the insights to improve the fitness, safety, and productivity of the users.