Product development used to be simpler. Devices were self-contained and for the most part lacked intelligence and connectivity. With the IoT in full force, those simple days are over. Every device imaginable, from smoke and CO2 detectors to coffee pots and refrigerators, is being connected to the Internet. This is putting system designers who are unfamiliar with the nuances of RF in the unenviable position of having to integrate some form of wireless technology into their design.
This provides challenges in both hardware and software, leaving design teams with the tough decision of whether to build their own radio to add differentiation and try and keep costs down, or to buy and integrate an RF module.
If the decision is to buy, Wi-Fi, Bluetooth and ZigBee modules are the top three wireless protocols that are being designed into nearly every device imaginable. While efficient, the integration of these modules still requires a high level of knowledge of the nuances of the associated software and RF characteristics that many developers may not possess.
Building vs buying
While engineers may be inclined to build a custom radio module, there are numerous factors that must be taken into consideration before moving forward.
Developing any radio module from scratch, whether it be Wi-Fi, Bluetooth low energy (BLE), ZigBee, or other standard radio, will take a considerable amount of time. Further, delays could be possible if the radio certification bodies have a long lead-time for testing and data review. Tying up critical resources during that length of time when they could be focused on other design aspects is a big risk for a small business or start-up.
Developing a radio module from scratch will not only add potential delays to the development cycle, there are extra costs associated with certification. Using a pre-certified radio module results in negligible certification costs. On the other hand, certifying a module requires an initial capital investment, and once certified there are maintenance and compliance requirements that also need to be dealt with on an ongoing basis.
Designing a module can make a lot of sense for teams that are building products that will be either high volume or have derivative products that will use the same module. Manufacturing a custom module in volume can range from $5 to $10, while purchasing a pre-certified one can cost $15 to $40 depending on the module. For low-volume products that need to get to market fast, the pre-certified module makes sense. For projects that are high volume with a more flexible design cycle, the custom route may make more financial sense.
Still, the case is strong for the pre-certified route even in high-volume applications. Take for example the Digi XBEE® SX Module that costs $35 in low volumes (Figure 1). By only considering just the hardware cost, a development team may determine that $35 per unit is too expensive and opt to design their own, but they could be terribly mistaken.
The Digi XBEE® SX Module comes with the ZigBee stack and a wide range of development tools and software that could cost hundreds of thousands of dollars to develop. When the software stack development costs are taken into account, especially for a robust one that properly implements the protocol features, building a module moves to a completely different level of development expertise.
Figure 1: Long-range modules like the Digi XBEE® SX can be price competitive in low volumes, yet have communication ranges of 9 – 65 miles. (Image source: Digi International)
Simplify design using pre-certified modules
Pre-certified wireless modules provide development teams with a way to decrease overall development costs and get to market faster. Despite these technologies being so ubiquitous, they are complex enough to implement that special niche expertise is required to provide a simple interface that utilizes the features of the protocol. Pre-certified modules certainly simplify design and decrease time to market, but not all pre-certified modules are created equal.
A key feature to look for when selecting a wireless module is scalability in the feature set. As products evolve over time, starting with too narrow of a core feature set will limit the overall design when more features and complexities are required. A great example of a scalable solution for ZigBee is the Digi XBEE® solutions. Here developers have access to modules that can transmit from a few hundred feet up to 65 miles with little or no development overhead.
Another feature that should be at the top of the design list is physical size. Some pre-certified modules can be a bit bulky and large compared to an integrated or custom solution. Since many industrial designers want to create sleek, thin and sexy looking devices, clunky and large modules that eat up a lot of real estate should be avoided. The Texas Instruments CC2564MODNCMOET Bluetooth module is super sleek and petite, measuring 7.1 mm × 7.1 mm × 1.4 mm, and comes pre-certified for FCC and CE compliance (Figure 2).
Figure 2: The Texas Instruments CC256MODN is a Bluetooth 4.1 dual-mode HCI module that is fully certified module and includes Bluetooth low energy features. (Image source: Texas Instruments)
Once a pre-certified module has been selected, care must be taken to ensure that it is properly mounted onto the PCB. For example, modules containing an onboard antenna cannot have any ground planes or metal beneath the antenna, or within the keep-out areas specified in the manufacturer’s datasheet. Doing so can affect the resulting antenna impedance, which will detune the antenna and make communication very erratic if not outright impossible. Since metal can affect the antenna performance, it is also essential to make sure that the device enclosure is properly designed.
Careful consideration needs to be given to the software development tools and stacks that are available to get the module up and running. Some modules require extensive external software for setup and configuration at runtime. If those software stacks are not provided by the manufacturer, a development team may be tasked with having to write thousands of lines of code to get the pre-certified module to function properly. In these cases, having manufacturer provided microcontroller code examples with a good hardware abstraction layer for portability is a must.
A preferred module will require at most a basic configuration command at start up, followed by nothing more than the transparent transmission and reception of serial data on a UART.
Hybrid solutions can provide the best of both worlds
Thankfully, developers aren’t stuck with either a build or a buy option for their wireless solution. There is a third viable solution, a hybrid approach. They can opt for the best of both worlds by using either a wireless IoT platform such as the Silicon Labs Gecko Wireless IoT Platform (Figure 3), or a microcontroller with an integrated wireless front-end. In both cases, there are a few parameters that development teams need to look for to ensure success.
Figure 3: The Silicon Labs Blue Gecko Wireless IoT Platform development kit comes ready to connect out-of-the-box with microcontroller, Bluetooth and software stacks. (Image source: Silicon Labs)
First, any platform or microcontroller utilized in a wireless product needs to be energy efficient. While IoT devices will be both battery- and grid-powered devices, deploying billions of them that ignore energy consumption will not be acceptable. Selecting low-power microcontrollers, such as the STMicroelectronics STM32L0 or an NXP Kinetis-L 81, can help ensure that the main controller associated with the product is energy efficient. These microcontrollers also support a wide range of pre-built drivers and software development tools that allow developers to get a wireless solution up and running quickly.
Next, microcontrollers that specifically target wireless solutions by building the wireless transceiver into the microcontroller can save time and money by decreasing the parts count and speeding up the certification process. A perfect example is the Silicon Labs EFR32FG1P132F64GM32-C0, which contains an onboard Bluetooth transceiver. The microcontroller is designed to be a low-power MCU and is supported by software libraries to operate the Bluetooth stack.
Integrated solutions provide developers with a good mix of trade-offs between building from scratch and purchasing a pre-certified module. Many times there are certified reference designs that, if followed, can dramatically decrease development and certification times. A few issues that developers need to be cognizant of is that microcontrollers with wireless transceivers built into them will use some of their processing time to manage the wireless stack, which in turn will slightly decrease their overall performance. Developers need to make sure that they take care when writing their software so they don’t overload the CPU and miss any real-time scheduling deadlines.
Another potential issue is that integrated transceivers still require external antenna components. Developers need to follow their reference designs carefully or risk delaying their projects by months if they improperly design their transmission line. In most cases the IC supplier is more than happy to review any designs, and provide input and suggestions to ensure the process goes smoothly.
Deciding to build, buy or integrate wireless capabilities can be quite the design enigma. Traditionally, developers looked only at the hardware design and manufacturing costs associated with older wireless technologies. The problem with this approach is that today’s wireless communications are no longer simple hardware solutions, but require a complex set of software stacks and tools in order to get a module functioning properly. While building your own module can look enticing at the start of a design, there are many risks and hidden hurdles that make using a pre-certified module or leveraging an integrated solution a far less risky endeavor.