7

I am lost in a forest of IoT protocols and need help. I'm looking for right hardware and protocol for my application. I would like to make a device of my own, but use an existing stack and hopefully an existing gateway, my requirements are:

  • Low Energy, battery powered
  • Send-and-sleep
  • Medium range (20-30m)
  • Point-to-point or star topology
  • Ready-to-use or easily configurable gateway
  • The data will be sent in small packets, the frequency can be for example once per 10 seconds

If possible, please address each of above points in your recommendation.

Wi-Fi, BT, BLE, Z-wave, ZigBee, XBee, LoRa, Ingenu, TI15.4... It makes my head hurt.

4

As is often the case, it depends. There are many factors to consider, and a lot of options available to cover the many different use cases around.

Range

DigiKey suggest that you can expect the following ranges for common IoT protocols in an unobstructed environment with little interference:

  • 5 GHz Wi-Fi: 50 m
  • ZigBee/RF4CE: 100 m
  • Bluetooth low energy: 100 m
  • 2.4 GHz Wi-Fi: 150 m
  • Bluetooth low energy using Bluetooth 5 extended range capability: 200 to 400 m (depending on forward error correction coding scheme)

In most environments, you will not achieve this range, so adding extra 'headroom' would be a useful idea to guarantee that even in harsher environments, you still meet your requirements.


Power Consumption

The format of the data you're sending is going to really determine which protocol you want, given that many options meet your range criteria.

Wi-Fi, for example, is designed to carry relatively large amounts of data at once, with throughput as a design priority. As such, frequent, small packets are poorly suited to Wi-Fi (that said, Wi-Fi HaLow may be worthy of further investigation, as it's specifically designed for long range, low power operation).

Part two of the linked DigiKey article has some benchmarks on power consumption which are quite helpful:

Bluetooth low energy

Power consumption = 24 μA x 3 volts = 72 microwatts (µW)
Bits per second (in typical sensor operation) = 960
Energy per bit = 72 µW/960 bit/s = 75 nanojoules (nJ)/bit

ZigBee

Power consumption = 30 mA x 3 V = 90 milliwatts (mW)
Bits per second (at maximum raw data throughput) = 250,000
Energy per bit = 90 mW/250,000 bit/s = 360 nJ/bit

Wi-Fi

Power consumption = 116 mA x 1.8 V = 0.210 W
Bits per second = 40 million
Energy per bit = 0.210 W/40 Mbits/s = 5.25 nJ/bit

I was keen to emphasise considering the size of your data earlier because the 'energy per bit' statistic is very deceiving if only a tiny fraction of the bits you send are your payload (as might be the case with Wi-Fi). It may be worth looking up benchmarks for packets on the order of the size you'll be sending; you'll find hundreds online which might help inform your decision, such as TI's Bluetooth low energy power calculation tool.


Gateways & Compatibility

Obviously, you wouldn't need a gateway if you chose Wi-Fi, but often the power constraints make other options necessary, in which case a gateway is generally needed.

Consider if your users are likely to have a gateway. For example, home automators might already have a 'smart hub' (these typically support ZigBee and Z-Wave along with Wi-Fi devices). In that case, they might not need another gateway, in which case it would be favourable to use one of the more commonly supported protocols. That said, some smartphones support BLE natively, which could potentially be useful in some cases—you'll have to decide whether it's useful for you.


While I can't tell you one or the other (likely several protocols would fit to varying degrees), this should give you plenty to consider and inform your decision more effectively. I might personally go for BLE from what you've specified, but it's a rather arbitrary choice; many of the other protocols I've listed would work just fine too.

  • Thank you for an informative walk-through. If you have some insight - which of the standards have resonable licensing if I were to develop a product. For example, I read that Z-wave is nightmare due to few manufacturers of hardware and strict requirements for the owners. – NoobPointerException Apr 4 '18 at 17:57
  • @NoobPointerException Unfortunately I don't have any personal experience on the licensing part, but for what it's worth, I've heard the same about Z-Wave. A cursory look at Bluetooth's requirements indicate they may be more straightforward to work with, but I can't speak from first-hand experience. – Aurora0001 Apr 7 '18 at 19:47
3

Given your requirements of range, power and proven stack Z-Wave is likely suitable candidate.

  • Low Energy, battery powered
  • Send-and-sleep
  • Medium range (20-30m)
  • Ready-to-use or easily configurable gateway
  • The data will be sent in small packets, the frequency can be for example once per 10 seconds

These Z-Wave modules can serve your purpose. The typical send and sleep mode currents are quite low, making Z-Wave ideal for battery operated devices. By specification, The Z-Wave devices stay in power save mode and consume low energy, and wake up only to perform it's function.

  • Point-to-point or star topology Z-Wave uses a source-routed mesh network architecture, which I guess works to it's advantage being low-power.

One limitation could be the number of devices a single Z-Wave network can support. As a Z-Wave networks can have a maximum of 232 devices. there are ways to overcome this limitation by creating separate networks though.

3

BLE will be the wiser choice.

Pros:

  1. You will find many ready gateway in the market.
  2. Range is variable, if you want it to be more then 20 m, you can use BLE-PA(Power Amplifier) modules, and then you can control the transmit power also for the optimization.
  3. According to your application, you can optimize for power. There is no other option I see which consumes less power than BLE.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.