Today, technology is advancing rapidly to make the world smarter, device by device. New devices and concepts are constantly arising to improve upon existing technologies and create new market segments. Similar technological advancements in Bluetooth have led to the emergence of Bluetooth Smart, also known as Bluetooth Low Energy (BLE). BLE is a low-power, short-range, low-data-rate wireless communication protocol defined by the Bluetooth Special Interest Group (SIG). BLE has a layered protocol stack that is designed to efficiently transfer a small amount of data with low power consumption. This makes it the preferred wireless protocol for battery-operated applications like low power sensor network interfaces where data needs to be fetched and processed in regular intervals. This article focuses on how such sensory applications where data does not change frequently, can efficiently utilize BLE to maintain low-power wireless operations.
The world is moving towards Internet of Things (IoT), where different systems need to collect and exchange data. BLE plays a crucial role in IoT where sensors are connected wirelessly, forming a network and enabling data exchange between devices. The host device could be a smartphone that monitors and controls all the network nodes. Such IoT applications include tracking your daily activities and home automation functionality like efficient lightning, monitoring, controlling temperature, humidity, along with consumer electronics (just to mention a few).
BLE Power Modes
If sensors are battery-operated, power-constrained, and have to last a long time, BLE provides an optimal connectivity option. Consider a low-power sensor that measures temperature and humidity, which are slowly varying parameters. These sensors can be interfaced with a BLE-enabled processor that can process and transmit data to a host device. The BLE subsystem can operate infrequently—say once every hundred milliseconds, and for the remaining time, be in low-power mode. BLE-enabled devices also offer multiple user configurable power modes that optimize operation of the BLE subsystem (BLESS) independent of the processor operating mode. These allow developers to reduce power consumption and enable years of operation from a single battery.
The five system power modes are Active, Sleep, Deep Sleep, Hibernate, and Stop. The three BLESS power modes are Active, Sleep, and Deep Sleep. BLESS modes are active until Deep Sleep mode with a system power of 1.3 µA. The BLE subsystem can transmit and receive data in BLESS Active mode. It remains idle and maintains its connection in BLESS Sleep and Deep Sleep modes. These power modes are independent of system power modes, give developers the flexibility to configure the system, and BLESS separately for the greatest efficiently. Thus we can build the complete system with very low current requirement, usually powered by a coin cell battery.
For example, the average current consumption for a 1 sec adverting interval is as low as 26 µA. For the same 1 second connection interval, it is still lower—17 µA.
Sensors and BLE
Sensors can be broadly classified as analog and digital. Typical examples of analog sensors include sensors for monitoring smoke, gas, ambient light, human presence, etc. Examples of digital sensors include monitoring temperature, humidity, pressure, acceleration, and so on. When the BLE subsystem is integrated with the application processor, sensors can be interfaced in a number of different ways. For example, analog sensors can be fed to a SAR ADC with a voltage follower in the front end. Digital sensors do not require analog conversion and hence data can be collected over any communication interface like I2C, SPI, or One-Wire Interface. Integrated timers, counters, PWMs, and Universal Digital Blocks (UDB) can be used to implement custom logic for further processing of sensor data. Ultimately, processed or received digital data can be sent over the BLE interface and monitored by the host BLE-enabled phone or any other monitoring client device. With varying resource availability and cost, processors integrated with BLE like the PSoC 4 BLE are available in different families to suit a wide range of applications.
Wireless Sensor Networks
Wireless sensor networks are typically implemented as mesh and hub networks (see Figure 1). Hub networks include all the sensors that can be placed at the same location. Each sensor needs to be interfaced to a single BLE peripheral device (server) to process and send the data to the BLE central device (client). Mesh networks follow a topology in which sensors can be located remotely. Each node in the mesh needs to be interfaced to a BLE peripheral device (server) and all these peripheral devices can be connected to the BLE central device (client).
The flexibility and resources of a processor integrated with BLE allows sensors to be interfaced with just a single BLE-enabled device. Figure 2 shows a typical schematic configuration made using PSoC Creator, an IDE for developing application built around the PSoC architecture. It shows both analog and digital sensor interfaces along with the BLE subsystem. This configuration demonstrates a typical system industrial data monitoring system sensing smoke, light intensity, temperature, humidity, and pressure. Each component in the configuration has an associated Application Programming Interface (API) allowing developers to access these components as per their requirements. Every component also has a datasheet associated with it explaining the component’s available configurations.
The BLE component is configured as a peripheral in its GAP layer. This enables any BLE device (like a BLE phone) to scan for this device, while it advertises with its name and then connect. In its GATT layer, it is configured as a GATT Server with a Custom Profile. The BLE Low Power features (discussed later in this article) are enabled within the component. One single service named “SensorService” is used with five different characteristics for collecting data from each sensor data. Every characteristic has its notification enabled, which allows the sensor data to be sent as notifications.
When it comes to BLE, everything is handled as “Events.” The BLE Stack provides “the defines” for handling these events. The following code fragment demonstrates the use of a few of these events.
CyBle_Start(AppCallBack);
void AppCallBack(uint32 event, void* eventParam)
{
CYBLE_API_RESULT_T apiResult;
switch (event)
{
case CYBLE_EVT_STACK_ON: /* This event is received when the component is Started */
/* Enter into discoverable mode so that remote device can search it. */
apiResult = CyBle_GappStartAdvertisement(CYBLE_ADVERTISING_FAST);
if(apiResult != CYBLE_ERROR_OK)
{
/* Error */
}
break;
case CYBLE_EVT_GAPP_ADVERTISEMENT_START_STOP:
if(CYBLE_STATE_DISCONNECTED == CyBle_GetState())
{
CySysPmHibernate(); /* Enter Hibernate Mode for Low Current */
}
break;
case CYBLE_EVT_GAP_DEVICE_CONNECTED:
break;
case CYBLE_EVT_GAP_DEVICE_DISCONNECTED:
/* Put the device into discoverable mode so that a remote can search it. */
apiResult = CyBle_GappStartAdvertisement(CYBLE_ADVERTISING_FAST);
if(apiResult != CYBLE_ERROR_OK)
{
/* Error */
}
break;
/* GATT Events */
case CYBLE_EVT_GATT_CONNECT_IND:
break;
case CYBLE_EVT_GATT_DISCONNECT_IND:
break;
}
}
Once the two devices are connected, the data can be sent using notifications in different connection intervals. The API “CyBle_ProcessEvents()” should be put in a while(1) loop and must be called at least once in each connection interval. We also can call the function that would send the data as notifications in the same while loop. The following function can be used for sending one byte of Temperature data as notifications. The same can be applied to other sensor characteristics as well.
void SendTempNotification(uint8 TempData)
{
CYBLE_API_RESULT_T bleApiResult;
CYBLE_GATTS_HANDLE_VALUE_NTF_T TempHandle;
TempHandle.value.val = &TempData;
TempHandle.value.len = 1;
TempHandle.attrHandle = CYBLE_SENSORSERVICE_TEMPERATURE_CHAR_HANDLE;
do
{
bleApiResult = CyBle_GattsNotification(cyBle_connHandle, &TempHandle);
CyBle_ProcessEvents();
}while((CYBLE_ERROR_OK != bleApiResult) && (CYBLE_STATE_CONNECTED == cyBle_state));
}
As described earlier, the processor and BLE subsystem (BLESS) have independent low power modes. For example, if the device is disconnected, we can put the processor into Hibernate or Stop Modes to reduce power consumption. In between the advertisement and connection intervals, we can utilize BLESS Deep-Sleep Mode. Even the individual components used (like ADC, I2C, etc.) can be put into their respective low power modes and awoke when required. This gives developers a great deal of control over power consumption based on what the system as a whole actually needs to perform.
Hence, the while(1) loop shall look like below:
while(1)
{
/* Process all the generated events. */
CyBle_ProcessEvents();
/* To achieve low power in the device */
LowPowerImplementation();
/***********************************************************************
* Wait for connection established with Central device
***********************************************************************/
if(CyBle_GetState() == CYBLE_STATE_CONNECTED)
{
CyBle_ProcessEvents();
SendTempNotification (Temperature);
}
}
Thus, a BLE-enabled phone can now scan for this Sensor Network device and monitor each of the sensor data, using the various characteristics. Some processor manufacturers also provide software support for connecting to BLE-enabled phones.
BLE Beacons
Bluetooth beacons are devices that broadcast signals that can be heard from nearby smart devices. For such applications, the BLE component needs to be configured as a Broadcaster for its GAP role, and the system can send the broadcast information. Beacons should be low-powered, and also benefit from an integrated processor/BLE approach to design.
BLE is gaining momentum in many markets, including consumer, industrial, and embedded applications. A key factor in the success of this technology is its ability to operate with a low-power footprint. BLE technology enables developers to design applications that are battery powered, long lasting, and more user friendly.
Filed Under: M2M (machine to machine)