It seems these days all the electronics projects are wireless in some form. Whether you choose WiFi, Bluetooth Classic, Bluetooth Low Energy, ZigBee, Z-Wave, Thread, NFC, RFID, Cell, IR, or even semaphore or carrier pigeon depends a lot on the constraints of your project. There are a lot of variables to consider, so here is a guide to help you navigate the choices and come to a conclusion about which to use in your project.
We can really quickly reduce options down to the appropriate tech with just a few questions.
Does it need to connect to the Internet?
If it does, and it needs to maintain a constant connection, then the answer is almost certainly WiFi. A WiFi connection will get its own IP address, manage the connection with the router, and send and receive packets on its own. Considering you’ve probably already got the wireless router, this is pretty much a done deal. Many people are prototyping with the ESP8266, but there are other options as well, and one hacker favorite is the Particle Photon (formerly the Spark Core). The Electric Imp is also regularly used, but doesn’t have the open source component that Particle does, or the price that the ESP8266 line does.
That doesn’t completely eliminate the other options, but they require additional complexity. BLE and ZigBee, would require another hub that is connected to the Internet. They exist (like the disabled Revolv), but it’s additional hardware you may not have, or may not be able to rely on your customer to purchase. They also don’t have the bandwidth that WiFi would have.
Cellular connectivity is another option when you are far from wireless or can’t rely on it. The biggest downside, though, is that it is expensive. It is getting cheaper to prototype, but paying for data can get ugly fast, and developing a product at a larger scale is extremely difficult and expensive. Most of the carriers require extensive testing and certifications before they’ll allow a product to connect to their network, so the gap between prototype and large scale production is pretty daunting.
Does it need to connect to a smartphone?
If it does, Bluetooth is probably the way to go, with WiFi and NFC coming in second and third. Bluetooth Classic is older and is used for high-bandwidth streaming like wireless headphones. But Bluetooth Classic is super sketchy with lag, dropped connections, and range problems. Bluetooth Low Energy (sometimes called Bluetooth Smart) is the newer version. It’s completely different and is designed for IoT or low bandwidth applications. Don’t let the Low Energy part fool you, though; because it transmits a lot less frequently with a lot less data, it can get away with much higher power transmissions, leading to significantly longer range. For BLE there are a lot of options for modules. A personal favorite is BlueGecko (which changed names from BlueGiga when they were purchased by Silicon Labs), but PunchThrough design has the LightBlue Bean, an OTA programmable, Arduino compatible device, and a module for scaling up production. Or check out the Tiny BLE in the Hackaday Store.
WiFi is another technology that almost every smartphone has, but setting up direct connections can be a real pain. It interrupts the phone’s internet connection so you can’t do WiFi to the Internet and WiFi direct to a device. It’s much easier when using WiFi for the device to connect to the smartphone through the Internet, much the same way it’s sometimes easier to email yourself a file rather than transfer it over USB.
If your bandwidth requirements are tiny (a few bytes), and your range requirement is tiny (centimeters), then you can try NFC.
Do devices need to talk to each other?
If devices are talking to each other for some reason, then WiFi is a great option here, ZigBee, is awesome, and there’s an upcoming spec called Bluetooth Mesh which will be breaking into the scene soon.
Here range is important, and so is power. Any device that is able to participate in a mesh must constantly be listening for messages. This means it will either chew through batteries, or it will need to be mains powered. Other devices may need to communicate with the network, but don’t pass messages back and forth, so they can turn on, say what they need to say briefly, then go back to sleep. In the ZigBee, world, the powered devices are called routers because they listen for and route traffic, and the battery powered devices are called end devices because they cannot have children of their own. There’s a third type called the coordinator, and there is a single coordinator in every ZigBee, mesh network, usually connected to a gateway to the Internet.
Knowing your range is important because if you need a range further than a base station, you have to have some kind of mesh network. If your WiFi router only gets you to the back door of your house and you have sensors in your garden, you need a WiFi range extender at the back door, or a ZigBee, network with nodes spread out so there is a path from one sensor to the next to the next. It’s not difficult to imagine a warehouse floor where the wireless doesn’t extend very far but a series of ZigBee, sensors plugged in act as a mesh network and ZigBee end devices connect regularly to spit out some data and go back to sleep. WiFi is a star network, so the router acts as a single point of failure. ZigBee is a mesh, so if any node goes down, it’s still possible for the network to continue working. ZigBee doesn’t have many modules, but XBee is a popular one.
Another option is Thread, which is IPv6 based. It uses 802.15.4, which is the same wireless protocol as ZigBee, but the IP-Addressable aspect is pretty appealing. This is still fairly new, so it’s hard to come by a lot of examples, but there are some big companies pushing it hard.
Bluetooth Mesh is a new entrant and is promising. CSR (recently acquired by Qualcomm) released a stack that implements a mesh network over Bluetooth LE, but they did it before a standard was published, so use it at your own risk.
Bluetooth LE might be enough for your application, though. With Bluetooth LE the concept is there are servers and clients. A server is the thing collecting the data or interfacing with hardware, and a client is the smartphone or other device that wants to be fed the data or send commands to the server. Clients can connect to multiple servers, and servers can have multiple simultaneous clients, but servers can’t really talk to other servers. Read more in our recent Hackaday Dictionary post about BLE.
Does it need to be close?
Generally with wireless technologies the advantage is that you don’t have to be close. But in some cases you want something to happen when two objects get close enough to each other, like a cat approaching an automated cat door, or a credit card tapped on a wireless card reader. For this you want either NFC or RFID. NFC is a subset of RFID but they have very different uses.
RFID can have much longer range (up to tens of meters). Tags can be active (battery powered and broadcasting), or passive (powered by the scanning device, so limited to the power they can absorb from the air). E-ZPass (for toll roads) is active, and your pet’s subdermal chip is passive. Generally they only transmit a single identifier, so the reader must look it up against a database.
NFC is much smarter and allows for two way communication. This is how phones can communicate with each other to transfer contact info or URLs, and in some countries subways use them, allowing you to get past the turnstile by tapping your phone. NFC is also how the touch to pay terminals work at retail stores. But expect the communication to be only a few bytes, and only when you’re within a few centimeters.
Do you want to be clever?
Sometimes you want to explore a new technology just to see if you can. There are a couple wireless transmission methods that have niche adoption but are still kind of cool. First is ultrasonic. Basically you play sounds through a speaker at frequencies above the human range of hearing but still within the capabilities of the speaker and microphone. Add some frequency analysis, and you’ve got yourself an easy wireless. This has been done with things like the Amazon Dash button, which uses a microphone to hear wireless configuration details transmitted by a special smartphone app.
Modulated light is another possibility. This uses pulsed LEDs to transmit data at very high speeds; so fast that you can’t see the flickering. Some people have played with using an RGB sensor placed over a smartphone screen to do control. Some banking apps in Europe use multiple blinking spots in a webpage to transmit data in parallel to sign transactions.
Of course, IR should be counted among modulated light, and while it’s been around for decades, it’s pretty reliable (indoors only), it works well, and it’s easy to do with minimum components.
Choosing your Chips
You’ve chosen your wireless technology, now you need to build it. Depending on what you’re trying to build, there are options for how this technology is packaged.
There are USB solutions for every one of these wireless technologies. No matter what you choose, you’ll be able to communicate with a computer over USB without having to develop any hardware. Plug a dongle into a Pi and you’re good to go.
The next step down is the Arduino shield, and again you’ll be able to find every one of these technologies as a shield. After that is a breakout board, which allows you to easily connect a special PCB to a breadboard or other headers.
Next down is the module. Modules are a godsend for product prototypes, small projects, and small- to medium-sized businesses without a lot of RF engineering resources. A company will develop a module which contains a PCB, the wireless microcontroller, and antenna, get FCC certification for this small PCB, and then sell it. The neat part is they’ve used tiny components so you don’t have to, they’ve mastered the magic of RF optimization so you don’t have to, they’ve handled the FCC certification so you don’t have to, and they have a software stack so you can just write the application layer and not worry about the lowest levels of communication. Modules are absolutely the way to go for prototypes and small runs of products, and many module vendors offer their modules in high volumes at costs that are only slightly above the cost of the components themselves.
But say you’re trying to miniaturize further, or you’re in volumes of hundreds of thousands. That’s when you should look into building your board based on the microcontrollers themselves, with your own antenna and balun and all that other stuff. It’s a lot of work, though, and unless you have experience with RF design, you will not make an optimized solution. You can do it, however, if you keep things smart and simple. But then there’s the step of certifications, which can be time consuming and costly.
Don’t discount the development environment, either. Some modules or chips require IAR, an IDE that can cost thousands of dollars. Others require development be done on free but closed tools. And some are just a monumental pain to set up. Your chip choice may come down to which development environment you are most comfortable with.
Whether you’re building an IoT water bottle or connected fork, there are lots of options for wireless tech, and a plethora of advantages and limitations to consider. Then there are lots of modules for just about every one of those choices.
(Image credit for the module in the center of the banner image: AutolycusQ on Wikipedia.)