Helium.co: Connect devices to the web without Wi-Fi, Bluetooth or Cellular
helium.co
helium.co
- 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)
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.
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
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.
Anyway, batteries come in standard voltage ratings - 1.5, 3, 9, 12, 24, and a host more. You select a battery that has the same rating as your electrical tool's requirements, so the voltage is already known, and the charge is delivered within the tolerance range of that voltage rating. And whether you're working in amp-hours or joules, you still need to know the voltage rating of your power source, so you will have this information at hand - it's utter nonsense to think that the only rating you need to know would be joules, or that the voltage for a given model of battery would be mysteriously unknown (and even if it were, trivially solvable with a multimeter, unlike amp-hour or joule).
> In theory, there is no difference between theory and practice. In practice, there is.
I've read this a few times and I'm still at a loss as to what you're trying to say.
> reporting power consumption in mA is used in industry, so it's useful to report.
The example you gave is of a different industry. This device is a digital communications module, and so I'd expect information to be provided in a form which is useful for digital electronics desginers to use. The data provided by the Helium people is not sufficient to understand the power use of the radio. I agree that reporting current draw during transmission is useful, but it is only one of a number of figures required to allow an accurate assessment of the radio's capabilities and power consumption. The electronics industry has standardised on multi-page datasheets to provide key information on device functionality. There's a reason for this. Ultimately the information given about the device is not sufficient to allow a design engineer to make an accurate assessment of its capabilities.
Yes, I am not a digital device engineer. I did, however, sit next to them and provision their designs for customers (also tested various bits of firmware for same). The 3G specialist low-power modems we used were rated by mA. Replacement modems we looked at were primarily rated by mA. Yes, there are datasheets, but the convention was to talk in current draw, not total power. Not to mention the original complaint was "they reported A, not j", not "they reported A, not a datasheet".
I look forward to hearing you explain how 3G modems are 'different' to digital communications, just because they're transmitting over a paddock rather than a tenement.
I've read this a few times and I'm still at a loss as to what you're trying to say.
Well, basically it's saying that you using terms like "completely" is wrong. There are plenty of places in the real world where things don't follow the script laid down by "shoulds".
You are not partially wrong. You are 100% wrong. Learn to accept feedback now or you will learn later when the stakes are higher.
Or, seen from a customer's perspective: If this company is as stubborn and misguided about this, how much more of reality are they unwilling to allow in? Why shouldn't I go with a vendor who faces reality?
AmpHours are not the same thing as reporting milliAmps. And neither one is power consumption. And neither one is useful for estimating power consumption. And don't bother looking for counter examples. That would be like showing me someone who said, "I drove three volts to work this morning."
As far as your second paragraph, it demonstrates an extremely sparse knowledge of electronic engineering. Yes, you kind of have some things kind of right, but not enough to communicate or make important decisions. I would highly advise you to take on a seasoned electrical engineer stat.
For example, you say "it's utter nonsense to think that the only rating you need to know would be Joules," but do you realize by only giving current you're doing the same or worse?
This is all neverminding the entire dimensions of time and the long-term implications of those two things junior electrical engineers always screw up: heat and vibration.
How can I possibly appease you, if you refuse to read my words properly - that is, even when the relevant italicised phrase is prefixed with exactly the criticism you're making? There's also a couple of other spots where you've twisted my words to better target your ire.
Why on earth should I 'learn to accept feedback' of this shoddy quality?
I too agree that 0.026mA is completely meaningless to me.
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).
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.
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.
Note that lead-acid batteries are rated in amp-hours AND a voltage. With those two pieces of information together, one can compute their power capacity. Your boss only had people show A·h in the tool, b/c most people working with lead-acid batteries know the voltage of their batteries. The voltage of the Helium device under question is unknown.
The fact that people are downvoting EEs below makes me weep for the future.
Note that your boss was also overly pedantic. One can clearly see Ah is valid on the wikipedia page [0]. It follows the same form as Nm or N·m being valid for Newton-meters [1].
[0] http://en.wikipedia.org/wiki/Ampere-hour [1] http://en.wikipedia.org/wiki/Newton_metre
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'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:
channel capacity in bits/second = bandwidth in Hz * log2(1 + signal power / noise power).
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!
* 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!
No thanks. Great on paper, but bad in practice, no?
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.
Never should your product be at the mercy of such things.
Still, it's an interesting scale-up of weak signals.
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.
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.
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.
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.
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....
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.
Negative. We are completely different products.
-sean
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.
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).
http://www.dresden-elektronik.de/funktechnik/products/radio-...
Based on the price structures at the time, it made a certain mad sense.
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.
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.
Why is this a lingering post at top of news.ycombinator?
thanks for your interest.
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.