Devices like smartphones have brought major changes to our day-to-day life. They are our gateway to information affecting our lives directly in real time, relating to our health, environment, and even how we make purchases. However, most of this information has to be ‘pulled’ out, which means that either it is obtained through a connection with another device or by searching the web. These methods require that users have to initiate an action when they want data. Sometimes users may not even know where or what to look for, such as when looking for offers on a product in a store.
The solution is to have a system that can ‘push’ messages to users in real time. As smartphones are the best gateway through which information can be pushed to users, this system should effectively send data to it without any hassle. There is where beacons come into the picture.
In wireless terminology, a beacon is a system that broadcasts messages so that they can be received by user devices in the vicinity. Beacons allow hassle-free data transfers to a user’s device without requiring their intervention. Current devices such as smartphones support various options that can be used to enable beacon functionality. To ensure large scale adoption of beacons — including support by a major section of devices, interoperability, low installation cost and low power mode operation — Bluetooth Low Energy (BLE) has become a ubiquitous choice for beacon communication.
BLE is widely used for low power wireless communication in applications requiring the transfer of data within a relatively small radius. A Wireless Sensor Node (WSN) is an example. Data is taken from a sensor and is usually sent to a smartphone. A typical application flow in these sensor nodes is as shown below:
Figure 1. Typical flow diagram of BLE sensor devices (Source: Cypress)
These beacons/sensors need to be powered from a source that allows them to function continuously while still maintaining the size-factor of the overall device. Powering these types of beacons from a wired source is rarely feasible as they are either on a human body or placed remotely; therefore, use cases that require wires for power do not make sense. Battery powered sensors introduce issues such as finite operating life, the need to recharge them frequently, and environmental impact due to disposal.
If we truly want beacons that do not require any kind of maintenance, then we need to utilize unharnessed energy from the surrounding environment such as light, motion, pressure or heat. This will enable an “install-and-forget” approach where the beacons will remain powered through the lifetime of the device.
This is where energy harvesting comes into play. Energy harvesting is a method of collecting minute amounts of unharnessed energy from the surrounding environment and storing it. This stored energy is used for powering the WSN device, collecting sensor data, and transmitting data over BLE.
Figure 2. Energy Harvesting WSN device block diagram (Source: Cypress)
The energy harvesting system (EHS) is a circuit that includes an energy harvesting device (EHD), an energy harvesting power management IC (PMIC), and a storage device. The energy harvesting PMIC ‘trickle’ charges the storage device (typically a capacitor) with energy provided by and EHD such as a solar cell, vibration sensors or piezoelectric devices. The EHS then uses this stored charge to provide energy to another embedded device. Depending on the state of the WSN, the EHS output power varies. When active, energy is consumed, and the voltage from the EHS begins to drop. When in a low power state, the voltage from the EHS rises since the storage device is being charged. The following image shows an example of an EHS output voltage varying with embedded device activity over a period of time.
Figure 3. EH output variation due to Device activity over a period of time (Source: Cypress)
For devices powered by an EHS, the energy consumed during an active state should not exceed the available energy in the EHS. Figure 4 shows an EHS powered system where the energy consumption of during an active state is greater than the amount the EHS can provide. The output voltage of the EHS slowly drops due to consumption, eventually shutting down the output completely.
Figure 4. WSN shutdown due to insufficient power (Source: Cypress)
Figures 5 through 8 present more detailed oscilloscope screenshots of various operations in a BLE sensor node powered from energy harvesting.
click for larger image
Figure 5. EHS output voltage variation with respect to CPU process over a period of time. The yellow signal is the EHS output voltage, and the green signal is the current consumption by the embedded device. The green peaks are current consumption during the CPU active process. The flat signal is during device low power mode. Note that the EHS output voltage drops at every CPU activity (peaks in green signal) due to the energy consumed. Also note that the voltage recovers during the low power states as the EHS recharges the storage device. (Source: Cypress)
click for larger image
Figure 6. EHS output voltage with respect to CPU activity without recharging the storage device in the EHS. Note that as the energy is depleted, the voltage drops below the cutoff voltage, at which point the EHS output is shut down. (Source: Cypress)
click for larger image
Figure 7. Current consumption (green signal) at device boot up. (Source: Cypress)
click for larger image
Figure 8. BLE TX activity in a beacon powered by an EH device. (Source: Cypress)
The limited power budget available with an EHS implies that everyaspect of the embedded system should be optimized energy-wise so that itworks seamlessly while powered by the EHS. There are many subsystems insuch a system that may be power hungry and need to be optimized toensure they do not pull down the output of the EHS. Some of the keyareas to target when optimizing power include the following:
CPU clock frequency
The system clock frequency determines how fast aparticular routine is going to be processed and how much energy it isgoing to consume during that time. A faster clock means fasterprocessing but higher current consumption. Also, each device has acertain minimum and maximum clock frequency requirement, which shouldnot be violated.
For EHS-based designs, an optimized clock frequency has to be chosen with regards to following two factors:
- Average current consumption
- Peak current consumption
The EHS capacity must consider both of these factors. The averagecurrent is the time average of current required during an active state.However, the peak current is the instantaneous maximum currentrequirement of an active state, and is often much higher than theaverage current. It may be possible that average current required iswell within the capacity of the EHS, but the peak current will cause thesudden energy depletion of the EHS, causing the voltage to fall belowthe cutoff voltage. Note that the processing time is part of thecalculation of average current consumption.
The following figure shows the power vs time plot of a particularroutine processed at two different system frequencies, first at 48 MHzand a second at 12 MHz.
click for larger image
Figure 9. Current consumption while processing a routine at 48 MHz (Source: Cypress)
click for larger image
Figure 10. Current consumption while processing a routine at 12 MHz (Source: Cypress)
In this example, the 48 MHz processed routine takes ~300 μs tocomplete and consumes about 10 mA peak during this period. The 12 MHzprocessed routine takes 1.1 ms to complete but consumes only 4 mA peakcurrent. The average current consumed during the process is greater at12 MHz but has a lower peak current requirement. Depending on the EHScapacity, one can go ahead with a short 48 MHz clock setup, a longer 12MHz clock setup, or a mix of both, where the clock frequencies areswitched from one process to another. Such current profiling should betaken into account while selecting the optimized system frequency.
Low power device boot-up
Once an embedded device is powered, it goes through aboot-up procedure before it can execute application code. A typicalboot-up sequence includes:
- Initializing memory
- Setting interrupt vectors
- Configuring peripheral and common registers
- Initializing external clocks, if any.
Each of these steps takes CPU processing time to complete, which inturns consumes energy. The amount of energy consumed depends on the typeof device used, the system clock frequency, how large thememory/register set that is being initialized is, and the time it takesto setup external clocks. Thus, the boot-up process is a power-intensiveactivity and has to be optimized so that it does not consume anexcessive amount of energy from the energy harvester output. Factorsthat should be kept in mind while writing boot up code are:
- Initialize only those sections of memory and registers which will be used. Leave others set to default values.
- Most wireless systems need high accuracy external clocks. These clocks, such as an external clock oscillator or watch crystal oscillator, have a large stabilization time after startup. Rather than waiting in active mode for the clocks to stabilize, the system should be put in low power mode (sleep/deep sleep) and awakened only when they are ready for use. Use an internal timer for this purpose.
Low power system startup
Once the device begins executing application code, thereis usually a need to start individual peripherals in the system. Theseperipherals could be internal to the device, such as an ADC, or may beexternal to the device, such as a sensor. The starting time may not belarge individually for peripherals, but in combination, the overall setup could require enough processing time to drain the stored energy inthe EHS.
The startup time of individual peripherals should be calculated for agiven CPU frequency. Then determine if the energy budget for startingall peripherals together (faster) is feasible or whether the startupprocedure needs to be broken into multiple stages (slower).
Staged application processing
The device will have various application routines thatrequire their own CPU bandwidth. These routines could be for configuringa peripheral, receiving data from sensors, performing calculations, andmanaging events or interrupts. Ensure that the energy required for thisprocessing does not exceed the capacity of the EHS. If it does, breakroutines into smaller subroutines and manage them in stages. This allowsfor the load on the EHS to be broken down into manageable currentpulses that enable the EHS to recharge between active CPU processes.
Additionally, between each stage, place the system to low power modewith a wake-up source as an interrupt from a counter or watchdog timer.As the system has to remain in this mode for a large portion of thetime, the current requirements during these modes should be as low aspossible.
Once data has been collected, it has to be transmitted wirelessly.This transmission can be done either on a BLE connection or BLEbroadcast, though energy-harvesting-supported beaconing are limited toBLE advertisement. This is because it takes a larger amount of energy toset up a BLE connection before the connection can be used to transferthe data.
In general, radio activity, either transmission (TX) or reception(RX), is the highest energy-consuming operation in a wireless device.Ensure that the BLE activity occurs as an independent process that it isgrouped with other process only if the EHS output can provide that muchpeak current.
Energy harvesters such as Cypress’s PMIC-based devices provide abattery-free technology for wireless sensors and networks. Their precisecontrol over output power with efficient power collection makes them agood choice for small wireless and beacon applications. They can eitherbe used solely as a power source or in conjunction with battery-baseddevices, such as a Li-ion battery, to increase a device’s operationallife. An energy harvester PMIC can startup from a low voltage and adaptto the need of the application. Some of Cypress's offerings, such asMB39C831, feature maximum power point tracking (MPPT) functionality.MPPT allows the internal DC/DC converter to control the output chargingby following the input power, thus maximizing the power output. PMICslike the MB39C811 support dual inputs for harvesting so that powercollection can happen simultaneously from two different sources.Optimized PMICs like the S6AE101A (solar or light EHD-optimized) offerextremely low start up and quiescent power consumption, enabling the useof a tiny solar cell.
Another aspect of a battery-less wireless beacon is the selection ofan MCU. MCUs integrated as programmable systems, such as SoCs, alongwith support for various low power modes are a good fit for suchapplications. Cypress’s Programmable System-on-Chip (PSoC) offers tightintegration with various types of peripherals that can be used tointerface to sensors. The PSoC 4 BLE, in particular, contains low powerperipherals along with a BLE radio and integrated BLE stack, providing atrue single-chip BLE sensor node. Also, the support for ultra-low powermodes allows the design to work seamlessly with constrained powersources such as energy harvesters and coin cells. Such harvesters, alongwith PSoC, prove to be an optimized design for battery-less BLE sensornode applications.
Refer to application note AN91267 for more information on PSoC 4 BLE. Also, refer to application note AN92584 for details on how to further optimize the power requirements for a BLE system. Refer here for Cypress’s PMIC solution details and their latest offerings.