The Internet-of-Things (IoT) means networking, and a lot of that will be wireless. One way to simplify IoT designs is to use wireless modules and gateways that have already been verified and approved. This allows a designer to concentrate on the application hardware and software. Meeting FCC requirements and gaining approval of wireless hardware is a viable alternative for high-volume or very compact applications, but many applications are better served by prepackaged solutions.
In this case, the typical IoT configuration is a gateway providing connectivity to cloud-based services. This might be a PC, tablet, or smartphone for some consumer devices. In the case of industrial and embedded consumer applications, however, the gateway is often similar to Freescale’s IoT Gateway (see “IoT Gateways And Triple Core Micros At FTF 2014”). Low-power ARM processor use in these types of gateways is common, as are low-power processors being used in the connected devices.
This file type includes high resolution graphics and schematics when applicable.
There are other alternatives available, like Imagination Technologies’ MIPS architecture, as well as Intel’s Quark (see “How Many Quarks Does It Take To Make An IoT?”). The Quark powers gateways like ADI Engineering’s White Oak Canyon IoT Gateway, Portwell’s PI 81A0, AAEON’s AIOT-X1000, and Super Microcomputer’s E110-8Q IoT Gateway (Fig. 1). The E110-8Q has a pair of Mini-PCIe slots and a ZigBee module slot.
The challenge is finding the right wireless support for these platforms. Mini-PCIe modules are one way to have a flexible platform and gain access to the required wireless protocols. Luckily there are lots of options available, like Advantech’s EWM-W148H half-size Mini-PCIe card that supports Bluetooth 4.0, as well as 802.11 a/b/g/n. Need GPS? Check out Versalogic’s VL-MPEu-G2 GPS receiver.
Modules that plug into slots are good for gateways, but many embedded applications have more rugged needs; in these cases, modules that can be soldered make more sense. They also eliminate the cost and size of connectors required by other modules.
There are lots of options in this space. There is no standard form factor, although a vendor will often have a line of pin-compatible modules. One good example of these, the Lantronix xPico Wi-Fi module (Fig. 2), is used in the Zano Micro Drone (see “Keep an Eye Out for Quadcopters”). The xPico has a serial interface and supports soft-AP and client modes simultaneously.
Microchip’s RN2483 module (Fig. 3) support the sub-GHz LoRaWAN (Low Power Wide Area Network) protocol. The LoRa Alliance’s LoRaWAN is designed for long range (over 15 km) connectivity and millions of nodes. Battery life when using this type of module in a system is targeted at more than 10 years. The interface uses an ASCII command set like many modules with a serial interface.
Even cellular support is available with surface-mount modules. Take MultiTech’s MultiConnect Dragonfly, for example. It has an ARM Cortex-M4 that is mbed-compatible. It handles cellular, LTE, HSPA+, and other variants, as well as providing GPS/GLONASS support.
Modules are available for just about every wireless protocol including ZigBee, Z-Wave, Bluetooth, and DECT ULE (see “Connectivity Options Abound for the Internet Of Things”). Many have built-in antennas, but this will be yet another choice for designers. Though convenient, these antennas lack the range and sensitivity of larger antennas. Cabling is often necessary to allow for their external placement.
Of course the advantages of this modular approach include FCC approval and systems that typically work out-of-the box. Protocol stacks tend toward embedded, and hardware often accelerates security support that is increasingly important to customers. Designers often can provide multiple products with different protocol support by using the appropriate module. Sometimes the swap can be transparent depending upon the wireless protocol, as well as the device protocol. Other times it may require software changes to the application or system drivers.