8 ms·

Helium.co: Connect devices to the web without Wi-Fi, Bluetooth or Cellular

225 points by fabrice_d 12y ago

api 12y ago
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 12y ago
  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 12y ago
    Not using 6low. All frequencies we use are unlicensed spectrum.
- densone 12y ago
  api. all good questions. 1) The IPv6 ends at helium's routing network. So, to and from the bridge can be ipv6 or ipv4. The devices ipv6 addresses live on the helium edge routers themselves. I think on our website it's a graphic that says "platform". 2) You are close. The devices are a custom protocol (no tcp/ip or udp at the device). 802.15.4 frames. 3) replace cloud-db with a distributed system that your programs and helium's programs can subscribe to, and send and receive data to helium devices or groups of device.. You will be able to communicate to the helium network, the same way our fusion application does.
  - api 12y ago
    Does your protocol do any NAT traversal if the bridge is stuck on an IPv4 network or behind a firewall that doesn't allow inbound? Like if I have two bridges, will traffic go point to point between them or does it have to visit Helium's servers? Also I'm curious about this distributed system. Is it based on a DHT, a meshnet protocol, some kind of distributed database, or something else? Or is it something simpler than that that lives in the cloud? I guess I'm wondering if you've gone into the realm of truly decentralized networking or whether this is a cloud-based service.
ggreer 12y ago
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
- notthetup 12y ago
  I think the website compares it to BluetoothLE which is a really low energy. But typical BluetoothLE data rates are much much lower than 250Kbits/s. I'm still surprised that they can bring it down to lesser active current draw than BluetoothLE which was designed for low-data rate, low current draw, short distance comms. Edit : Here's a app note on real life current draw of TI's BluetoothLE solution. http://www.ti.com/lit/an/swra347a/swra347a.pdf http://www.ti.com/lit/an/swra347a/swra347a.pdf Edit 2: Here's another research paper comparing ZigBee and BLE solution's current draws. ZigBee is almost an order magnitude larger in current draw. http://research.microsoft.com/pubs/192688/IWS%202013%20wireless%20power%20consumption.pdf http://research.microsoft.com/pubs/192688/IWS%202013%20wirel... Edit 3: Old but good presentation on power usage in 802.15.4. http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf
- nielsbot 12y ago
  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"
guidedlight 12y ago
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.
- nl 12y ago
  Most wireless access methods either have low range or low transmission rates or high power usage because of physics, not because of regulation. Eg, BTLE optimises low power at the expense of range and transmission rate. It sounds like this is optimised for low power, low transmission rates. There isn't really another widely available protocol optimised for that (except ZigBee). That's a very useful option - devices like FitBits and Garmin bike computers use all kind of work arounds involving teathering etc to try to make connected systems small and still connected.
- derefr 12y ago
  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.
dotBen 12y ago
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.
- X-Cubed 12y ago
  https://www.helium.co/#/tech https://www.helium.co/#/tech End-to-end 256-bit SSL encryption
- densone 12y ago
  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 12y ago
    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 12y ago
      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.
  - stevenrace 12y ago
    Is it prone to existing Zigbee attacks ('packet of doom', key extraction, etc)?
kator 12y ago
LOL the beta signup doesn't submit? I guess they don't want anyone to sign up...
- densone 12y ago
  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 12y ago
    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 12y ago
      Yup I gave up didn't have time to hack it..
      - pharkmillups 12y ago
        Kator. we are looking into it. Please feel free to email hello@helium.co
      - pharkmillups 12y ago
        Hey Kator, We figured it out. Hope you can give it a shot now.
kazinator 12y ago
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 12y ago
  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 12y ago
    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.
- dragonwriter 12y ago
  > If a bridge covers 50 square miles, it means that a device must cover 50 square miles to reach a bridge. Range isn't determined by the minimum of the broadcaster and the receiver, its more like the product of the receiving antenna capacity (a function of size, mostly) and broadcast power. So any stated range has to be not just the coverage of the bridge, but the coverage of the bridge given a presumed device on the other end.
- pavius 12y ago
  The only thing that makes sense to me is that given the same distance from the peer (the bridge in this case), it would consume less energy than BLE. They do claim, however, to accommodate longer ranges (by design) than BLE and I wonder if this holds true with no modification to the device itself (i.e. different RF blocks for short/long range).
kazinator 12y ago
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 12y ago
  Hey Kazinator - We only use the same hardware standard as Zigbee. Nothing else.
  - stevenrace 12y ago
    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 12y ago
      stevenrace: Custom non Zigbee firmware. Let's talk hardware design over email some time? sean@helium.co
sarahj 12y ago
> 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 12y ago
  "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.
deleted 12y ago
[deleted]
vxNsr 12y ago
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.
notastartup 12y ago
Curious how this is being pulled off. How can devices connect without any 3g, wifi or bluetooth?
- pauly 12y ago
  radio frequency
speeq 12y ago
Is Helium connected to the SigFox network?: http://www.technologyreview.com/news/527376/silicon-valley-to-get-a-cellular-network-just-for-things/ http://www.technologyreview.com/news/527376/silicon-valley-t...
- pharkmillups 12y ago
  Hey Speeq - Negative. We are completely different products.
chrissnell 12y ago
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 12y ago
  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.
  - deleted 12y ago
    [deleted]
drfritznunkie 12y ago
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 12y ago
  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 12y ago
    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.
powera 12y ago
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.
pling 12y ago
Proprietary radio stack. Nope. Never should your product be at the mercy of such things.
- nosequel 12y ago
  See pharkmillups reply here to a similar concern: https://news.ycombinator.com/item?id=7982051 https://news.ycombinator.com/item?id=7982051
empressplay 12y ago
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?
robot 12y ago
"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 12y ago
  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.
viksvevo 12y ago
thats great news
rancur 12y ago
stop telling me WHAT it does (dime/dozen and I can come up with that quickly) and tell me HOW it does it
Shuank 12y ago
I'm curious about the latency
- pharkmillups 12y ago
  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.
geuis 12y ago
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 12y ago
  You would have a valid point if the name you chose was even tangentially related to what your project does.
jmspring 12y ago
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?
noonespecial 12y ago
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 12y ago
  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.
CompuHacker 12y ago
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?
inoop 12y ago
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 12y ago
  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.
madaxe_again 12y ago
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 12y ago
  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.
Sanddancer 12y ago
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 12y ago
  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
cryo 12y ago
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-modules/oem-modules-derfmega/description/?L=1 http://www.dresden-elektronik.de/funktechnik/products/radio-...
- pharkmillups 12y ago
  Cryo, we know that module well and it works with Helium. Dresden make an excellent SoC. Shoot us an email, hello@helium.co
eric_bullington 12y ago
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 12y ago
  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 12y ago
    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.
leke 12y ago
So are going to see our favourite smart phones being Helium-powered smart devices in the near future?

225 points by fabrice_d 12y ago

api 12y ago

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 12y ago
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 12y ago
  Not using 6low. All frequencies we use are unlicensed spectrum.
densone 12y ago
api. all good questions. 1) The IPv6 ends at helium's routing network. So, to and from the bridge can be ipv6 or ipv4. The devices ipv6 addresses live on the helium edge routers themselves. I think on our website it's a graphic that says "platform". 2) You are close. The devices are a custom protocol (no tcp/ip or udp at the device). 802.15.4 frames. 3) replace cloud-db with a distributed system that your programs and helium's programs can subscribe to, and send and receive data to helium devices or groups of device.. You will be able to communicate to the helium network, the same way our fusion application does.
- api 12y ago
  Does your protocol do any NAT traversal if the bridge is stuck on an IPv4 network or behind a firewall that doesn't allow inbound? Like if I have two bridges, will traffic go point to point between them or does it have to visit Helium's servers? Also I'm curious about this distributed system. Is it based on a DHT, a meshnet protocol, some kind of distributed database, or something else? Or is it something simpler than that that lives in the cloud? I guess I'm wondering if you've gone into the realm of truly decentralized networking or whether this is a cloud-based service.

ggreer 12y ago

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

notthetup 12y ago
I think the website compares it to BluetoothLE which is a really low energy. But typical BluetoothLE data rates are much much lower than 250Kbits/s. I'm still surprised that they can bring it down to lesser active current draw than BluetoothLE which was designed for low-data rate, low current draw, short distance comms. Edit : Here's a app note on real life current draw of TI's BluetoothLE solution. http://www.ti.com/lit/an/swra347a/swra347a.pdf http://www.ti.com/lit/an/swra347a/swra347a.pdf Edit 2: Here's another research paper comparing ZigBee and BLE solution's current draws. ZigBee is almost an order magnitude larger in current draw. http://research.microsoft.com/pubs/192688/IWS%202013%20wireless%20power%20consumption.pdf http://research.microsoft.com/pubs/192688/IWS%202013%20wirel... Edit 3: Old but good presentation on power usage in 802.15.4. http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf
nielsbot 12y ago
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"

guidedlight 12y ago

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.

nl 12y ago
Most wireless access methods either have low range or low transmission rates or high power usage because of physics, not because of regulation. Eg, BTLE optimises low power at the expense of range and transmission rate. It sounds like this is optimised for low power, low transmission rates. There isn't really another widely available protocol optimised for that (except ZigBee). That's a very useful option - devices like FitBits and Garmin bike computers use all kind of work arounds involving teathering etc to try to make connected systems small and still connected.
derefr 12y ago
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.

dotBen 12y ago

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.

X-Cubed 12y ago
https://www.helium.co/#/tech https://www.helium.co/#/tech End-to-end 256-bit SSL encryption
densone 12y ago
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 12y ago
  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 12y ago
    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.
- stevenrace 12y ago
  Is it prone to existing Zigbee attacks ('packet of doom', key extraction, etc)?

kator 12y ago

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

densone 12y ago
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 12y ago
  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 12y ago
    Yup I gave up didn't have time to hack it..
    - pharkmillups 12y ago
      Kator. we are looking into it. Please feel free to email hello@helium.co
    - pharkmillups 12y ago
      Hey Kator, We figured it out. Hope you can give it a shot now.

kazinator 12y ago

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 12y ago
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 12y ago
  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.
dragonwriter 12y ago
> If a bridge covers 50 square miles, it means that a device must cover 50 square miles to reach a bridge. Range isn't determined by the minimum of the broadcaster and the receiver, its more like the product of the receiving antenna capacity (a function of size, mostly) and broadcast power. So any stated range has to be not just the coverage of the bridge, but the coverage of the bridge given a presumed device on the other end.
pavius 12y ago
The only thing that makes sense to me is that given the same distance from the peer (the bridge in this case), it would consume less energy than BLE. They do claim, however, to accommodate longer ranges (by design) than BLE and I wonder if this holds true with no modification to the device itself (i.e. different RF blocks for short/long range).

kazinator 12y ago

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 12y ago
Hey Kazinator - We only use the same hardware standard as Zigbee. Nothing else.
- stevenrace 12y ago
  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 12y ago
    stevenrace: Custom non Zigbee firmware. Let's talk hardware design over email some time? sean@helium.co

sarahj 12y ago

> 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 12y ago
"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.

deleted 12y ago

[deleted]

vxNsr 12y ago

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.

notastartup 12y ago

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

pauly 12y ago
radio frequency

speeq 12y ago

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

pharkmillups 12y ago
Hey Speeq - Negative. We are completely different products.

chrissnell 12y ago

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 12y ago
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.
- deleted 12y ago
  [deleted]

drfritznunkie 12y ago

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 12y ago
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 12y ago
  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.

powera 12y ago

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.

pling 12y ago

Proprietary radio stack. Nope. Never should your product be at the mercy of such things.

nosequel 12y ago
See pharkmillups reply here to a similar concern: https://news.ycombinator.com/item?id=7982051 https://news.ycombinator.com/item?id=7982051

empressplay 12y ago

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?

robot 12y ago

"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 12y ago
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.

viksvevo 12y ago

thats great news

rancur 12y ago

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

Shuank 12y ago

I'm curious about the latency

pharkmillups 12y ago
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.

geuis 12y ago

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 12y ago
You would have a valid point if the name you chose was even tangentially related to what your project does.

jmspring 12y ago

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?

noonespecial 12y ago

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 12y ago
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.

CompuHacker 12y ago

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?

inoop 12y ago

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 12y ago
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.

madaxe_again 12y ago

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 12y ago
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.

Sanddancer 12y ago

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 12y ago
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

cryo 12y ago

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-modules/oem-modules-derfmega/description/?L=1 http://www.dresden-elektronik.de/funktechnik/products/radio-...

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

eric_bullington 12y ago

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 12y ago
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 12y ago
  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.

leke 12y ago

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