One of the key performance criteria for a wearable or portable device is – normally – low power consumption so that the user does not have to frequently recharge the item. Whilst we may tolerate charging our phones nightly, evidence has shown there is little appetite for recharging a multitude of devices.
In this article, I also assume that the wearable device communicates wirelessly, as is the case for the majority of these items nowadays. Power management in such a device is tightly coupled with the management of the radio part, as the radio is going to be the most “expensive” item when it comes to the battery management budget.
Analysis of the use case
Fortunately for designers, there are wide range of low power microprocessor/radios that have a variety of power and sleep modes to help optimise the power drain. However, these need to be closely controlled by the application to realise the benefits.
The first step in designing a low power application is to carefully define the use case. A typical wearable will have various sensors connected to a microprocessor, and one or more radios to send the data on to a mobile phone, computer, or other custom hardware. Bluetooth Low Energy (BLE) is frequently one of or the only radio used to communicate.
Modes of operation
A modern Bluetooth device will consume most power when transmitting and receiving (say 5-10mA), less when the microprocessor is running with the radio shut down (2-3mA) and can drop to very low power if put into sleep mode (few uA). So, one of the first tasks in designing for low power is to analyse the modes of operation of the unit, and check if one mode will dominate the power consumption calculation.
To use a couple of examples, if one takes the simple Bluetooth “beacon”, this might send a short advertising pulse every second, and spend the rest of the time in sleep mode. Power consumption in this application will be totally dominated by Sleep mode current. Conversely a BLE audio application, transmitting audio to a headset, will have a highly active radio, and in this case the power consumption in “Radio-on” mode will dominate. A different type of application, say one reading and analysing complex sensor data, but only transmitting certain “alert” situations, might be dominated by the microprocessor mode.
Sleep Mode
Taking the different modes in turn, “Sleep Mode” will typically present several options. The most extreme is that you can shut down the entire system. However, you will need some external mechanism to wake it up again, and then the whole system must reboot from scratch. Whilst this could suit some applications, it would be far more typical to leave the real time clock running at some cost in power consumption, and have the system wake up on a timed basis. Further options include whether you retain data in RAM which will allow a faster restart at the cost of higher sleep current. Often you can selectively retain RAM blocks. So if the application only requires 16kB of RAM out of 64 available, for example, you may be able to only keep active the portion of RAM required.
Optimising the sleep state and wake up may therefore involve some calculations and prototyping, as the full picture can’t necessarily be covered by spec sheet numbers. For instance, the total charge used in different wake up modes may need to be measured. One further factor to be considered is that sleep currents are temperature sensitive. So, in the case of a wearable device, keeping the processor at room rather than body temperature could be significant. This is something that the physical design will need to address.
Microprocessor control
Modern microprocessors, even in small devices can have complex features. Much will depend on the individual device, but the processor clock speed can sometimes be varied, with implications for current consumption, and peripherals may be able to be switched on or off.
More advanced devices can be multicore, for example, with separate processors to control the radio, and to run the core applications, which can independently be put into sleep modes. This offers further flexibility, but will make the application design more complex, as the designer will need to determine which parts of the design run on which processor, with the different processors typically having different specifications.
Therefore, there can be several options to keep the microprocessor power consumption “budget” to a minimum. Good application design will have the microprocessor(s) running for the minimum time at the lowest power mode possible.
Radio activation
The largest power draw will occur when the radio is on. It is therefore essential to manage the radio connection to minimise consumption. Here, careful analysis of the use case is required. Firstly, how quickly does the wearable need to connect to its host? Is this a “background” activity or something noticeable by the user that will need to be prompt? What happens if the host is unavailable? Considering these aspects will determine how frequently the wearable tries to establish a connection and how it handles a failure to connect or a lost connection. The less often the radio is active, the lower the power consumption, but this must be balanced against the user experience.
Power levels on the radio are typically controllable. So, it is possible to adapt power levels depending on the proximity of the host. Operating a radio at maximum power will significantly increase the current consumption. So, a balance between reliability and power needs to be found. One additional issue with a wearable device is that the human body will significantly degrade the “over the air” radio performance. Whilst there is no magic solution to this, appropriate design can minimise the impact of the body, allowing radios to be operated at lower power.
The other aspect is to minimise the amount of data exchanged, therefore minimising the “radio on” time. Can the data be compressed or filtered? This will have a processing cost, to be balanced against a more limited radio transaction time This might need to be prototyped to be fully optimised.
Multiple radios
If we have a multiple radio device, for example, BLE and UWB (Ultra-Wide Band), or BLE and WiFi, typically the second radio will be much more power hungry than the BLE. The BLE device should therefore normally be used to control the connection and the overall system operation, switching on the other radios only when necessary.
Conclusions
To conclude, a typical wearable device will operate in a number of different “modes” over a standard usage cycle, and one or more of those modes might be significant in the overall power consumption. For each mode, there are a variety of considerations as to how to minimise power consumption, which need to be balanced with the user requirements of the device.
It is rarely enough to simply look at specifications to see how a device will perform in practice. To truly optimise the power consumption of a device, the designer needs to carefully study the specifications and options of the radio and processor elements and do some practical prototyping to measure the real-world impact of different design choices.
Author details: Dr Nick Wood, Sales & Marketing Director, Insight SiP
