Return to Blog Home

802.15.4 Wireless for Internet of Things Developers

In a vast world of wireless technology, developers building connected products face a difficult choice when selecting a wireless layer for their applications. How do you choose which technology will highlight your product and give you robust connectivity in an unpredictable physical environment? And at what price point? This blog post highlights the Helium team’s thought process and criteria in selecting a wireless implementation with our primary user, the Internet of Things developer, in mind.

The Helium Way

Helium’s wireless technology is an implementation of the IEEE 802.15.4 standard with enhancements to ensure security, upgraded bandwidth, ease of development, and ease of use. All Helium-based devices use the Helium Atom Wireless Application Module and connect to the Element Access Point with dual-band 802.15.4 radios over 2.4Ghz and sub-Ghz frequencies.

Major advantages of Helium’s approach include hardware-based security with end-to-end encryption, authentication and authorization. On top of this we’ve also built zero-configuration onboarding for all Helium-based devices, so they can join the Helium wireless network securely without credential management on the part of the user.

It seems like every IoT company touts its wireless technology as having the longest range, best ability to navigate to wireless interference, and lowest power consumption. For Helium to select a wireless layer and protocol, we had to optimally solve for range, battery life, security and developer experience, while leveraging our team’s experience in the wireless world.

The Customer Problem (Or: How I learned to Love the IoT Crystal Ball)

We focused on understanding developer requirements in IoT and their associated problems vs. selecting existing wireless technology based solely on features and availability. In Helium’s world of wireless communication, we concentrate on handling small amounts of data from large numbers of low-power devices (using batteries, solar, energy harvesting, etc.) – meaning we never planned to stream Netflix over our wireless link. Sensing applications built on Helium frequently require sleep and wake cycles in asynchronous patterns with the product providing real world interrupts from activity alerts in a given application. In the case of a basic sensor, developers can imagine this taking the form of a temperature, humidity, pressure, occupancy or weather alert.

When looking at the options, we started with the following design criteria:

  • Development Environment
  • Data rate
  • Range (network coverage)
  • Security
  • Power consumption
  • Network topology
  • Network directionality (uni-directional vs bi-directional)
  • Network size
  • Network reliability
  • Backhaul
  • Available spectrum
  • Standards licensing
  • Available parts
  • Cost

Once we had the categories defined, we mapped these against the available technologies. As a brief overview, here are some existing solutions within our design criteria.

Technology Frequency Data Rate Range Power Usage Cost
2G/3G Cellular Bands 10Mbps Several Miles High High
Bluetooth/BLE 2.4Ghz 1, 2, 3 Mbps ~300 feet Low Low
802.15.4 subGhz, 2.4GHz 40, 250 kbps > 100 square miles Low Low
LoRa subGhz < 50 kbps 1-3 miles Low Medium
LTE Cat 0/1 Cellular Bands 1-10 Mbps Several Miles Medium High
NB-IoT Cellular Bands 0.1-1 Mbps Several Miles Medium High
SigFox subGhz < 1 kbps Several Miles Low Medium
Weightless subGhz 0.1-24 Mbps Several Miles Low Low
Wi-Fi subGhz, 2.4Ghz, 5Ghz 0.1-54 Mbps < 300 feet Medium Low
WirelessHART 2.4Ghz 250 kbps ~300 feet Medium Medium
ZigBee 2.4Ghz 250 kbps ~300 feet Low Medium
Z-Wave subGhz 40 kbps ~100 feet Low Medium

Lastly, we had to decide not only based on the factors above but also what would provide the best possible experience for developers using Helium. Helium needed to make hard choices for our own product definition that isolated clear winners especially in the data rate, power usage and range categories. Narrowing down the options, we also leaned on the experience of our team and decided to pick the IEEE 802.15.4 standard.

Another IoT standard? Really?

The wireless standards battle is messy to say the least and it appears there isn’t “one standard to rule them all” for the Internet of Things. We decided to enhance the existing IEEE 802.15.4 standard and build our own wireless protocol based on network models already working in 2013.

Developers creating IoT products would be hard-pressed to implement low power device networks that mesh (mesh networks’ devices have to stay awake to serve as “hops”), so we selected a star topology in order to allow all sensors to sleep. By doing that and controlling the transmit rate, we are able to control the power usage of an entire Helium deployment from the Helium Cloud. Having in-depth protocol control also gives us the unique opportunity to add additional RF power amplifiers and low noise amplifiers along with antenna diversification to extend the range of Helium-powered devices.

At the time of this writing, the IoT standards wars rage on, with no clear-cut winner capturing dominant market share while making it easy for developers to build connected products.

The Advantages of Helium’s Approach

On range: 802.15.4 was already in a good place, but we felt very strongly that the Helium Atom Wireless Application Module needed dual band wireless with intelligent switching between frequencies as a product feature, so we had to find a sub-Ghz transceiver for 802.15.4. Sub-Ghz (specifically 915Mhz in North America and 868 in the EU) gave us a leg-up to expand our network coverage and made sense for us since we were already implementing our own protocol. And Helium wireless communication is bi-directional between sensors and the Helium Cloud, providing great flexibility and greater security guarantees for developers building on top of us.

With all the information on wireless protocols compiled, we soon found that we could support higher than normal data traffic – sending more than just sensor readings over the Helium 802.15.4 implementation. We designed into the protocol a method to manage firmware updates and modify sensor business logic via over-the-air from the Helium Cloud. Armed with this feature, developers using Helium can truly “deploy and forget” connected products, managing everything from sensor sample/transmit rates, alerts and sensor business logic such as local data analysis from the Helium Cloud. The latter two examples are accomplished via Helium Script, a programming language that runs across the Helium IoT stack including on the sensors themselves.

Lastly, the elephant in the room: security. IoT security is an unsolved problem in 2016, with large-scale breaches reported on a daily basis. It was much the same when we had to make our selection in 2013. It appeared as though software defined security and pre-shared keys dominated the landscape in terms of availability, but we knew we couldn’t follow in the footsteps of these failing security models. We also knew it was critical that we implement hardware-based encryption with tight integration into the wireless protocol. This same encryption would eventually carry from the sensor edge up to the Helium Cloud to protect our customers’ applications.

In closing, determining which wireless technology would be good for our users 3+ years in advance was a significant effort, but the customer feedback and results we’re seeing in production deployments are validating our approach. Wireless hurdles are never fun (and maybe impossible) to overcome once a project is underway. We’ve already done the hard work to help customers at any stage in their development cycle and speed up time to market. The hope is we can prevent developers from losing time and money as they set out to build the connected devices of the future.

Want to Learn More About Helium? Talk to us!

  • If you’re interested in finding out more about Helium, visit for an overview of our products.

  • Development kits and all necessary hardware to start building connected products can be purchased at

  • Join our Slack community at and speak directly to the Helium team as well as other Helium developers.

  • If you’d like to discuss an upcoming project with us, let us know and we’ll get in touch soon.