As part of the series on choosing the right technology, we’ll go over the possibilities regarding communications.
Communications involves all the means of digital interaction between hardware/software devices themselves and with end users. This can be as simple as providing a USB port and serial terminal or GUI interface to your machine, but in most cases what you want is some kind of wireless solution.
These comes in many forms, mostly depending on “who” is doing the interacting, the type of messages or instructions being exchanged and the maximal range for the interaction. The most important options are NFC, Bluetooth, Wi-Fi, Zigbee and cellular.
Near Field Communication
NFC is useful when you only need a short range for exchanges and when the messages are relatively simple, such as authenticating to an access control system using a proximity card.
An important advantage is that only one side of the exchange, the reader, actually needs to be powered because the energy used by the card is provided via the communication field itself. The downsides are that range is usually low (we’re talking centimeters, here), the processing power on the card is quite small and it often means forcing uses to carry around yet another token.
The latest generation of bluetooth—Bluetooth Low Energy, or “Smart”—has greater range than NFC and is more ubiquitous: pretty much everyone is already carrying around a BLE-capable device with the smartphone in their pocket.
In addition, bluetooth is very flexible. Communications can be established between custom hardware devices, between devices and mobile, and the bluetooth modules can act either as clients (performing actions on remote devices), servers (accepting requests and commands from remote clients) or simply as information-bearing beacons. Bluetooth v4 is very power-conscious, so it’s possible to embed these transmitters in battery powered devices while keeping consumption low and extending battery life enormously.
Finally, most bluetooth modules are built with a “System on a Chip” (SoC) at their core, which can be used to run application firmware. This means that, rather than having a microcontroller handling the business logic and using the BLE component as a peripheral, all the code resides on the bluetooth module itself. This reduces part count in your project and the final complexity and cost of the boards.
The downsides with BLE are mainly in the areas of range and cost. You can expect communications to function well over a range in meters (we’ve seen 70+ meters in some applications, outdoors with no obstacles) but you won’t be much more than 100 meters even in the best circumstances.
Complete modules—that come with software stacks to speed development and are already FCC certified—are relatively expensive, but are a good way to create proof of principle and prototype devices quickly. These costs can be brought down significantly by developing custom solutions based on the underlying chips (e.g. the nRF51822) but that implies bearing the burden of software development and radio transmitter certification.
Either way, bluetooth meets the demands of all kinds of use cases, especially when users want to interact directly with devices through their mobile phones and tablets. Two really great BLE modules that we’ve worked with extensively are the
- Bluegiga modules; and
- The RedBearLab BLE Nano
though plenty of other solutions exist to meet varying requirements.
Sometimes it’s not so much about the communications range as it is about accessibility and amount of data you’re looking to shuffle around. When you’re looking for always on communication, need to transfer lots of information or want to be part of the “Intenet of Things”, using a wi-fi connection to tie-into the Internet is the way to go.
Wi-Fi connected devices can be accessible at any time, from any location, through the ‘net and can transfer great amounts of information at high speed. They are great for allowing interaction between machines and people.
One great chip for this is the ESP8266. There are a whole range of modules built around this component, and it is a powerful little beast. It can act as either a client (like a computer on the LAN), access point (AP) that allows any wifi-enabled device to connect to it, or both at the same time. We’ve used these ICs to create internet connected devices that run their own embedded webservers while at the same time acting as clients to other systems on the network.
This is another example of a system on a chip, where you can use the module as a simple peripheral or run you own application firmware directly on-board—it can even be programmed using the Arduino SDK, which means there’s a wide community of developers that help you with your development and many existing libraries that will work with it without modification.
The ESP8266 itself is quite inexpensive and even stand-alone modules built around it are pretty cheap.
The main downsides of using such a chip is that the range is comparable to that of bluetooth, you probably need some way to talk to the wider internet to make full use of its potential (meaning access to a WLAN would be required) and it can be somewhat power hungry compared to other solutions.
The ZigBee standard is in some ways the converse of Wi-Fi. It is designed to allow for easy communication between devices, consumes little power and is specifically suited to reliable, self-configuring and self-healing mesh networks. It is a very flexible and robust means of communications and it deals well with networks that are subject to interference and dynamic changes. The ZigBee standard is open and the devices are relatively low cost in production.
On the downside, though it’s great for communication between devices it isn’t as easy to interact with the network for humans—unlike for bluetooth and wifi, the devices everyone carry around don’t include methods of connecting through this protocol. In addition, it is meant to transfer small messages between co-operating devices, which is perfect in some applications but not so much in others.
Cellular is the way to go when you want to be able to communicate no matter where the device winds up (subject to carrier coverage, of course). Using a GSM or 3G cell network can allow for the advantages of wi-fi without the need to be tethered to a LAN and can be a great solution when your device needs extensive range and will be moving around or is to be located in some remote area.
There are different networks and capacities to choose from, so bandwidth is normally not an issue. The main downsides here are cost and power consumption.
The components themselves can be expensive but, more importantly, to connect to a network you’ll need an account with a carrier for each of your connected devices and the amount of data transferred can also impact associated fees greatly.
Also, getting a signal out over an extended range implies using a certain amount of power. Components we’ve used have required burst of a few Amperes, which impacts both the layout of circuitry to account for the current and the battery requirements. Still, with careful design and conscientious use of power saving modes and techniques, it’s possible to extend the life of a standard LiPo battery a good deal.
The best choice for cellular coverage will depend on the network to use and the host platform, and can be anything from a USB dongle with a Raspberry Pi, an Arduino cellular shield (e.g. the SparkFun Cellular Shield) or a dedicated GSM or 3G module included directly in your circuit board.
With that, we’ve covered the main options when it comes to connecting devices to each other and to the people who use them. Next in our tutorial on choosing the right technology, we’ll talk about processing: the heart of any intelligent device.