How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
The first three parts of this blog series on wireless communication for the IoT have concentrated on some of the detail of RF design. Now I’ll look at matching a selection of the many software/hardware systems and protocols available to likely IoT applications. There are so many in fact, I’ll just cover the short-range, usually indoor systems and leave long-range to Part 5.
When venturing into a new area of design it’s always a good idea to have some understanding of the basics. This is especially true for a digital electronics designer not used to a world where all logic seems to break down and circuits that appear to perform perfectly are deemed illegal because of emissions outside the permitted frequency bands. Fortunately, you can purchase off-the-shelf pre-certified modules to get around some of these issues. Unfortunately, there is no ‘standard’ IoT application and no standard all-purpose communications protocol. Note too that regulatory approval requirements governing radio emissions vary from country to country and if you want world-wide sales, your product must comply with all of them!
Pretty much all IoT wireless communication takes place in blocks of the radio frequency spectrum designated as the license-free Industrial, Scientific and Medical or ISM bands. But what does the term ‘license-free’ actually mean? It does not mean that you can build, run or sell some device that nominally transmits with an ISM carrier frequency of say, 2.4GHz, but is poorly designed such that out-of-band signals interfere with other equipment. Neither can you crank up the signal power beyond a certain limit to extend the range. It means that you personally do not need a broadcast license or amateur radio license from your government telecoms agency to operate in these bands. It also means any Short-Range Device (SRD) must be able to co-exist with other devices operating in the same band (See The Coexistence Problem in Part 3). However, any product you sell must have Regulatory Approval and proof that it complies with the strict specifications for ISM signals as defined by bodies such as the European ETSI or the US FCC.
A board containing high-speed logic circuits with no intentional RF transmission may still radiate sufficient energy to fall foul of the regulations. A single-board computer such as the Raspberry Pi 2 will have to undergo what is called Qualification testing to prove that its emissions are within limits. The Pi 3 has an extra burden of testing to ensure that it’s WiFi and Bluetooth transmissions are compliant too. The FCC and CE marks are printed on the PCBs of both, enabling them to be sold legally in Europe and the US.
Wireless Standard Certification
If you propose to market your new wireless IoT gadget there is a further, optional, stage of testing and certification which can add credibility to the product. For example, products bearing the Wi-Fi CERTIFIED™ logo have, to quote from the Wi-Fi Alliance web site, “met industry-agreed standards for interoperability, security, and a range of application specific protocols.” You must use an approved test laboratory for what they describe as ‘Rigorous Testing’ of your product before a certificate can be issued. A similar process is required by the Bluetooth Special Interest Group (SIG) if you want to use the Bluetooth® logo on your new product. Recently, the LoRa® Alliance has been set up to promote LoRaWAN™ as a standard for low-power, low data-rate long-range IoT connectivity. And there are others.
Do I design at chip-level or go for a module?
Basically you have to have a very pressing reason to lay out your own PCB with an RF transceiver chip, antenna matching components and perhaps the antenna itself in the form of a chip or a PCB track. Any saving in component costs is blown away completely by the costs of designing the PCB tracking to meet EM emissions regulations. Qualification testing alone costs a fortune and takes ages. To quote Pete Lomas, co-creator of Raspberry Pi: “…testing can be like watching wood warp, paint dries too quickly…”. No-brainer then: go for a module. That doesn’t mean that your finished product won’t have to show compliance with regulations, but it’s far more likely to pass first time and not require expensive re-work.
RF Carrier Frequency Selection
It’s easy to forget that wireless communication between devices predates the IoT by many years. The TV remote control comes to mind. Until recently Infrared light was the medium of choice, but now Radio Frequency (RF) is taking over. Actually, the earliest TV control I remember from the late 1960’s was ultrasonic – and the transmitter had no electronic components. It consisted of a single click-action push switch in a plastic case which just changed channel when you pressed it. Not a hardship as the UK only had three channels in those days! The button was connected to a tiny hammer which struck a piece of metal causing it to ring like a bell at an ultrasonic frequency. But enough of Fred Flintstone’s TV, let’s get back to the IoT of today. Selecting which part of the RF frequency spectrum to operate in is not too much of a hassle as an international body, the International Telecommunication Union (ITU) has co-ordinated the carving up of the RF spectrum into bands of frequencies allocated for different applications. Wireless IoT is usually restricted to the ISM bands mentioned above, divided between the 2.4/5.8GHz group and the Sub-1GHz group. Table 1 gives a rough idea of the frequencies involved.
433.05 - 434.79 MHz Region 1 (inc Europe)
868 - 870 MHz Region 1 (inc Europe)
902 - 928 MHz Region 2 (inc USA)
2.4 - 2.5 GHz All Regions
5.725 - 5.875 GHz All Regions
Table 1. Popular ISM/SRD Frequency Bands used for IoT Applications
Generally speaking, the sub-1GHz frequencies are used for long-range applications from say, 100m to 20km line-of-sight. The GHz bands are essentially short-range only, from 1m to 100m line-of-sight and much less when used indoors through walls. The GHz bands allow much larger data rates than lower frequency bands however: Mbits/sec compared with 100’s of bits/sec for sub-1GHz at extreme range. As a rule of thumb, use GHz bands for indoor work, sub-1GHz for outdoors.
What communication protocol/standard/hardware should I use?
As with everything else in the modern world you are both blessed and cursed with an enormous range of options. It is possible to narrow the choice but any one application is unlikely to have a single obvious solution. Let’s go through some possible scenarios and see if it’s possible to navigate through the jungle.
Simple key-fob with up to four buttons for opening garage doors, turning on outside lights or triggering a clay-pigeon trap: buy a complete kit, there are loads available. Most will include some form of encryption system for secure transmission. The requirements are to send a few data bytes pretty slowly over a line-of-sight range of only a few metres. No sophisticated protocols are needed.
Hardware: Quasar ZANDER-S4 Key Fob Wireless Remote Control kit.
For a customised version, use a pair of simple, no-frills transmitter and receiver modules with an encoder/decoder chipset to provide secure transmission (if required).
Hardware: Quasar 433.92MHz ASK QAM-TX1 transmitterpaired with a QAM-RX1 receiver . Optional RF600E encoder and RF600D decoder . The modules are really easy to use with nothing to adjust or set up!
Advanced Remote Control – RF4CE
If you’re designing a complex multi-media control with many functions and possibly feedback from the ‘thing’ being controlled, then some rather more sophisticated kit will be required. Infrared has dominated TV remote designs for years, but manufacturers are now switching to RF and in 2008 a number of them formed the RF4CE (Radio Frequency for Consumer Electronics) Consortium. Working with the ZigBee Alliance, a standard specification for remote control based on the 2.4GHz ZigBee network protocol was developed: RF4CE. This protocol allows a network to be created linking TVs, DVD players, Set-Top Boxes to remote controls and if desired, the Internet. An RF4CE network handles control and monitoring functions. Its limited data rate of 250kbps means that video data streaming is definitely out!
Hardware: RF4CE ZigBee Remote Control Development Kit. An evaluation kit for Silicon Labs’ EM34x wireless System-on-Chips and modules, it also contains everything needed for RF4CE development.
Short-Range Data Link
A short-range two-way indoor data link can operate in the 2.4GHz frequency band and the first protocol that springs to mind is Bluetooth. It was originally developed for ‘cable-replacement’ with a maximum bit-rate of 1Mbps (later versions up to 3.0 extended this to 3Mbps). One of the first applications was the wireless headset, originally marketed as ‘empowering’, now considered just plain embarrassing. Implementations are rated in terms of RF transmission power and hence communication range in four classes. Class1 devices have a theoretical line-of-sight range of up to 100m; Class 4 only about 0.5m. A Master device, such as a smartphone can link to a maximum of seven Slaves, such as the headset mentioned above or more recently, small loudspeakers. Versions 1, 2 and 3 of Bluetooth have since been re-branded as Bluetooth Classic.
Bluetooth Classic has suffered from two main weaknesses over the years: when switched on it has a tendency to drain batteries rather quickly, even when it’s not linked to anything. And it has dodgy security. The answer to both these problems has until recently always been: 1. Switch it off and 2. Keep it switched off. A less drastic alternative is to ensure that you use the minimum power class possible. There is absolutely no point in blasting out +20dBm of RF power (Class 1) to talk to a device 1m away. Even using a Class 3 device doesn’t necessarily offer complete immunity from eavesdropping. A snooper can massively boost the reception range of a Bluetooth receiver by attaching an RF front-end amplifier fed from a parabolic dish antenna (See Part 2 for antenna gain calculation). The vulnerability of Bluetooth lies principally in the interval of information exchange between a master and a slave device known as ‘Pairing’. Recent Bluetooth chips feature a ‘Whisper Mode’ which either uses an NFC link to establish the connection, or temporarily reduces the normal signal power. Moral: if you want to keep a secret, STOP SHOUTING.
A typical application for Bluetooth Classic might be for wireless hi-fi stereo link between loudspeakers and a laptop PC or TV. Most laptops have a Bluetooth v2 or v3 capability built-in and recent ones will be Smart Ready. For this design, Classic protocol is used because of the need for a reliable, continuous, relatively high-speed link with power consumption not an issue.
Hardware: Microchip RN-52 Bluetooth 3.0 Audio Module. An evaluation kit for audio including loudspeakers, RN-52-EK is available .
Short-Range Sensor Network
A classic IoT situation: a home full of sensor modules powered by batteries, or better still using Energy Harvesting techniques to get power ‘for free’. Bluetooth 4 encompasses all the earlier versions and adds a new protocol for the benefit of these IoT systems called Low Energy or BLE. Slave sensor devices only use the Low Energy protocol and are designated Bluetooth Smart. Master devices such as smartphones usually have a dual-mode capability, able to handle both Classic and Low Energy communication. These are classified as Bluetooth Smart Ready. BLE also enables ‘Connectionless’ or unidirectional communication – useful for Beacon networks now being deployed in many retail establishments.
Designed for sending small packets of data infrequently, BLE uses a much simplified protocol to ensure that the battery-operated transmitter consumes very little power. A Slave module announces its presence at intervals of say 100ms, via one of three ‘Advertisement’ channels selected not to interfere with the IEEE 802.11 (WiFi) channels 1, 6 and 11. A Master within range can then acknowledge and establish a link. BLE differs from Classic in that this process of establishing and then dropping a link is greatly simplified, allowing the remote sensor unit to communicate its small amount of data and then shut down quickly.
Hardware: MikroElektronika HexiWear Wearable Development Kit. Build a smart watch or a remote sensor tag based on Bluetooth BLE communication.
For an explanation of the slightly baffling term ‘Connectionless’ let’s look at an example ‘Beacon’ application using BLE. Beacons will turn your own smartphone into a pushy salesman whenever you enter a shop fitted with the things. Sorry, I mean Beacon technology will greatly enhance the Customer Experience on your Journey to Fulfilment in a retail context. A beacon is, as its name suggests, just a transmitter. It spends most of the time ‘asleep’, consuming minimal power, waking up at regular intervals to Advertise itself by transmitting a short packet of data before going back to sleep again. This packet contains a unique identifier code and is picked up by any smartphone running the appropriate app that comes within range. The link is connectionless because the phone does not reply to the ‘Here I Am’ signal. Instead, the app uses the identifier to supply the user with information gleaned from its database or via the Internet. In this shop context, you may for example, be informed of perfect matching shoes to go with the outfit on the rail in front of you.
Hardware: Nordic nRF51822 Bluetooth Smart Beacon Kit.
Sensor Network with Internet Access
Most IoT applications will involve a connection to the Internet with data passing directly from the sensor network to the Cloud. In the scenarios discussed so far a local controlling device such as a smartphone processes and displays the data, perhaps recovering further data from the Internet as required by the App. In order to unleash the full potential of IoT, data processing will take place remotely and this requires Cloud software to have direct access to the sensors. Now here lies the problem: the Internet uses the hugely complex IP protocol designed for communication over a vast Wide Area Network (WAN). The limited capacity of the low-power sensor microcontroller is simply not good enough. Some sort of interface device is needed between the heavy-duty IP of the Internet and the low-data rate, low-power Wireless Personal Area Network or WPAN.
IPv6 over Low power Wireless Personal Area Networks - 6LoWPAN
The 6LoWPAN working group defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent and received over IEEE 802.15.4 based WPAN networks. The 802.15.4 standard pre-dates the IoT and there are many RF chips and modules around providing the necessary hardware.
Hardware: Atmel ZigBit 2.4GHz AT86RF233 XMEGA SoC Module. This wireless SoC works with ZigBee/IEEE 802.15.4 wireless protocols and can be used as the WPAN side of 6LoWPAN Gateway.
This SoC isn’t powerful enough to perform the protocol conversion from the Internet connection by itself. To achieve that, some serious ‘muscle’ is required such as an ARM Cortex-M4 based microcontroller.
Hardware: L-TEK 6LoWPAN IoT Gateway Module. The module performs the necessary protocol conversion allowing WPAN-based sensors to communicate with the Cloud via its Ethernet LAN connection.
The Thread Group is a consortium of IT hardware/software companies who have defined an open protocol for home automation based on 6LoWPAN.
Coming Up Next
When I started this series on IoT communication, the plan was for two, possibly three posts. One difficulty has been determining how much basic RF design theory is needed to put together a working and legal system using the available hardware. Another is the rate at which new chips/standards/protocols/service providers keep appearing. Anyway, in Part 5 I intend to cover long-range systems, comparing LoRaWAN and SIGFOX, both contenders in the area of low-data rate wide-area networks for IoT. Cellular radio (mobile phone) providers may in the end become the major IoT players by implementing a narrowband protocol running over the existing 3G and 4G networks. The first radio modules compliant to (deep breath) 3GPP Release 13, Narrowband IoT (NB-IoT) LTE Cat. NB1 are available now….
If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues.