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)
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.
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
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.
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.
The numbers did seem a little low to me in consumption (and certainly their bar graphs are way out), and I took it as granted that they weren't including power up or down times - you're certainly very right in saying that there isn't enough detail given for consumption.
I'll take it on the chin, but just say that in my experience in my previous job, I firmware-tested and provisioned 3G modems for low-power usage in remote telemetry units. Not an EE myself, I worked closely with them, and when they were looking for replacement modems from various vendors to replace an end-of-life model, the primary (relevant) stat listed and discussed was mA rather than joules - it seemed normal to me that mA was acceptable to mention for the task.
Sorry for the delayed comment - HN speed-post limitation.
Without a defined voltage, mA and mAh are meaningless. We could assume that they used a 3.7V lithium battery because that tends to be the case with this type of technology, but it isn't stated anywhere. The criticism is completely valid.
In theory, there is no difference between theory and practice. In practice, there is. The criticism is not completely valid - I've just given you an example of where, in industry, it's used in the same manner as originally mentioned. You can shout at the wind that it's blowing wrong, but it's still going to blow - reporting power consumption in mA is used in industry, so it's useful to report.
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).
> reporting power consumption in mA is used in industry, so it's useful to report.
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.
do you realize by only giving current you're doing the same or worse?
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?
Hopefully this video will kind of get at what all the other folks here are trying to point out regarding mAh or Ah being an utterly useless "power consumption" unit without explicitly defining the voltage.
I too agree that 0.026mA is completely meaningless to me.
Your comments suggest to me that you're not a practising electronics engineer and don't have much experience with digital electronics design. You've demonstrated confused thinking about the meaning of units and complete ignorance of digital design processes.
> 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.
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.
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".
AmpHours are not similar to units of energy. They are not subtly different from units of energy. They are completely different. The difference between a drawing of a house and a house.
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].
Amp-hours or joules, you still need to know the voltage of your battery. It seems the strangest criticism being made against me: "Aha! If you're using amp-hours, you must also know the voltage!", as if this is an otherwise irrelevant detail. The exact same people pinging me would have an equally apopepltic fit if I said "just hook up any old battery, voltage is unimportant, as long as you've got a lot of joules!".
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.
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...
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.
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.
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.)
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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....
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.
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.
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
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.
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.
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.
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.
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.
"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.
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?
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).
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.
Shuank, helium edge routers will have a global footprint to minimize latency to the internet. We always want latency from the internet to helium enabled devices to be as low as possible.
kator. 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.
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.
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.
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.
- 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.