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.
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.
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.
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.
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.
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.
It's solely based on throughput. The helium bridge has very little state. Our true limitation will be how much we can put in the air to a single bridge. Our metro networks will have a lot of bridges.
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).
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...
There are two things we're trying to convey here (but rest-assured we're not trying to be misleading):
1. We can support a lot of connections. I mean a lot. This is based on our design, but truly limited by the receiving radio.
2. 50 square miles is optimal conditions. It's hard to quantify how bridges and radio enabled devices will work in populated metropolitan areas. These numbers are solely based on field testing, not in metro areas.
I'm commenting because I'm genuinely curious about the technology, I'm not trying to tear anything down.
That said, the technology page is not very clear.
The wording doesn't currently indicate this is idealized or limit conditions. Because you say it covers tens of thousands of devices over such a large area, I assumed this would be expected (like a cell tower). Your description actually fits very closely with a cell network. Why would a device that covers only my home need to support connections with tens of thousands of devices? Would it cover me and all my co-workers at the office 1 mile away (well within it's 4 mile range)? Or would I be expected to have a bridge at home and in the office? Is it like a Femtocell in a mall or like the ZigBee bridge sitting in my living room?
Given that picture, I'm genuinely curious about the capabilities. Immediately below that paragraph are bars that show a 700+ day battery life and a transmission power of 0.025mA. Are these for a totally different use case? If so, I'm confused. If not, it's amazing and I'm very exited. How is a transmission power of 0.025mA @ 915MHZ possible at a range of 4 miles? I would have assumed 1000x that (at least) would be necessary on unlicensed ZigBee spectrum. Similarly power would need to be amped up on the receive side,... meaning receive windows would be costly.
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!
I switched from W to dBm at the last minute, so there might be mistakes. Anyway, I think it ends up being feasible, because you have some play with transmit power, the noise floor, reflections, and a better antenna, which will all change your number by a few 10s of dB in whatever direction you choose.
Definitely not the worst startup I've seen on HN. I think they can make something useful, since their goal is quite modest.
Thanks! I'm happy with my current job, but would love to play with your eval boards (in my copious spare time :) when they're available. Send me an email (jon@jrock.us) and I'll buy a couple to try when they're ready.
It's rare when I see a startup on HN where I initially think "this is impossible", but do a little math and find that it's actually quite possible. Easy? No. But you're going to have a much better time working with the laws of physics in your favor than you would if you came up with something theoretically impossible :)
In the interim, check out http://wsprnet.org/. There are lots of people on the forums that are interested in weak signal work. If you have (or get) a ham radio license, you can try sending WSPR from a raspberry pi with a long wire connected to an I/O pin. It's pretty cool! (I've been meaning to set this up at work to see if I can get the signal at home on various bands, especially VHF around 144MHz or 1.2GHz. If that works, I have no doubt that you guys will be successful. And I think it will work.)
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.
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.
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.
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.
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.
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.
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
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.
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.
> 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.
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).
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....
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.
"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.
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.
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.
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.
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!
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.
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.
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.
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?
"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.
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.
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.
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.
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).
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.
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?
106 comments
[ 4.2 ms ] story [ 227 ms ] threadAlso 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.
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.
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.
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
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
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%20wirel...
Edit 3: Old but good presentation on power usage in 802.15.4. http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf
It's solely based on throughput. The helium bridge has very little state. Our true limitation will be how much we can put in the air to a single bridge. Our metro networks will have a lot of bridges.
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).
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...
There are two things we're trying to convey here (but rest-assured we're not trying to be misleading):
1. We can support a lot of connections. I mean a lot. This is based on our design, but truly limited by the receiving radio.
2. 50 square miles is optimal conditions. It's hard to quantify how bridges and radio enabled devices will work in populated metropolitan areas. These numbers are solely based on field testing, not in metro areas.
That said, the technology page is not very clear.
The wording doesn't currently indicate this is idealized or limit conditions. Because you say it covers tens of thousands of devices over such a large area, I assumed this would be expected (like a cell tower). Your description actually fits very closely with a cell network. Why would a device that covers only my home need to support connections with tens of thousands of devices? Would it cover me and all my co-workers at the office 1 mile away (well within it's 4 mile range)? Or would I be expected to have a bridge at home and in the office? Is it like a Femtocell in a mall or like the ZigBee bridge sitting in my living room?
Given that picture, I'm genuinely curious about the capabilities. Immediately below that paragraph are bars that show a 700+ day battery life and a transmission power of 0.025mA. Are these for a totally different use case? If so, I'm confused. If not, it's amazing and I'm very exited. How is a transmission power of 0.025mA @ 915MHZ possible at a range of 4 miles? I would have assumed 1000x that (at least) would be necessary on unlicensed ZigBee spectrum. Similarly power would need to be amped up on the receive side,... meaning receive windows would be costly.
The basic equation is:
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!
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.
Definitely not the worst startup I've seen on HN. I think they can make something useful, since their goal is quite modest.
It's rare when I see a startup on HN where I initially think "this is impossible", but do a little math and find that it's actually quite possible. Easy? No. But you're going to have a much better time working with the laws of physics in your favor than you would if you came up with something theoretically impossible :)
In the interim, check out http://wsprnet.org/. There are lots of people on the forums that are interested in weak signal work. If you have (or get) a ham radio license, you can try sending WSPR from a raspberry pi with a long wire connected to an I/O pin. It's pretty cool! (I've been meaning to set this up at work to see if I can get the signal at home on various bands, especially VHF around 144MHz or 1.2GHz. If that works, I have no doubt that you guys will be successful. And I think it will work.)
phark!
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.
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.
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.
End-to-end 256-bit SSL encryption
You can further encrypt your own payloads to keep them extra secret from us too.
If by the manufacturer, then it is potentially a security and privacy concern.
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.
thanks for your interest.
Receive-only technology that covers 50 square miles is old hat: radio, TV, ...
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.
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.
We only use the same hardware standard as Zigbee. Nothing else.
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....
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.
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.
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.
Negative. We are completely different products.
[1] https://github.com/chrissnell/GoBalloon
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.
* 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!
shoot us an email, would love to speak more!
Never should your product be at the mercy of such things.
No thanks. Great on paper, but bad in practice, no?
Based on the price structures at the time, it made a certain mad sense.
https://github.com/geuis/helium-css
Why is this a lingering post at top of news.ycombinator?
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).