How to Design Low-Power Always-On Wearables: Part 3 – Optimizing Bluetooth Wireless Connectivity
Original Title：How to Design Low-Power Always-On Wearables: Part 3 – Optimizing Bluetooth Wireless Connectivity
Editor’s note: This is Part 3 of a three-part series on designing battery-powered always-on wearable electronics, focusing on three areas in which to optimize for power. Part 1 described how to configure the microcontroller to extend battery life and reduce recharges. Part 2 looked at how to safely maintain the battery to extend time between recharges. Here, Part 3 examines wireless networking for wearables and how to optimize the wireless connection for low power.
Wearables push the limits of designers’ abilities to optimize for space and low power. Every square millimeter matters and every wasted milliamp contributes to shorter battery life, leading inexorably to a poor user experience. One of the major battery drains on a wearable is the wireless interface, and many solutions are emerging to help designers minimize its drain on the battery.
This article discusses how wireless connections work for a wearable and how to configure the wireless interface to minimize battery drain. It then examines wireless chips from Dialog Semiconductor and discusses how to properly configure a Bluetooth connection for a wearable.
Wireless communications in consumer wearables
Wearables for consumers typically connect to a mobile device running an app developed by the manufacturer. Although wearables can operate independently from a connected mobile device, the most common mode of operation is to synchronize with a mobile device at a set interval whenever it’s within range. This synching does not need to be real time, which is a critical factor in power optimization.
For example, a fitness wearable synchs data with the app, including a log of heart rate, steps, and distance over time. Even if the user is exercising, this data does not need to be real time. An update interval of from one to five seconds can be acceptable, and often the interval can be configured by the user. The wearable also receives alerts from the mobile device, including incoming calls and text messages. These alerts are on-demand and only occur when needed.
There are many wireless interfaces designers can use for connecting to a wearable, but for the sake of interoperability few can compete with Bluetooth, which provides a direct connection between the wearable and the mobile device. Wi-Fi can also be used to connect the wearable device to the internet when the mobile is out of range. The wearable can then be configured to connect to a public or any other network that it is authorized to access. Data can then be exchanged bidirectionally. For example, data can be transferred from the wearable across the Wi-Fi network to the wearable manufacturer’s cloud, from where it can be sent over the cellular network to the mobile device. At the same time, the mobile device can be updating the wearable on relevant local conditions as well as email or text notifications.
As Wi-Fi is rare in a wearable due to the added power and cost involved, and since wearables are almost always near their paired mobile device, this article will focus on Bluetooth.
Bluetooth for wearables
Bluetooth was originally developed for peer-to-peer connections for the streaming of data at a data rate of 1 to 3 megabits per second (Mbits/s). This original Bluetooth specification today is known as Bluetooth 3.0, or Bluetooth Classic. While these early versions of Bluetooth were useful for streaming audio and multimedia files, their design was too power hungry for intermittent, low data rate, low-power control signals and sensor data. For these applications, Bluetooth 4.0 was developed.
Now widely known as Bluetooth Low Energy (LE), Bluetooth 4.0 can transfer data as slow as 125 kilobits per second (Kbits/s). In addition, Bluetooth LE chips spend most of their time in sleep mode, drawing minimal power until needed. This is perfect for a low-power wearable with a small battery.
To implement a Bluetooth LE radio on a wearable, a developer can either use a microcontroller with an integrated radio, or use an external radio. The system requirements determine which can be the lowest power option.
For example, if the Bluetooth LE radio is integrated as a peripheral in the microcontroller, it can save precious pc board space. However, it does require the microcontroller to be at least partially powered to allow the radio peripheral to operate.
Alternately, the Bluetooth LE radio can be external to the microcontroller. While this requires additional pc board space, it has the advantage of requiring only the radio chip to be active while the microcontroller can be in a low-power mode. This also has the added advantage of a modular approach to the wearable design. This allows the host microcontroller to be swapped out for a more powerful one in a new design while the Bluetooth LE radio chip remains the same. It can also speed the design cycle since the Bluetooth radio and stack does not need to be coded into the microcontroller.
Using an external Bluetooth chip
An external Bluetooth chip for a wearable should have a simple interface to the microcontroller that does not add significantly to the power consumption and should also be able to wake up the microcontroller from a sleep state. One device suitable for wearables is the Dialog Semiconductor DA14585 Bluetooth SoC shown in Figure 1.
The DA14585 is based on an Arm® Cortex®-M0 core that runs out of 128 kilobytes (Kbytes) of factory programmed ROM. It also contains 64 Kbytes of one-time programmable (OTP) memory for customization. This allows the development of custom Bluetooth application firmware for the DA14585. This firmware can also access the additional on-chip peripherals, including:
A four-channel 10-bit analog-to-digital converter (ADC) that can be used for battery monitoring
A quadrature decoder can be used to interface to a three-axis human interface device (HID) such as a step counter with direction
A keyboard controller peripheral can be used for connecting to and debouncing push buttons
Figure 1: The Dialog Semiconductor DA14585 is a complete Bluetooth SoC solution with a full Bluetooth 5.0 stack, a 2.4 gigahertz (GHz) radio transceiver, and additional hardware to customize a Bluetooth peripheral. (Image source: Dialog Semiconductor)
The DA14585 also integrates a 2.4 GHz transceiver, baseband processor, and a qualified Bluetooth LE 5.0 stack to minimize the time a developer has to spend learning the nuances of Bluetooth semiconductor design. It supports up to eight simultaneous Bluetooth LE connections, although a wearable typically requires only one.
The chip can connect to a microcontroller using a UART, SPI, or I2C interface. While the device includes default firmware for host communications, for a more efficient wearable system design, Dialog supports developer customization of host communications using the on-chip OTP. The UARTs support data rates of up to 1 Mbit/s with hardware flow control, so the host microcontroller must support a compatible UART interface.
The DA14585 is also small. It comes in a 34-pin WLCSP that is only 5 millimeters (mm) x 5 mm giving it a minimal board footprint. It has a profile of 0.9 mm, making it suitable for ultra-slim wearables.
The Bluetooth LE core and stack are fully compliant with Bluetooth specification v5.0 (Figure 2). One advantage to having the stack in the DA14585 instead of the microcontroller is when the Bluetooth specification is updated, Dialog can simply update the stack in the DA14585. The wearable will still function as before, while the developer has the option to update the host microcontroller application firmware to take advantage of any changes in the specification.
Figure 2: The Dialog Semiconductor DA14585 requires minimal external components. It implements a complete Bluetooth v5.0 core and radio so that the developer does not need to learn the details of building a Bluetooth semiconductor solution. (Image source: Dialog Semiconductor)
The Bluetooth radio requires few external components. It supports all Bluetooth device classes and packet types. In addition, the radio can be powered down to save energy. It is seen as an AHB-bus peripheral by the Cortex-M0 core.
Dialog Semiconductor also has the DA14586, which has the same ROM, OTP, and peripheral set as the DA14585, but with the addition of 2 Mbits of flash memory. While flash memory can be programmed many times and OTP only once, OTP consumes significantly less power compared to flash. The DA14585 also operates from 0.9 to 3.6 volts, while the DA14586 requires 1.8 to 3.3 volts.
Implementing a low-power Bluetooth wearable
The Bluetooth core on the DA14585 has two modes of operation: Active and Deep Sleep. While in Active mode, the radio is transmitting and receiving across the Bluetooth wireless connection; Deep Sleep mode disables the core and optionally removes power from the radio. Because a wearable is at best a near real-time device, to save power the core and radio can be programmed for a periodic sleep and wakeup event.
For example, the Bluetooth core can be programmed to go into Deep Sleep for a period of time, then wake up to Active, manage any messages or notifications to or about the user (i.e. emails, heart rate updates), then go back to Deep Sleep. The period of this cycle is up to the developer. The longer the core is in Deep Sleep the more battery power is saved; however, too long a Deep Sleep can result in delayed Bluetooth messages. The core can be programmed to be in Active mode longer to reduce latency and response times, but this will consume more power. The developer should experiment with different Deep Sleep and Active mode periods to optimize the power versus response time for the best user experience.
The main Arm Cortex-M0 processor for the DA14585 supports four power modes: Active, Sleep, Extended Sleep, and Deep Sleep. Note that these power modes are not to be confused with the Bluetooth core power modes—the Bluetooth core can be in its Active mode while the Arm core and peripherals are in their own Extended Sleep mode.
In Active mode the Arm core and peripherals are all powered and active. This is the mode the DA14585 is in during an active Bluetooth data connection. In Active mode, with the DA14585 powered by a 3 volt supply, the device draws 5.3 milliamps (mA) while receiving, and 4.9 mA while transmitting.
In Sleep mode the Arm core is idle, but its state is retained. This saves power when the Bluetooth is active, and the Arm core is waiting for the transmission to finish so it can act on the data. The current draw in Sleep mode varies depending upon which peripherals are active.
In Extended Sleep mode, the Arm core is idle along with selected peripherals. This mode can be used to save power when the Bluetooth core is in its own Deep Sleep mode and also during long periods of Bluetooth inactivity. The Bluetooth peripheral and the host interface can be active, and either can wake the Arm core with an interrupt on detected activity. This mode consumes a minimum amount of power. In Extended Sleep the DA14585 draws 3.3 microamps (µA) with 64 Kbytes of RAM retained.
The lowest power mode for the Arm and peripherals is the Deep Sleep mode. This turns everything off including the Bluetooth radio. This can be useful if the user decides to turn off Bluetooth and none of the DA14585 peripherals are needed. In Deep Sleep, the DA14585 can draw as little as 610 nanoamps (nA), or 1.4 µA if 16 Kbytes of RAM need to be retained.
In basic operation, the DA14585-based wearable’s Bluetooth core would spend most of its time in its Deep Sleep mode, while the Arm is in either Sleep or Extended Sleep mode. The Bluetooth core then periodically wakes up at a programmed interval into its Active mode to check for wireless data, while the Arm core wakes to its Active mode and communicates the data with the host microcontroller. When transmission is complete, the Bluetooth core goes into Deep Sleep while the Arm core goes into its Sleep or Extended Sleep mode. This provides an active and reliable connection to the mobile device while also conserving power.
Getting started with the DA14585
To get started with the DA14585, Dialog has provided the DA14585-00ATDEVKT-B Bluetooth DA14585 basic development kit (Figure 3).
Figure 3: The Dialog Semiconductor DA14585 basic evaluation board connects to a PC via a USB interface and contains everything a developer needs to test and debug microcontroller drivers and application firmware for the device. (Image source: Dialog Semiconductor)
The DA14585 basic development kit supports full debugging through a USB interface. It is controlled by a host microcontroller from Microchip Technology that uses external flash program memory. Application firmware for the microcontroller can be loaded into the flash memory through the USB interface. The developer can load the example programs included with the kit and use them to interface to another Bluetooth device such as a PC. The developer’s custom firmware can then be loaded and debugged.
Designers of wearable devices need to optimize for minimal power consumption for the best user experience, while also factoring in development time and cost. A wireless interface can consume a large portion of the power budget, but this can be greatly mitigated through careful interface selection and implementation.
As shown, using an external Bluetooth chip with a host microcontroller can speed development time, allowing developers to create a wearable without designing a Bluetooth interface from scratch. Appropriate use of available low-power modes can extend wearable battery life while ensuring reliable operation.
KEY COMPONENTS TABLE
1.The content, data, charts, etc. of this article come from network reference or other public materials, and the copyright belongs to the original author and the original published source. If the copyright owner has any objection to the quotation of this article, please contact ICZOOM "marketing(at)iczoom.com" and we will deal with it in a timely manner.
2.The quotes in this article are for readers' learning exchange only, and do not involve commercial purposes.
3.The content of this paper only represents the author's point of view. ICZOOM cannot gurarante and assure the accuracy, reliability or integrity of the content. The decision or behavior made by readers after reading this article is based on their own will and independent judgment. Please clarify the relevant results before reading this article.
4.Please contact ICZOOM "marketing(at)iczoom.com" with the reason of reproducing if you want to reproduce the articles that ICZOOM owns the copyright. Without permission to reproduce, ICZOOM will reserve the right to pursue the legal liability.
5. If there is any inconsistency between the English and Chinese versions, the Chinese version shall prevail.
ICZOOM has the final right to interpret this statement.