Providing wireless connectivity for IoT; what are the options

By Rui Ramalho, product manager – connectivity modules, Murata Europe

Many embedded developers are finding that in addition to making their design function that every IoT design will always require wireless connectivity in order transfer sensor data to a cloud-based application. Faced with this requirement engineers can either design their own wireless transceiver or decide to incorporate a pre-certified wireless module into their design.

The first choice however when considering how your IoT design will communicate is what protocol standard to use. There are a multitude of communication technologies available, the popular standards being Wi-Fi, Bluetooth and ZigBee. The designer must start by investigating how much data will need to be transferred and over what range it would typically need to be sent. For most applications there are always trade-offs between range, data rate and use case to be considered. The use case might highlight a number of criteria such as the frequency with which data needs to be transferred and the supply power budget available; a key consideration when using a battery powered device. For example, for the control of a device or receiving some sensor data only a few times a day, Bluetooth Low Energy (BLE) can be quite appealing. Virtually any smartphone can support this method of communication and, therefore, the control or data storage processing device can readily be available. However, if a higher quantity of data, say a few Mbytes needs to be transmitted then the designer might best consider using Bluetooth Classic or Wi-Fi.
Then the consideration of range needs to be taken into account. BLE typically can communicate over 30 meters in line of sight but if the data needs to be transmitted across a building an alternative must be considered like the emerging technology of BLE Mesh, ZigBee or sub 1GHz. In case of mesh-based networks, the range is created by the data being repeated along the mesh and therefore the presence of nodes along the path that must be covered is needed. However this might present challenges when we want to have sensor at one extremity of a building and access its information at the other end. Sub 1GHz ISM band communication technologies have the inconvenience of not using uniform frequencies across the world thus requiring different products variants or adjustments for the different regions. In addition, the communication protocols used are not standard creating even more incompatibilities between devices using these technologies. For an increasing number of IoT designs Wi-Fi is seen as a good communication method for a number of reasons. Firstly, the infrastructure is becoming more and more available, secondly, the data rates are much higher and of significant note is that it usually will provide you with a direct connection to cloud-based services.

Once the communication protocol has been selected the engineer will initiate the selection of the components for its design. The next question is usually should I use a module or a make a discrete design. There are two situations where a module is usually the logical answer: when time-to-market and/or size matters. A module is a ready-made single fully tested component and, with a high integration level the footprint is much smaller than that of a discrete design is used. This is the reason why the top manufactures of smartphones choose modules for their designs.

In an industry where cost is very sensitive, often the principal argument becomes the price of the components. Here the engineer must be aware of the important differences of the price versus cost. When the BOM is compared between a discrete connectivity solution and a module, the module usually costs a bit more. Obviously there are the assembly costs that need to be considered in addition to the development, test and certification costs. The engineer must have always in mind that a module is a single component that was fully tested on the production line, ready to be placed on the PCB and in most cases is pre-certified to many regional wireless certification bodies. Modules with pre-integrated firmware are also available to simplify the task of software integration. Procurement colleagues will also have less individual components to manage the supply chain for in order to guarantee the smooth production. Management will no doubt also appreciate the fact no additional resources for the development such as expensive test equipment and, potentially, at least one specialist wireless communication design engineer. Modules also avoid the hidden costs associated with, for example, the expensive redesign of an RF board due to EMI problems caused by poor track layout.

Once decided on adopting a module approach to implementing Wi-Fi connectivity the engineer can choose from a number of suitable products on the market. An example is the Type YD (part number LBWB1ZZYDZ) from Murata. See Figure 1.

Figure 1 – Murata LBWB1ZZYDZ Wi-Fi wireless module

Measuring just 33 x 18 x 2.5 mm this compact FCC/IC and CE compliant module integrates a Broadcom BCM43362 wireless transceiver, a STMicroelectronics STM32 ARM Cortex-M3 microcontroller and an antenna. Several software architectures can be supported. Using Murata’s Simple Network Interface Controller (SNIC) protocol, which is based on Broadcom WICED solution, it offers access to a pre-built firmware/software package that makes the host integration, wireless and peripheral control more easier and reliefs the burden of firmware programming. Acting like a black box the module can be controlled by any MCU through UART or SPI interfaces.

Figure 2 – SNIC serial interface protocol

Figure 2 illustrates how message exchange is achieved between the customer application and the Type YD Wi-Fi module. Figure 3 shows some of the command instructions that can be issued over the UART or SPI interface to detect Wi-FI access points, establish communication and transfer data.

Figure 3 – Command set examples

It should also be noted that in addition to using the module as a communications interface an engineer can make a complete application development on the internal ARM Cortex-M3 of the module. This would be ideal for a number of applications that involve connecting a small number of sensors for example to a cloud application without the need of a host application MCU. There are a number of unused GPIO pins available on the module to allow this in addition to the MCU’s ADCs. Armed with a Broadcom WICED software development kit the engineer can develop such an application. The final firmware can then be downloaded to the module such that it becomes the core of the device.

Selecting a pre-certified wireless module instead of developing a discrete solution will save significant amounts of design resource and cost but will also ensure you can get your product to market as quickly as possible.