Once the design decision is made to take the module approach to adding Bluetooth Low Energy (BLE) connectivity to an IoT design, developers need to give serious consideration to which module they will employ. While they all provide connectivity, there are subtle differences in architecture, configuration, and power — among many other factors — that need consideration. Fortunately, the breadth of choices available is considerable.
Making sense of the myriad choices requires consideration of many factors. Here are some of the key factors to include when choosing a BLE module for your next design.
Cost — For many applications, cost is the critical concern. As pointed out in Part 1 of this series, however, the total cost of ownership associated with a module choice may outweigh the module's unit cost as the important factor. This total cost includes any added development time, certification expenses, tool and software purchases, and post-deployment maintenance efforts associated with device choice. Key questions to ask a vendor beyond unit pricing include the type and nature of hardware and software development and integration support offered (including for cloud services and mobile app development), availability of local regional support, vendor experience level with the technology, need for external components, compliance versus actual certification and listing, and upgrade path to emerging standards such as Bluetooth 5.
Size — The amount of PCB board space a module occupies can be critical in some applications and can have an impact on the cost and complexity of the PCB needed to support the device. In applications such as wearable devices, the module's height might also be a critical concern.
Hosted or hostless architecture — Some BLE modules are designed to be drop-in communications peripherals with the transfer of messages as their sole function. Such modules work as a “black box” attached to a host processor that is handling all other device operations, simply executing their host's setup and data transfer commands. Other modules are “hostless,” standalone devices that serve both as a user-configurable system controller and the BLE peripheral. Many modules can serve in either architecture, sometimes requiring additional software or development effort to be hostless, however.
The choice of architecture can have a significant impact on materials and development cost, as outlined in Part 1. Architecture also affects the evaluation criteria that a developer should consider. For a host-based architecture, key additional parameters include the kind of connection used between host and BLE module, the command, control, and data options that the module allows the host to control, and how much of the upper layer communications protocols the host must handle. For a standalone, or hostless, module, developers should explore the application resources remaining after the BLE functions are implemented. Memory, IO, interfaces, and the like all need consideration.
So does the underlying CPU of a hostless module. When the module is to serve both as the application processor and the BLE peripheral, CPU choice can impact the design effort in many ways. Developers need to be familiar with and have tools and libraries for the base CPU's architecture or be prepared to acquire them. The availability of tools and other support from the vendor can be important as well. Furthermore, the CPU's ability to handle unique application needs, such as signal processing, in a power-efficient manner can be an important factor.
Power — One of the essential, but tricky, factors to evaluate are the module's energy demands. Data points such as sleep mode current and current at full transmit power can serve as a starting point, but a BLE device's actual energy demands depend heavily on many factors. These factors include how long and often a device is active or asleep in normal operation, how efficient its code is in executing both communications protocols and application programs, supply voltage, operating temperature, and a host of others. The best approach for developers seeking to minimize energy consumption in their design is to narrow the field to several candidates, then test them under typical application conditions to see how they actually perform. It's also best to test again several times during development to ensure that application code is not causing an unexpected rise in energy use.
Range — To achieve low-energy operation, BLE deliberately restricts output power and data rate. So for many developers, the range over which the module will reliably communicate is a key concern. Unfortunately, the range of a communications channel is so situation-dependent that specifications become essentially meaningless. Factors such as RF transmit power and receiver sensitivity used in link budget calculations can provide some insight, but other considerations such as antenna type and orientation, environmental RF noise, and capability of the device at the other end of the link all have significant impact. As with power evaluations, a developer's best approach is to narrow the field of candidates and then test, test, test.
Other considerations — Beyond the pure technical aspects of a module's offerings, there may be other factors that merit consideration in certain circumstances. One of these is module construction. Many modules are designed for surface-mount operation, for instance, while others such as the Fanstel modules can also work with thru-hole PCB designs. For some, this feature may be vital. Other construction considerations include the operating temperature range options for the module (commercial or industrial), the availability of differing output RF power levels in pin-compatible families, and the ability to bypass an internal antenna to connect to an external one.
Some modules also offer flexibility in the RF channel supported or have an additional RF capability beyond BLE. A design that is software-configurable to use BLE, Wi-Fi, or another protocol can be very useful in some applications. Similarly, modules that offer secondary RF capabilities such as near-field communications (NFC) might be the ideal choice in some cases.
Selection guide — To help developers quickly sort through the many BLE module choices available, Electronic Products (EP) has prepared a downloadable selection guide — available using the link below — containing information on a range of devices. With the exception of cost, most of the factors discussed here are listed in the guide, which also provides hyperlinks to the datasheets of the modules for further detail. This list principally focuses on modules available in the U.S. and on modules that target designs headed for volume production, so it should not be considered an exhaustive listing of the available modules.
The guide is in the form of a PDF document with everything scaled to a single page. This format allows users to zoom and scroll for ease of reading or get an overview at a glance. When printed, the single-page text is tiny, although legible under magnification. Those requiring a printed chart may, thus, want to consider using the “Poster” option under their PDF viewer's print settings.
To make the guide as useful as possible, EP may periodically update, expand, or correct this guide to reflect changes in the BLE module market and fill omissions. In that event, we will note any such updates in the Comments field below.
Advertisement
Learn more about Electronic Products Magazine
