Not Mesh - Helium is a Complete Platform for Connected Devices


#1

Not Mesh unfortunately…


Simple Device Connectivity

Connectivity starts with Modules. Helium Modules are FCC-certified and are small enough to fit almost any form factor. Modules talk to Bridges, and any device in range of any Bridge can connect to the network. One Bridge can handle tens of thousands of devices and cover 50 square miles.

Ultralow Power Consumption

At the device level, the Helium Protocol and Firmware combine to produce devices that require very little power to transmit and receive data. Byte for byte, Helium-powered devices far outlast devices connecting over WiFi, ZigBee, Cellular, and even Bluetooth Low Energy.

A Complete Platform

The brains of the network live in the Helium Platform, at the edge of the Internet. The Platform - powered by Helium’s distributed routing infrastructure - handles all device traffic in and out of the network.

When your data passes through a Bridge and arrives at the edge, the Platform handles the processing and then exposes it to your APIs. You can also integrate functionality like storage, analytics, messaging, and payments via our Platform Data Partners.

End-to-end Security

Payloads are encrypted from the moment they leave the device all the way to processing at the edge. Helium also enables you to reflash devices over-the-air (OTA) if a vulnerability needs patching. And Helium can be run entirely on-premise, meaning your device traffic never has to touch the public Internet.

No Data Limits

Helium imposes no limits of any kind on your device data. Although Helium is optimized for small data, devices can send and receive objects of arbitrary size. And the Helium Network imposes no fair use policies on your traffic. Send as much data as your applications and users need. We’ll happily deliver every byte.

Made for Developers

Our modules, shields, and development kits make prototyping dead simple, and Helium supports most popular platforms like Arduino and BeagleBone.

Helium Fusion is a powerful device management and dataflow engine that makes it easy to connect devices to the Platform and get data flowing to your APIs.

Standards Compliant

Under the hood Helium embraces and extends several powerful standards. The Helium Protocol uses a modified-802.15.4 frame for transport, and existing ZigBee deployments can be retrofitted to run Helium.

And every device on the network has an IPv6 address. Our innovative use of trusted protocols enables every device on the network to have a true Internet presence without the complexity of a full TCP stack.

Helium Fusion

A Dataflow Engine to Connect Any Thing

Fusion is a dataflow engine that lets you layer logic and functionality onto your data sources. Fusion makes it easy to turn device data into complete applications. Use Fusion to assemble and shape data, then wire it directly to your internal APIs or integrate with one of our Platform Data Partners to add components like storage, analytics, messaging, and payments. Fusion also gives you a complete view of your device deployments. Manage your devices, their flows, and monitor total device traffic all in one interface.

Fusion also lets you take advantage of all types of communication that Helium powers. Device-to-device, device-to-Internet, and Internet-to-device traffic are all possible on Helium. A weather sensor in Idaho can talk directly to a crop sensor in Nebraska via Helium, and these relationships can be built, tested, and deployed entirely in Fusion.

Unite millions of devices with one flow.
Flows are pieces of logic that enable you to transform, bend, and route data. Flows are flexible and intuitive, and allow business analysts and firmware engineers alike to prototype and deploy new functionality. Flows are also shareable. Helium developers can take advantage of flows built by other community members and modify them according to their use case. And Fusion lets you do granular deployment with flows, meaning you can apply them to one, many, or all of your devices.

Helium in the Enterprise

In addition to public networks, Helium hardware and software is also available for customized, private deployments. From Modules to Routers to application specifics, our team and partners will work with you to design, deploy, and support sensors networks.

Every industry stands to reap the benefits of simple, ubiquitous device connectivity. Early enterprise adopters will be best positioned to capture large pieces of the coming $21.9T in global economic value-add projected across all verticals.

Global Interoperability

Data from any device on any Helium network can be routed and integrated with other devices, systems, and services.

Security

Helium can be used to construct entirely private networks. Your device and sensor traffic never has to touch the public Internet.

Low Hardware Footprint

Bridges require minimal power, space, and maintenance. Routers are discrete pieces of hardware that live alongside existing infrastructure in any data center.

Fully-supported

Helium comes packaged with response-time SLAs and 24/7 production support from expert engineers.

Public, Private, or Hybrid Deployments

Enterprises can deploy on our MANs, create dedicated networks, or take advantage of both.

https://www.helium.co


#2

A very interesting aspect is the 50 square mile coverage per bridge. The bandwidth/latency and other desirable characteristics may or may not be there but the range alone is really something. As per the bandwidth I saw something about 2mbits per module, but don’t know if that is meaningful and would like to tech evaluations of the bandwidth of the bridge and projected prices for the units. Really exciting though. I also keep wanting cheap free space optical as I think that might be a good complement and would be interested in knowing if people with the background think that is a viable complement for mesh toward the goal of replacing the functional core of the current net as quickly as possible. I know its a moving target driven by demand and complicated by an ocean of data centers and lit/unlit fiber etc.


#3

Question in the Helium Forum


Details of underlying Technology

Is there a whitepaper or details of the underlying signalling available?

I’m doing some research on ‘Software Defined Radio’ that could run in a Mesh mode…not much out there.

I have no idea at this stage if your platform would be a fit for the SAFE network (fully decentralized), but please feel free to check it out and pass comment if you have the time: http://maidsafe.net/overview2


Thanks for the question. We’ll be rolling out a new website and expanded resources over the coming weeks and months - so most of what I mention here will be covered in depth in blog posts and docs - but here’s the high level on the Helium architecture:

Helium Protocol - Long range, low power, highly secure communication. It uses the 802.15.4 for the PHY and runs at both 2.4 GHz and Sub GHz. The protocol uses UDP for transport and MessagePack for data encoding. And all data is encrypted end to end using AES.

Helium Modules - The device-level components that drive connectivity and run the protocol firmware. You can see the forthcoming version here (until the new site is live). Coming in around 19x19mm, they are built on commodity components and can usually be customized based on use case and form factor.

Helium Gateways - Small, cheap pieces of hardware that run the Helium Module to connect to N devices in range; and some backhaul method (WiFi, Cellular, or Ethernet) to connect to the Internet. Very literally a dumb bridge between 802.15.4 and IP. One Gateway can handle connectivity for 1000s of devices in range.

Helium Platform - All data sent to and from device passes through our platform infrastructure. We offload a lot of the processing and logic to the platform. Virtual IPv6 addressing and security are two of the biggest components here. (All your devices get a complete IPv6 address without the hassle of TCP locally.) The platform also enables things like letting a Helium-powered device to connect to any Gateway in range.

All communication is (currently) device -> gateway -> platform (and vice versa for the reverse). By example, here’s what happens when a device joins the network successfully (eliding over some security details): It’s powered on; it fires off a frame asking to join the network; a gateway in range routes that to the platform where it’s processed; the platform sends a frame to the device via a gateway authorizing it join the network, thus initiating a session. This whole process takes ~300ms.

Related to the above blurb, we’re not doing any meshing at the moment (which probably takes us out of the running for the Maidsafe use case at this point). We might investigate it in the future but at the moment the tradeoffs around code complexity and power usage at the device level are too great. And given the low cost, tiny form factor, and minimal power usage of Gateways, it’s straightforward for Helium and/or our users to create coverage.


#4

PCell power usage seems pretty minimal, but as we’ve become accustomed so far its only suggesting half a use case and minimal as it is it may not be minimal relative to some of the IOT Helium type devices where I think the aim is 10 year battery life or something like that.