
Helium.co: Connect devices to the web without Wi-Fi, Bluetooth or Cellular - fabrice_d
https://www.helium.co/
======
inoop
Looks like pretty standard WSN tech. Some points of critique:

\- Range: 50 square miles? That would imply a range of r=4 miles, which is
pretty impressive. Is this single hop, or are they 'cheating' by implying a
multi-hop network? The best I've seen is >1km on an Australian deployment
where the base station was on a hill and the nodes were deployed on a lake,
and this was using an nrf905 on the 915 MHZ band with a whip antenna iirc.

\- Power consumption: 0.026mA. Amps is a measure for current, not energy? I
can send 10 bytes at near-zero average amps as long as I do it only once per
millennium. This number is completely meaningless without a time scale. They
should just report mJ if they want to talk about the energy consumed in a
single operation.

\- 765 days life time. Again, they are not reporting the full story here: what
is the size of the battery? What type of battery? Is this estimated, or
measured? These nodes typically use MSP430's and may have a very, very low
sleep current (e.g. ~8uA for a tmote). However, the numbers quoted by the
manufacturer are often averages, and there may be significant differences
between nodes
([http://www.cse.msu.edu/~glxing/docs/ipsn13-Nemo.pdf](http://www.cse.msu.edu/~glxing/docs/ipsn13-Nemo.pdf))

Two years is a very typical life-time for sensor nodes. However, you can only
get that with very, very low data rates (e.g. one packet every minute). If
you're doing multi-hop, nodes close to the sink (bridge) will drain faster as
they have to relay not only their own data, but that of nodes down the routing
tree as well. So, you might end up with a situation where the life-time of the
network is much lower than that of an individual node.

\- Nitpicking, but one day is not typical at all for cellular. Sure, your
phone only lasts a day on a charge, but that is mostly due to to the main SoC
and display. If you look at the modem in isolation, most of the energy is
spent in energy tails, which you could cut down considerably on a network that
supports fast dormancy. If you don't care too much about latency (i.e. you
want your nodes to upload data only once per so-many hours or even days), you
can easily go a week between battery swaps.

~~~
vacri
_They should just report mJ if they want to talk about the energy consumed in
a single operation._

Nah, not really. When your battery is rated in "amp-hours" and you're being
extremely tight with your radio, turning it on and off as necessary, it's fine
to measure it in mA - the time unit is 'silent'. Radio was on for 10 seconds?
Take 10x0.026 off the amp-hour stored in the battery. My last workplace dealt
in agricultural telemetry based off solar-panel charged lead-acid batteries,
rated in amp-hours. Amp-hours are similar to units of energy, but are subtly
different - really they are actually measuring storage of electrical charge,
which is not the same thing: [http://en.wikipedia.org/wiki/Ampere-
hour](http://en.wikipedia.org/wiki/Ampere-hour)

They even had to put unicode support into the software configuration tool,
because the boss was very clear that the proper unit for amp-hour is A·h, not
Ah.

~~~
inoop
| Nah, not really.

You are absolutely correct about the difference between Joules and A·h, but
what I am pointing out here is that they have omitted the time-scale entirely.
They are not talking about continuous draw here, they explicitly mention the
operation of transmitting 10 bytes, which should always be reported in terms
of energy, not current/power.

So are they trying to report average current, or energy? Well, a typical
wireless chip consumes several mA during rx/tx, not 0.026mA. This means they
either have invented a wireless chip that is three orders of magnitude more
energy efficient compared to industry standards, or they are talking about
average current over time (for example, an NRF24L01 consumes up to 14mA during
rx/tx: [http://www.nordicsemi.com/eng/Products/2.4GHz-
RF/nRF24L01](http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01)).

I think we can safely assume therefore that they are talking about average
current draw. Coming back to my original point, what is missing from their
numbers are duty cycle and data rate. In other words, how often does the chip
wake up to transmit a packet, and how many packets/hour can I pump through
their network?

Given that BLE is just a standard 2.4MHz packet radio, which should draw a
comparable amount of current to what they are using, it seems obvious the main
difference is traffic rate and duty cycle, which they don't report.

~~~
vacri
The numbers did seem a little low to me in consumption (and certainly their
bar graphs are way out), and I took it as granted that they weren't including
power up or down times - you're certainly very right in saying that there
isn't enough detail given for consumption.

I'll take it on the chin, but just say that in my experience in my previous
job, I firmware-tested and provisioned 3G modems for low-power usage in remote
telemetry units. Not an EE myself, I worked closely with them, and when they
were looking for replacement modems from various vendors to replace an end-of-
life model, the primary (relevant) stat listed and discussed was mA rather
than joules - it seemed normal to me that mA was acceptable to mention for the
task.

Sorry for the delayed comment - HN speed-post limitation.

------
ggreer
I'm way out of my area of expertise, but I'd really like to know more about
the underlying technology. I searched around a little, but I'm not sure about:

1\. The frequency band(s) it operates on.

2\. Average/best-case data transfer rates.

3\. Energy usage. Sending 10 bytes uses 0.026mA? Ok... that's current, not
energy. To get power usage (watts), you need voltage and current. To get
energy usage (joules, watt-hours), you need voltage, current, and time. I
assume the voltage is the same in the Bluetooth comparison, but it's unclear
if both radios are on for the same amount of time.

4\. The bridges. Claimed coverage is up to 50 square miles, so sqrt(50/pi) ==
4 mile range. Are directional antennas required for that? Is this a limitation
of the protocol or the radio?

Based on the information available, I'm guessing this is an IEEE 802.15.4[1]
device running on the 900Mhz ISM band. Transfer rates probably peak at
250Kbit/sec.

I think the energy comparison to Bluetooth is disingenuous. Bluetooth probably
has more expensive startup costs. Sending 10 bytes may take much less energy,
but Bluetooth's faster data rates may allow it to win on a 10 megabyte
transfer.

It's interesting, but I really want to know more before considering the
product.

1\.
[http://en.wikipedia.org/wiki/IEEE_802.15.4](http://en.wikipedia.org/wiki/IEEE_802.15.4)

~~~
nielsbot
If you look at the image at the bottom of the "tech" page, there's a picture
of a device + a tag that reads "802.15.4"

~~~
densone
Helium Protocol is based on 802.15.4. You are correct.

~~~
amscanne
How can one bridge handle tens and thousands of devices and cover 50 square
miles per the tech page? That doesn't make sense.

~~~
jrockway
Well, they don't tell you the bitrate. WSPR is a protocol that can make
worldwide contact on the HF bands (3-30MHz) with 0.01mW of power. The catch is
that it takes 2 minutes to send a message like "KD2DTW/FN30".

900MHz signals don't propagate like HF (by refracting off the top of the
ionosphere), but they do have interesting propagation characteristics like
bouncing off of passing airplanes. If you have a protocol that can extract
signals from below the noise floor, and enough erasure coding (reed-solomon,
etc.) to handle bursts without connectivity, you can build an urban network
fairly easily. The only problem is that it's not that useful.

My guess is that they are like FitBit and just plan to blanket every home with
one of these things, and allow devices to roam to whatever access point is
closest (like when you walk past someone's house with a FitBit, and notice
yours has synced).

~~~
amscanne
The site says specifically that _one_ bridge can cover tens of thousands of
devices and 50 square miles.

It also seems to be based on ZigBee (that is, ZigBee devices can be
retrofitted) so it's 2.4ghz, 915mhz or 868mhz.

Like you said, there are plenty of ways to go one way (from a powerful
transmitter). But those are noisy frequencies for a weak transmitter to make
it several miles...

Anyways, agreed that the plan is probably fitbit-style. But the crazy specs
make it seem a bit like snake oil to me...

~~~
jrockway
This doesn't sound that unbelievable to me. You don't need a lot of power to
send a receivable radio signal. (GPS is a good example, the satellites are
20,000km away and transmit at 25W, but GPS still works just fine!)

The basic equation is:

    
    
      channel capacity in bits/second = bandwidth in Hz * log2(1 + signal power / noise power).  
    

So let's say they are using 1MHz of spectrum (WiFi uses 20-80MHz), are
transmitting at 1mW EIRP, and have an omnidirectional receiving antenna (there
is no such thing, but "assume a spherical cow", it's the worst-case anyway).
At the claimed range of 4 miles, the signal will lose 100dB because of "path
loss" (actually spreading out), giving you ~ 1e-10mW (-10dBm) of signal at the
antenna. Let's set the noise floor at -60dBm which I have not really measured,
but sounds good. That's 1e-6mW. Plug this into our formula and you get a
bitrate of about 1 bit every 7ms. That's ~20 bytes per second!

So let's say that we want to collect a sample once a second from 256 devices.
We get 20 bytes per second, so can sample every 256 seconds (let's say that's
5 minutes). There are 256 devices, so each one gets a 1 byte ID. Then you have
19 bytes of payload, which is fine for things like thermometers or your FitBit
or whatever. Fill the rest with an error-correction code.

Now you have 256 devices, each using 0.01W of power for 1/256 of the time.
With a 5Wh cell-phone battery, that's enough for 14 years of transmissions.

Now, to get thousands of devices, you can use more spectrum; there is plenty
more in the ISM band. You can transmit with more power, 0.01W is what a
Raspberry Pi IO pin can transmit connected to a long wire. You can get a
directional antenna, since you probably aren't listening for signals from the
sky or underground. You can also send less data.

Anyway, I ran the numbers and I don't think this company is claiming to
violate any laws of physics! It all sounds quite possible, actually, with the
right engineering work. I'm looking quite forward to purchasing an eval board!

~~~
amscanne
Isn't your math off?

Due to path loss, rx signal is 1e-10mW => -100dBm, not -10dBm.

Plug into the formula and we have a maximum theoretical bound of ~ 0.14
bits/second, or one byte every 42 seconds.

~~~
bryanlarsen
Even 1 byte every 42 seconds would be very useful for many types of sensors.

~~~
amscanne
That's with the transmitter on 100% of the time.

------
drfritznunkie
When will you all be posting more information about the hardware module? I'm
curious about the specifics of the hardware, (basically datasheet stuff for
those of us actually designing hardware):

* supported voltages: 5V, 3v3, 1v8, ...?

* module communication: SPI, i2c, TTL serial, etc.

* module programming: sounds like there is a way to load my key on to the module, will that be done through the attached platform? Or will you need a proprietary programmer?

* footprint for the module: not only dimensions, but keep aways (antenna, etc), orientation, etc. And from the website photo looks like there are no mounting holes on the pcb, and those are especially handy when prototyping

* external antenna: I realize this throws a monkey wrench in the FCC cert, but there are going to be applications where an external antenna is going to be a necessity. Any plans for an external antenna module?

* EN pin: the Iq on many of these radios make it necessary to completely disable them for extreme power savings. Be curious how quickly the radio module can cold boot and establish a link with a base station.

As for the network, no mention of communications with the devices, strictly
one way? No ability to push updates to sensors in the field?

I'm missing a couple of others, but I'm too braindead to think of them at this
hour.

This looks like it could be a huge time saver for those looking to build out
sensor networks, I hope for your success!

~~~
pharkmillups
dr, Can send you data sheet on module. Email hello@helium.co \- Not sure on
1v8 \- SPI / UART \- All module and bridge programming happens OTA \- We have
arduinos for making pocs, the module is currently 19x12mm I believe. \- Our
next module will have u.fl. (in the works now) \- Network goes in both
directions. Access from the internet via ipv6. drFritz.xx.helium.io. -You can
also communicate to other devices. The other device can be anywhere as long as
it's on the helium network and you are allowed to speak to it.

shoot us an email, would love to speak more!

~~~
paletoy
How is this protocol better than LoRa(by semtech - an old stable company, used
by giants like IBM) ,or weightless(standardized protocol) ? Because they are
your competitors , not wifi and the like.

~~~
amalag
Sounds like Helium is taking those technologies and adding a bridge?

------
empressplay
So... the idea would be I'd design, engineer and manufacture a (presumably
hardware) product at great expense that's essentially 'locked-in' to a single
proprietary network that could a) spontaneously cease to exist due to
insolvency or such, b) increase my access costs arbitrarily or through
acquisition or c) become detrimentally unreliable through poor scaling or
other disruption, and I would have absolutely no recourse or ability to
transfer my products over to another method of communication without initially
building in such a 'fallback' (in anticipation of these potential pitfalls) at
even greater expense?

No thanks. Great on paper, but bad in practice, no?

------
sarahj
> End-to-end Security

Not, it should be noted, End-to-end Encryption :)

It would seem, according to another comment in this thread, as if the bridges
and platform have de-facto access to all traffic unless another layer of
encryption is performed.

Apart from some vague notions to 256 bit and SSL there is very little written
about the security and threat model of the network.

Unless I am also reading the marketing wrong, this also seems to be
positioning itself as a new communication network - completely centralized to
a single company/organization - with no published standards. Compared to wifi,
bluetooth and to an extent the mobile network - I can't see a winning use case
for this.

~~~
mgraczyk
"The Helium Protocol uses a modified-802.15.4 frame for transport, and
existing ZigBee deployments can be retrofitted to run Helium."

They are using something similar to 802.15.4 for at least their physical
layer. If their power numbers are correct, then they are probably not using
any of the specified 802.15.4 physical layers exactly to spec.

------
pling
Proprietary radio stack. Nope.

Never should your product be at the mercy of such things.

~~~
nosequel
See pharkmillups reply here to a similar concern:
[https://news.ycombinator.com/item?id=7982051](https://news.ycombinator.com/item?id=7982051)

------
powera
For the record, I'm calling shenanigans. Solving multiple problems "magically"
with a product in a closed beta, with no press about people having tried it?
Seems unlikely that it will do half the stuff promised in the next 3 years.

------
eric_bullington
I got excited for a moment and thought this was a TV white spaces deployment,
which (in my mind) holds the best promise for establishing a nationwide
wireless mesh network[1]. Base stations that support TVWS are beginning to
appear on the market.

Still, it's an interesting scale-up of weak signals.

1\.
[http://en.wikipedia.org/wiki/White_spaces_(radio)](http://en.wikipedia.org/wiki/White_spaces_\(radio\))

~~~
inoop
TV white space has certain problems that make it unsuitable for extremely low-
power applications. For one, the FCC requires you to periodically query a web
service to determine which channels are currently unoccupied at your location.
If you are mobile, you need to query every so-many meters (~50, I believe, but
don't quote me on that), which would mean querying every 40-odd seconds
assuming an average walking speed of 1.2m/s.

Even if you're not mobile, e.g. an environmental sensor or relay station, you
will still need to periodically check to see if there isn't a wireless
microphone or other device occupying the band you're transmitting on.

Querying a web service over a 3G connection will cost you anywhere between 2-6
Joules depending on hardware, network conditions, network features (fast
dormancy, state transition time-outs) etc.

So for battery powered and/or low data rate applications, staying in an
unlicensed band like 433, 868, 915, or 2.4 is still the best option by far.

~~~
eric_bullington
Right, I agree. As I read about the project, it was clear this wasn't an ideal
use case for TVWS.

Are you sure you have to query the TVWS database out-of-band? I assumed the
cognitive control would run over the TVWS connection itself.

------
api
I'm very curious about how bridges work. How do they provide ipv6 connectivity
if most of the networks they are connected to do not issue ipv6? Or do they
require it?

Also does Helium operate a cloud-based proprietary service discovery bus? It
sort of sounds like ipv6 + cloud db + some custom protocols + low power wide
area wireless.

Not knocking it... Sounds very useful for all sorts of things.

~~~
pjc50
There are various 6-to-4 technologies and tunnels, presumably they use one of
those in conjunction with 6lowpan or similar. I'm guessing the radio side uses
the old analogue TV bands, because the whole thing sounds very similar to the
"Weightless" whitespace radio system.

~~~
densone
Not using 6low. All frequencies we use are unlicensed spectrum.

------
kazinator
A big clue about the technology is the dropped hints that it's related to
Zigbee:
[http://en.wikipedia.org/wiki/ZigBee](http://en.wikipedia.org/wiki/ZigBee)

~~~
pharkmillups
Hey Kazinator -

We only use the same hardware standard as Zigbee. Nothing else.

~~~
stevenrace
So is this basically a TI Chipcon 2500 + Contiki + and a small ARM linux box
acting as gateway?

Are you just making Zigbee hardware API calls - or custom firmware? Are you a
part of the Zigbee aliance? How did that effect development?

As for claims of range, I'm impressed. Since 2010 onward my startup has built
various configurations of Zigbee networks (some >100sq km) - but only saw a
max reliable range of 4km (rooftop of 4th floor, clear line of sight,
1W)...which prompted experiments in moving things down to 433Mhz. Just curious
what magic is going on....

~~~
pharkmillups
stevenrace: Custom non Zigbee firmware. Let's talk hardware design over email
some time? sean@helium.co

------
chrissnell
What's the radiation pattern for the bridge's antenna(s)? I'm building a
couple of high-altitude balloons and writing code for them in Go. [1] My plan
is to use AX.25/APRS for most comms but I'd love to run a secondary payload
with a Helium device if there is coverage up above.

[1]
[https://github.com/chrissnell/GoBalloon](https://github.com/chrissnell/GoBalloon)

~~~
pharkmillups
Chris very cool. We have a golang driver for helium that will be opened up
soon.

The bridges use multiple omnidirectional chip antenna per radio. Each radio
also has a u.fl connector so you have choices. Hope to see you sign up for the
beta. Would love to see this in action.

------
speeq
Is Helium connected to the SigFox network?:
[http://www.technologyreview.com/news/527376/silicon-
valley-t...](http://www.technologyreview.com/news/527376/silicon-valley-to-
get-a-cellular-network-just-for-things/)

~~~
pharkmillups
Hey Speeq -

Negative. We are completely different products.

------
Sanddancer
This tech looks interesting, but at the same time, kinda underwhelming for
certain aspects that aren't talked about. For example, one of the things I'd
like to use something like this for is for creating adhoc meshes in areas that
may or may not have good internet access, so anything that requires internet
access to set up things like multicast is a no go for me. While I realize part
of the business model for products like this is running the network, at the
same time, there are lots of uses for products that can talk to each other in
a manner easier than you can currently do.

~~~
pharkmillups
Hey Sanddancer, Helium can run without direct access to the internet. It's
designed to be a small portable stack. Shoot us a message. Would love to hear
about some of your use cases. hello@helium.co

-sean

------
guidedlight
What problem does Helium solve, when Wi-Fi, BT and Cellular works for most
people?

Most wireless access methods are inefficient and consume large amounts of
battery because they try to cram dozens or thousands of devices into extremely
limited, heavily regulated, congested spectrum. Most wireless technologies
work very well in laboratory conditions - but then suffer in the real world
because of this.

It's not clear whether you are doing anything new here to overcome this
fundamental issue, except attempt to introduce another 'standard' to compete
in the same crowded space.

~~~
derefr
Presumably, this would _mostly_ be a connection standard for devices that
aren't owned by "people", per se.

In a true Internet of Things, the Things that matter aren't really consumer
goods; they're the Things which make someone money or perform some civic
function, and for which it isn't readily apparent when they _stop_ working,
unless someone notices and reports the failure. When these devices can report
their own failure, they can be fixed much more quickly.

The most vivid (and banal) example of this is a paper towel dispenser in a
washroom, which can report when it runs out of paper. Other examples include
power/water meters (which already operate over 3G), transit card readers (also
3G), traffic lights and cameras, parking meters, etc.

It'd also be interesting to use it for drones, though. Anything that can save
battery life better spent on flying would be great for that industry.

------
noonespecial
I don't like that the radio is closed and that the network is owned, but I
love the direction of tiny IoT modules that _already have their fcc certs
done_.

I'm hoping someday the "intentional radiator" portion of getting a product
online is as simple as sticking in a SIM card now ( _in Europe_ I add
sarcastically).

~~~
pharkmillups
Hey noonespecial, Just a quick point. The radio is based on 802.15.4 which is
an open standard. Much of our end node code is going to be open source, if not
all.

------
cryo
More detailed infos would be nice, I wonder how these compare to the following
AVR 802.15.4 SoC modules

[http://www.dresden-
elektronik.de/funktechnik/products/radio-...](http://www.dresden-
elektronik.de/funktechnik/products/radio-modules/oem-modules-
derfmega/description/?L=1)

~~~
pharkmillups
Cryo, we know that module well and it works with Helium. Dresden make an
excellent SoC. Shoot us an email, hello@helium.co

------
geuis
I understand that common names are reusable. I understand that your product is
different than mine. Still, I wish there was still some respect when choosing
product names, especially open source projects.

[https://github.com/geuis/helium-css](https://github.com/geuis/helium-css)

~~~
achr2
You would have a valid point if the name you chose was even tangentially
related to what your project does.

------
rancur
stop telling me WHAT it does (dime/dozen and I can come up with that quickly)
and tell me HOW it does it

------
robot
"Our first MAN is being rolled out in San Francisco" for a fraction of a
second I thought this is a network created by men walking on streets with some
form of connectivity gadgets. You know, like the ones holding signs on the
pavement. I guess I am watching too much louis ck.

~~~
noonespecial
I know this is a joke but a company I used to work for had a _serious
discussion_ about hiring sandwich board men to walk around with mobile
hotspots that would inject ads and provide certain local services to those
connected.

Based on the price structures at the time, it made a certain mad sense.

------
CompuHacker
Being unfamiliar with wireless authentication/encryption; What prevents the
Helium bridge/platform from impersonating a specific Helium device? Could they
originate a false message or change the timestamps on an old message?

------
kazinator
If a bridge covers 50 square miles, it means that a device must cover 50
square miles to reach a bridge. How does it do that on such low power usage?

Receive-only technology that covers 50 square miles is old hat: radio, TV, ...

~~~
amscanne
I had the same question.

It seems to run on unlicensed (I.e. noisey) spectrum because existing ZigBee
devices can be retrofitted.

The tens of thousands of devices and 50 square miles per bridge makes no sense
to me. That's like a cell tower. I'm assuming it's a mistake.

~~~
noselasd
50 square miles is about a 4 mile line of sight range. I have a GSM BTS the
size of a normal wifi router(though the antenna is a bit bigger) that can
handle that.

------
leke
So are going to see our favourite smart phones being Helium-powered smart
devices in the near future?

------
dotBen
I'm curious what kind of eavesdropping is feasible on this band. It's not
clear if there's encryption built in, especially if low power, and the long
distances make for some attractive triangulation opportunities too.

~~~
densone
Hey dotBen. Messages are aes-256 encrypted. Every single device on helium has
its own unique secret. We will be writing about this on the blog very soon.

You can further encrypt your own payloads to keep them extra secret from us
too.

~~~
sweis
Are the unique secrets defined by the user or at manufacture time?

If by the manufacturer, then it is potentially a security and privacy concern.

~~~
pharkmillups
Hey Sweis -

There's a whole process to how the secret for each device is created. That
secret is used to ensure helium connectivity is safe. You can then securely
implant your own secret into a chip we use and that secret can be used to
encrypt your payload. Helium never has to know what you are sending. We just
need to know where it's going so we can get it there for you.

We'll be posting more docs on this in the coming weeks and months. Feel free
to shoot me an email if you want to chat more before they are available.

------
jmspring
Essentially a bunch of hype based around yet another proposal for adhoc(++)
networking limited to a geographic region.

Why is this a lingering post at top of news.ycombinator?

------
Shuank
I'm curious about the latency

~~~
pharkmillups
Shuank, helium edge routers will have a global footprint to minimize latency
to the internet. We always want latency from the internet to helium enabled
devices to be as low as possible.

------
kator
LOL the beta signup doesn't submit? I guess they don't want anyone to sign
up...

~~~
densone
kator. Checked and it seems to work. Just make sure you fill out all of the
fields and the submit button will light up or you can email me. sean@helium.co

thanks for your interest.

~~~
cvan
Even when the form was valid, it didn't work for me (checked in both Chrome
and Firefox). I had to manually remove the `disabled` attribute on the submit
button to post the form.

~~~
kator
Yup I gave up didn't have time to hack it..

~~~
pharkmillups
Kator. we are looking into it. Please feel free to email hello@helium.co

------
viksvevo
thats great news

------
notastartup
Curious how this is being pulled off. How can devices connect without any 3g,
wifi or bluetooth?

~~~
pauly
radio frequency

------
madaxe_again
This is an American company - we should be suspicious of their intent with all
of this data on their network, as it'll likely end up in the hands of the NSA.

~~~
pharkmillups
Hey Madaxe. Helium never has to know the contents of a payload. We encrypt it
to keep the information secure, but you can further encrypt that payload via
your own requirements with very little effort.

------
vxNsr
If this company gets successful at all they may run into the AT&T effect of
being a monopoly of a useful technology.

Their biggest strength is that they are the first ones in the field, their
biggest weakness is that they own the tech, it's difficult for people to trust
someone who owns the entirety of a market.

