Now in its fifth major release, Bluetooth has many features and options that make it possible to tune wireless communication to the precise needs of the application.
One of the most important factors for IoT applications is the availability of Bluetooth’s low-energy profile, BLE. But there are a number of factors to consider when it comes to designing BLE into the end equipment.
Implementing Bluetooth from scratch is a complex undertaking but, for most IoT applications, it is not a necessary step. There are numerous solutions available that provide Bluetooth and BLE integration. The key is to select the solution that has the best fit for the application’s requirements.
One of the key reasons for choosing BLE in IoT designs over traditional Bluetooth is its lower power consumption. The designers of BLE recognised that typical implementations would only need to send short packets at widely spaced intervals. A connection might last only for a few milliseconds with readings being taken a second or more apart.
BLE saves energy by allowing the interface and its control electronics to move into a low-energy sleep mode between transitions if it does not need to listen for incoming packets. Conventional Bluetooth transceivers will often remain awake during those quiet periods to listen for keep-alive messages. The sleep period is dynamic. If an active phase does not result in the transfer of application data, the protocol can extend the sleep period.
As receive and transmit power is typically on the order of 10 mA to 30 mA, the ability to sleep for long periods means BLE transceivers and their host MCUs can work on devices that are powered by sources such as lithium coin cells. BLE further reduces the energy burden by restricting the number of channels on which a transceiver needs to perform discovery – 3 versus the 32 of traditional Bluetooth. This makes discovery faster with far fewer searches.
Designers working on an IoT application can choose a dedicated BLE interface IC, a module-level solution or opt to use an integrated MCU with BLE support built in. Each of these options has implications for the project, such as time to market and form factor.
RF antenna options
The antenna is a key consideration. An effective antenna design is required to ensure that the end product meets user requirements for range and power efficiency as well as compliance with regional standards intended to prevent spurious RF emissions.
The time-to-market advantage of a module-based Bluetooth implementation, such as the Microchip Technology RN4020 or Panasonic PAN1760A, is that the antenna can be integrated into the module itself. This greatly reduces design and test time. Module implementers take great care in optimising the antenna design to ensure it operates at high efficiency over a wide operating range.
However, the use of a module may place constraints on the design of the baseboard and enclosure that do not suit the end application, particularly if there are specialised requirements for the device. For example, a wearable will often need to use an enclosure that is comfortable for the user. Often, these devices will form the antenna into the enclosure design itself, which demands a customised solution. In this case, a dedicated Bluetooth transceiver IC designed to work with a custom antenna is required.
Space constraints will tend to favour the use of a single Bluetooth-enabled SoC that performs application and communications functions. If the aim is to add Bluetooth to an existing product line that already has an extensive base of firmware developed specifically for it, the integrated SoC solution may not be a viable option.
Protocol support
One key advantage of a Bluetooth module or dedicated transceiver is that it makes it possible to offload most communications functions from the host CPU. The Kinetis KW35/36 series of BLE ICs from NXP include an ARM Cortex-M0+ processor core running at 48 MHz to handle the Bluetooth protocol stack in addition to the CAN-FD and LIN standards used in automotive body electronics.
This processor core is powerful enough to run, in addition to the BLE protocol, other applications, allowing it to function as a complete SoC as well as a smart transceiver. Typical use-cases for the KW35/36 are for remote keyless entry and tyre condition monitoring. The device supports up to eight concurrent, secure connections.
The Panasonic PAN1760A module, which integrates filter electronics and antenna for ease of integration, is based around the CC2540 transceiver made by Texas Instruments. Protocol-stack handling is performed by an integrated 8051 processor core.
The RN4020 developed by Microchip Technology can act as a BLE module for a larger system or, using scriptable firmware running on its PIC24 processor core, work independently supporting both the protocol stack and the end application.
Higher performance to support higher-performance applications that require BLE connectivity is available from devices such as the Nordic Semiconductor nRF52832, which integrates an ARM Cortex-M4F core, 512 KB of Flash memory and 64 KB of RAM.
BLE SoCs and modules can provide a number of ways in which the wireless protocol can be integrated into an application. The Microchip RN4020 offers a scriptable mode to support rapid prototyping and implementation of BLE-enabled applications. The scripting language can be used to build applications that read sensor data and relay the information over a Bluetooth connection to a paired device.
Inside the BLE stack
In most cases, an integrated SoC with BLE support will provide firmware libraries that provide access to the functions of the protocol stack. The BLE stack itself is divided into a number of layers and component parts that can be implemented on top of a real-time operating system (RTOS) that may be supplied by the vendor, a custom solution or a third-party offering.
The stack will often communicate with the RTOS through semaphores, flags and callback functions. Some porting effort will be required to map the function calls from a vendor’s BLE stack to the underlying kernel if a custom or third-party RTOS is employed. Key elements of the BLE stack are the Generic Access Profile (GAP), the Generic Attribute Profile (GATT) and the Security Manager (SM).
The GAP performs a number of tasks including the sending of data broadcasts without first establishing point-to-point connections, the discovery of nearby devices and the setup and teardown of connections between peers that have been paired. The GATT takes on the tasks of sending data to and receiving data from peers that have been paired. Packets sent by the GATT can be set to demand a response to ensure correct delivery or they can be set to expect no confirmation.
The data sent using the GATT layer will often fit into one of the Bluetooth standard’s many application-specific profiles. By making use of these profiles rather than using custom packet formats, IoT node vendors can help ensure interoperability with a wide range of peer devices, such as medical sensor nodes that report blood pressure and heart rate or building automation systems that relay environmental data.
The SM implements the functions needed to pair devices securely and send protected messages after pairing. The SM includes functions for exchanging encryption keys and – an increasingly important factor in IoT designs – for encrypting data before transmission.
Security is becoming a key focus for many IoT developers. As well as encryption of inflight data, it is important that systems are made resistant to attack vectors such as BlueBorne. This may make it important to put a simple user interface onto the device so that an installer can enter a secure code during commissioning. Alternatively, an additional RF channel such as NFC can provide the necessary authentication from a mobile phone running an appropriate app or a custom hardware tool used for installation and commissioning.
API considerations
The decision on whether the Bluetooth interface runs within the host MCU or separately will affect the structure of the software. But vendors often provide tools to aid with moving from one to another where changes in applications demand it.
When the application is based on standalone Bluetooth-enabled MCU, the stack is typically accessed through C function calls. As an external smart transceiver IC, the same API functions may be accessed in a coprocessor mode through a serial interface such as a UART. The serial protocol may be based on AT commands similar to those originally employed for simple modems, or on a custom protocol. The serial protocol will carry commands from the host to the Bluetooth stack and responses and events from the Bluetooth stack back to the host.
Other tools that aid the construction of profiles can include compilers that take as input XML files that define the messaging requirements of the application and convert them into C code and header files. This makes it easier to send data such as blood pressure readings that fit into standard Bluetooth profiles.
Multicore IoT-node implementations, such as those that employ a separate Bluetooth transceiver IC or module, have the opportunity to optimise energy consumption by coordinating sleep cycles. With an intelligent transceiver, there is no need for the host CPU to remain awake while RF communication is taking place. Once a command has been issued to send data and the packet is placed in a suitable buffer, the host CPU can move into a low-energy sleep mode while the transmission or reception occurs.
An intelligent transceiver can monitor incoming packets for content and ensure only those with important data for the host CPU will cause it to wake up for processing. Broadcast messages that only concern network management can be dealt with by the Bluetooth transceiver’s own processor. This allows features such as packet relaying in a Bluetooth 5.0 mesh network to be performed without disturbing the host CPU.
Messages that affect the IoT node but have a low priority, such as server status updates, can be buffered locally. The host CPU need only be woken to empty the buffer or when a command from a server that needs immediate attention is received. To implement this functionality, a software state machine that interprets incoming data needs to be written on top of the core Bluetooth firmware supplied for the transceiver’s CPU.
As a BLE transceiver needs to stay awake to listen for incoming packets, this can lead to energy consumption that is greater than planned. A typical scenario is when the GATT layer sends a packet that requires a response from the receiver. As a result, the node will not be able to sleep until this confirmation is received or the transaction times out.
Some urgent packets that are mission critical will need to use such confirmations. However, many data items will be sent that do not need immediate confirmation. Instead, the guarantee of delivery can be performed by application-layer protocols. For example, a custom protocol may synchronise with the remote peer when it next wakes up using packet-sequence numbers or codes. This allows the node to sleep as soon as it has sent the last update packet within the current wake-sleep cycle. The sniff subrating mode employed by BLE synchronises the two endpoints so that a master will hold on to data until the next wakeup or sniff period.
Conclusion
By making smart modules and transceivers that are supported by extensive firmware libraries, manufacturers have achieved the goal of making BLE accessible to practically all IoT designs. The solution that is most suitable for a given design depends on its requirements and application goals, but the wide choice of options means there is one that provides a good fit.
For more information contact Farnell element14, 0800 111 057, info-za@farnell.com, http://export.farnell.com/welcome-south-africa
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version