Which Wireless Tech Is Right For You?

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.

The LightBlue Bean, a small (and very hackable) Bluetooth LE device.

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.

The BLE113 Arduino Shield

The BLE113 Breakout Board

BLE112 Module

Inside the BLE112 are the microcontroller, balun, antenna, and crystals.

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.)

Post navigation

43 thoughts on “Which Wireless Tech Is Right For You?”

been recently playing with hc05 BT modules that provide virtual serial links between radios. SPP is standard and you can have a phone pair with an hc05, a desktop or another hc05. its not forcing a protocol on me (binary) and I can use this as a transport to carry anything I want. but it does not support any kind of multicast or bus and I miss that.

previously I was using lots of xbees since they have the same transparent virtual serial term idea, but they also have the benefit that, if all radios are tuned to the same PAN-ID, they all receive the same data, like a party line. I used that feature for ‘message stealing’ in a creative way (one station can listen on the comms and passively do stuff when A and B are talking; it can be used well, actually; think about ‘one message transmitted and many stations being able to use that’. 1:1 messaging is only a part of efficient networking. multicasting or broadcasting is often more than just ‘nice to have’.

once mesh ble happens, that will fix this problem, but until then, I’m limited to 1:1 pairings and that kind of is a constraint that is too limiting for many IoT apps.

BLE as it exists now allows for a 1:many relationship. You can have multiple devices connect to a single sensor if the firmware supports it. BlueGiga’s modules can accept up to 8 simultaneous clients, so if you have a sensor that reports temperature, for example, then up to 8 devices can subscribe to notifications from that sensor.

its clumsy at anything other than 1:1. the binding and unbinding is too slow, for one thing! and not every station can be dual role (central and perif). BLE is quite a bad design, from where I sit. its a huge step backward in so many ways, its not even funny.

Yeah, BLE performs poorly at that. Honestly, there just isn’t a good, /non-proprietary/, mesh standard out there yet. There’s really two key features that are needed, which no one seems to have implemented in a high performance manner quite yet – TDMA-style wake-ups, and low overhead route discovery algorithms/protocols. I’ve been looking for that for years at this point, but it sounds like it’s a fairly difficult problem.

Digi’s new SX actually sounds reasonable, but it’s quite expensive per unit. They weren’t so good a few years ago (when Digimesh first came out) IMHO but they’ve gotten their stuff together now. From the tech end, Wirepas Pino sounds awesome, but I haven’t been able to get a hold of any low volume hardware that actually utilizes that technology.

For a non-proprietary mesh standard, Zigbee is very good and has been around a long time, so there are many options out there for product. The new Thread protocol (http://www.threadgroup.org/) offers some great improvements including easier commissioning, IPv6, and better security. Only issue is because it was just ratified, production product won’t be shipping until early 2017

Yes this. The 915MHz and 433Mhz $1 or less devices from HopeRF for example. There is self organizing ad-hoc mesh networking for these – I would have to look for it. They also can have impressive range and can work with a small Yaggi for a mile or more.

since getting into the multirotor hobby, I have learned that the nrf24l01 can be bought with an LNA and PA (amps at rx and tx). you can get very good range with a pair of those! if you can keep a quad in the air many meters away with that, it sounds good enough for most local area IoT tasks. and they are cheap as chips, too.

BLE can be used for some nifty stuff. But if you want to make a product around it you’ve got to pay significant $$$ to the Bluetooth SIG for licensing and testing, even if you’re using a module with a preloaded stack.

There should be some tutorial on how to interface with a network device in your software For Dummies ™ article.

In fact, if you don’t come from a software background, even if you’re just doing serial communications, you end up doing the whole user interface in the controller over a terminal window. Would be nice to see a few simple examples as to how you’d go about making eg. a simple windowed program that talks to your device and does something useful, like offload some computation from your controller.

The paragraph about cellular was true until the Particle Electron came out this year. The Electron is reasonably priced, both for the device and cellular data (no contract, $3 per month for 1 Megabyte, $1 for each additional Megabyte).

You’ll want to start on a WiFi router and not a shield or add on to a microcontroller. You want something with a better data path than SPI or serial port and much faster processing speed. Wireless routers are optimized for bandwidth with hardware packet forwarding and much better data path – Ethernet or PCIe or onchip radio.

Yes indeed for that “what about LoRa™” mention ! LoRa™’s range & reliability at slow data rates tends a near order of magnitude greater than normal UHF wireless techniques. In built up areas100s of metres instead of 10s are typical, with km instead of 100s of metres in rural applications. See => http://www.instructables.com/id/Introducing-LoRa-/

I tried to look at that Particle Photon, but it seems they require you to create an account on their website and login to get access to downloads, and it seems like they don’t offer local toolchains at all — all the information I can find says even the locally-installable IDE require Internet-connection because it sends your code to their servers for compilation!

Perhaps not exactly wireless but parasitically using existing wires…
Why are there so few powerline carrier options and such high prices vs wireless?
The most compact and inexpensive module I can find is KQ130f which has almost no English documentation beyond pinout and carrier freq, I am no expert but I would love to see some powerline carrier coverage on HaD so I dont have to order and test two of every(limited selection) transceiver set.
I am also concerned with the unique (to low voltage hackers) safety and communications issues as well as best practices when connecting a circuit board to 220v mains.

And no mention of power consumption? I see elsewhere (https://www.youtube.com/watch?v=IYuYTfO6iOs) that the ESP-8266 can run for (gasp) 17 days transmitting once an hour powered by a LIR2450 (CR2032 didn’t work…). BLE should get you several _years_ from a CR2032 at this rate…

I wouldn’t recommend any device to talk to the internet without considering security. The ESP8266 has Wifi security, so locally nobody could eaves drop without a lot of effort, but no higher level protocol security once it leaves your network, ie no TLS, so no Https etc.

It obviously depends on your application, but you should consider security at all times. Consider something as simple as time. If you have a clock and you just want the ESP to use NTP. that is fine, but using it for NTP in a heating or security application is a potential vulnerability. it is easy to spoof your system to do something you don’t want it to.There are tricks using TLS to get time and dates from servers.

But if you are opening up the ESP directly to the net for garage door control or homecontrol and automation. you are better sticking the interface behind a proxy or gateway (using a Pi or some other flavor) so you can have secure connections. At that point does it need to be Wifi? (Last leg is secure with WPA2 and the ESP is easy and cheap, but power hungry)

I’m really into NFC lately because there are some new ICs that allow you to create zero battery sensors. I built one to go in my bike tire or a football: hackaday.io/project/7077-rfid-air-pressure-sensor

Right now I’m working to get the cost down and to convert it to flex so I can mount it more easily.

I came to say that ZigBee is too expensive but it had been a while since I checked so I did a little searching first. I am happy to say that some time in the last few years ZigBee modules have come down in price a lot. Or at least there are cheaper ones (~$10) avaiable now if you look for them. I still see the expensive (~$30-$40) ones and didn’t look hard enough to spot the difference in features.

Anyway.. ZigBee is finally cheap enough that I can imagine using it in many projects around the house. But… I still probably won’t because even those cheap modules are still about 10X more expensive than other sollutions like NRFxxx chips, HopeRF, etc… I’m disapointed not to see anything like that in your article.

The way I see things these networking chips HAVE to be cheap. The reason is.. while one project may be important enough (in my mind) to spend more money on a better wireless chip another is not. I am going to want all my things to be compatible though. Preferrably they are going to all use one mesh. If that can’t be done easily enough then they can all talk to one access point in a star formation. I’m not going to want to maintain one network for some projects and simultaneously a second for others!

I guess this would mean I would use WiFi for everything since of course I already have a WiFi router. WiFi seems to have reliability issues in my home, probably interfereance problems. Unfortunately some things (like Chromecast and Miracast) are ONLY available for WiFi. I prefer to make everything that can work without WiFi do so in order to keep the WiFi frequencies as clear as possible for those things. Totally off topic but please.. somebody build and sell something like Miracast that uses Ethernet!

I’ve got an implementation question about cellular connections. If you buy an expansion card like the u-blox modem card and add it into your own box can you lean on the carrier certification of that card or do you have to resubmit your whole box/product+modem to be certified as a unit?

I’ve heard carriers will kick you off (blacklist) if you don’t have the exact product combo (with the modem) certified with them; and I’ve heard that as long as you aren’t modifying the signal characteristics they won’t. And certification appears to be expensive (?)

I have experimented a lot with BLE and found that the software was simply too complex for most of my needs and support is not quite good enough yet. I have used regular Bluetooth for wireless control of car air suspension bags. I put together an app easily using MIT App Inventor as it supports regular BT (not BLE currently). It worked well enough. Zigbee and the like are proprietary and so I avoid them. Nowadays I generally stick with WiFi as it is broadly supported and can be made quite secure using SSL. I keep a completely isolated net for my objects behind a dedicated router with only the necessary ports open. I use a GL-iNet router which is a neat low cost device that uses operWRT. I also use UDP where possible (with CoAP if supported) as that allows very quick response times from start up and lower power usage than TCP/IP. The hardware is a combination of ESP modules, RPIs and the CHIP $9 computer. The latter works great and is suprisingly well supported but still does not seem to be available in quantity. I use 13.56mhz NFC for very short distance communications like when I want to detect and identify an object placed next to a sensor. At one point I looked into using IR “flooding” for communication within a room but I think that for most applications WiFi is the way to go.

At a company I worked before, we used a mesh network with BLE (using the NRF BLE SoC) for one our product lines. I think it was some half-home-brewed solution, which was quite unstable, but we managed to get it working somewhat at least.

If there’s one thing I can count on for being unreliable in general purpose use, mainly connecting things to phones/tablets, it’s bluetooth. In well defined and implemented applications I would not be surprised if there are seamless and responsive Bluetooth applications, but I have yet to find one. BLE just made things worse.

My grown up job is advising retailers and manufacturers on which type of Home Automation kit to stock and sell, bluetooth for HA never makes the list, returns are too high. Granted this is not IoT, but a surprising amount of generic BT modules used in IoT are also embedded in some way in the kit that hits retail shelves.

An important consideration I outline for both parties is that while newer tech (i.e. BLE, Smart Bluetooth, Wifi Direct, WiFi HaLo) is cool and makes development easier or the user experience better, it also reduces the market share of devices (phones / tablets) that support it. BLE generates around 40% returns rate for applications where BLE is used for device to product communications. This is a shocking returns rate and has led to the policies I advise today. Where BLE is ok for use, is within the application itself e.g. between a sensor and controller or hub.

Where fashion / fitness / gadget tech is involved, the returns rate drops considerably, since this market tends to have later generation devices.

I just thought that the user is an important aspect to consider in the development of any application and this includes the entire thing you have created not working in an application because a user has a ten year old HTC droid, that barely supports Bluetooth, let alone BLE!