How New Long-Range Radios Will Change the Internet of Things
medium.com
medium.com
The current "hottness" in our space is bluetooth low energy (BLE). This is super low power (or, rather: chips that are really good at going to deep sleep, and then coming online very quickly to burst some data out), but the range on BLE isn't great.
Some companies use general purpose radios (these guys: http://www.glowcaps.com/ are basically an couple of atmega 328s and some 433mhz radios) for range, but it seems like everything is moving towards BLE because you can use your cellphone/tablet as a base station.
If LORA can seriously get this sort of range (I'm skeptical, honestly), then that is a total game-changer for IoT.
A friend of mine at a chip manufacturer in town was telling me about some radio thing they were doing that had range like this about a year ago, but I didn't believe him. That little of power, for that long of range seems like straight-up magic.
Super cool stuff! Very excited to see this really happening!
Not to get too silly, but this about sums up how this makes me feel with regards to IoT: https://media.giphy.com/media/rl0FOxdz7CcxO/giphy.gif
Would love to hear thoughts on it. Email address in my profile.
* How to exchange the topic key is described as out of scope, but totally critical since you also propose renewing the topic key as a way of attaining forward secrecy.
* You totally hand-waved away the exchange of participant keys.
* I'm pretty sure you've exposed some cryptographic weaknesses in the core protocol but I'm not going to spend the time to keep analyzing.
So in short, your protocol is not very useful. Sorry.
The biggest problems in IoT space are key agreement and machine trust among a hugely heterogeneous population. Solutions will come in the form of standards adoption, hegemony, government regulation, and probably a combination of all three. Multicast security is somewhat of a solved problem (e.g. wifi.)
Communications security between actual people is an entirely different and more easily solved problem.
There's no weakness there that's not fixable. Replay protection can be easily added in the layer above, and rolling the topic key can also be done. The nonce problem can go away with using the wider Salsa variant.
> How to exchange the topic key is described as out of scope, but totally critical since you also propose renewing the topic key as a way of attaining forward secrecy.
Where did you see that? I go into a lot of detail here: https://stringphone.readthedocs.org/en/latest/protocol.html#...
> You totally hand-waved away the exchange of participant keys.
See the previous point.
> I'm pretty sure you've exposed some cryptographic weaknesses in the core protocol but I'm not going to spend the time to keep analyzing.
Hmm.
> Solutions will come in the form of standards adoption, hegemony, government regulation, and probably a combination of all three.
"Don't bother working on it" doesn't sound like very useful advice...
What's the stop a MITM between a client and any other client from intercepting the conversation? In your protocol, nothing, except that if the MITM isn't there at the start, they can't join in right away. This is not a very useful assurance. So please, keep working on it, but I think your challenges are pretty serious. If the problems are fixable, then go ahead and fix them. I'd be happy to take another look - after that.
We're putting up a LoRa network here in SF, and plan to publish a bunch of our test data, including link error rates and throughput. Urban deployments are new so more data will help us all understand what's doable. (There are a few rural deployments in production; less uncertainty there.)
I'd love to put one in our hackerspace out here :) -- a few offices of people working on IoT would probably think that was pretty cool.
LoRa basestation gateways are available off-the-shelf for from Kerlink, Multitech, and Link Labs. The gateways are actually quite simple, they just forward packets to the cloud network server, and back to the clients.
I've been checking LoRa for months to do some projects, but all got to some bottlenecks. (E.g. here are some notes on a USB-stick LoRa communicator plans: https://hackpad.com/LoRa-USB-Communication-Stick-xKGgChuwbzL )
Both LoRa and Sigfox came out of French companies, and several wireless carriers have announced plans to build networks. Also check out The Things Network guys in Amsterdam who are trying to crowdsource a network, very cool stuff.
I signed up for your beta via your site. We want in asap.
LoRa only makes sense (and I've seen it used) in large infrastructure type uses like sensors that monitor roads or bridges.
These technologies are more exciting because you are talking about realistic coverage areas of square kilometers with inexpensive, unlicensed radios. Think of something like a large natural gas pumping field -- there are tons of industrial sensors and controls spread out over a fairly large area that don't need to send much data. I work in the radio industry, and these technologies, if they live up to their hype, will be industry disrupting.
Other technologies can have many more simultaneously communicating devices. In the case of OnRamp/Ingenu, a factor of 1600 more due to their encoding scheme.
Narrowband technologies like SigFox (based on TI radios), have way more than 64 channels available in the US, I believe in the range of 1000, but are more susceptible to interference.
We'll be using TI HW (Launchpad dev kit) on our SF event on Nov 20 (https://www.eventbrite.com/e/smart-city-iot-hackathon-connec...), but we're fully open on the hardware side.
Full list here : http://makers.sigfox.com/
LoRa radios that are close to a gateway can dynamically shift to a 300 Kbps mode, or down to a long-range mode that's ~10Kbps (but yes could also be degraded further by error rate if at edge-of-range).
BLE; you're talking about power requirements of ~10mA transmit (current consumption), and averages in the <10μA range. That's the whole point of the tech. It's stuff that can run for years on a watch battery.
Now: how LORA is accomplishing such crazy long ranges when supposedly consuming similar amounts of current goes a little beyond my understanding of RF. There are a few people commenting in this thread that seem to have the knowledge, though!
It's probably easiest to explain how this works with conventional narrowband digital modulation schemes. For a typical modulation scheme, the bandwidth of the modulated signal is proportional to the bitrate. There's also some minimum signal-to-noise ratio below which the receiver can't decode it. By sending more slowly, you get a narrower signal, which means that the receiver can listen to a narrower slice of spectrum. Even though the received signal's no more powerful than before, because the receiver is no longer hearing all the noise outside of that narrower band the SNR improves and it can decode much weaker signals.
LORA appears to use direct-sequence spread spectrum, which basically means that the transmitter applies a spreading code to convert the narrow signal to a very wide one and the receiver uses the same code to despread it again and pick out the signal. Its range improvement is still based on the exact same principle of speaking very slowly to improve your SNR though.
Another way to make a signal go further is to transmit at a lower data rate (thus spreading your signal out over time so that in effect you have more power in the signal). The FCC limits "dwell time" in a single channel to .4s in the 900MHz band.
Yet another way to increase range is to increase your receive sensitivity. Lora's Chirp Spread Spectrum coding actually allows signals to be received below the noise floor. You can liken this to decrypting data: to an observer the signal looks like noise, but if you know how to look within the noise you can pull the actual coded information out.
All of these LPWAN technologies use different forms of coding and signal spreading over time to get long range. Note how spreading your signal over time means your throughput goes down.
The limit is actually 4W ERP (1 watt transmit + 6dB antenna gain) per CFR 15.247: https://www.law.cornell.edu/cfr/text/47/15.247
If you are aware of an exception to this, I would be very interested.
We (Sigfox) are running a hackathon in SF on Nov 20th, in partnership with the City. Good occasion to test the live network, and get your hands on a dev kit
https://www.eventbrite.com/e/smart-city-iot-hackathon-connec...
More info about Sigfox on http://makers.sigfox.com
Those dev kits are pricey... Is this the one? http://snootlab.com/shields-snootlab/829-.html
The Akeru board is still quite expensive (€100), as it's a full Arduino/Genuino board + sigfox module + subscription. And the guy is producing them himself, with small batches. This one is not FCC-ready yet anyway.
Keep in touch for future US-based events !
Anyway, signals are a function of time as well as bandwidth, and with more precise clocks in our devices and higher CPU power to make sense of it, it is an exciting time live and see what's next.
And that was on a very ad-hoc wire antenna.
Every now and then I find a post on HN that really makes my day and I realize how awesome this community is and how our interests overlap beyond computer programming and entrepreneurship. This is one of them.
1. The esp8266 like you have already mentioned. Get one with a u.fl connector and make your own cantenna to attach to it. You can use the microcontroller in the esp8266 to take the sensor readings (it even has an ADC to read analog sensors). This is the new hotness and there are tons of examples.
2. Even cheaper but less user friendly is a very low tech 433 MHz RF transmitter like you can get on eBay. You then need an external microcontroller to run it so you might actually be less cost effective overall and these things take quite a bit of effort to implement a reliable comm system because of the on-off keying system and zero built in error correction. There are libraries like VirtualWire or RadioHead that take quite a bit of pain away. You can get other frequencies if your country doesn't allow unlicensed 433MHz transmissions. Example of what I'm talking about: http://www.ebay.com/itm/like/140719918135?ul_noapp=true&chn=...
There are some downsides though. The sensor+radio combo's are custom orders for now, meaning they take too long to arrive and are too expensive. That issue will get solved over time. They also have an extremely low data rate. A single set of values every 15 minutes. That issue probably won't be solved. Still, you can learn a lot from a CO2 reading or a door opening counter reading even if it's only every 15 minutes.
The hard bit is the intelligent software that processes the data. If anything is the achilles heel of IoT it's that lots of data does not necessarily lead to any insights.
* Star networks are infrastructure heavy, requiring build-outs on part with cellular networks, and having low per-base density.
* LoRa's CSS (Chirp Spread Spectrum) approach doesn't promise to scale well, as devices start to interfere with each other over its very wide spectrum scattershot. There are other problems.
Disclaimer: I work for an IoT mesh company (SSNI/WiSun) and we're busy cranking out massive networks that actually work. Sadly you can't get a dev kit at Fry's yet.
The counterpoint to mesh is that it's a) much more complex to implement b) uses more power since nodes need to relay each others' communications.
It will be interesting to see how it plays out, and who ends up crying in whose martinis as you say.
Which is the catch. Run too many nodes at once, and the signal-to-noise ratio will rise and your signals will start to fail to decode. What this generally means is that nodes at the edge of the network - the ones with the lowest SNR budget - start to drop out first. I'd be interested to see what their link budget and range is with 1600 devices on the same node, or conversely how many devices they can fit on a node at the advertised link budget and range. (Also, just how well they cope with a mixture of near and far nodes.)
Can someone tell me some names of those radio chips? I'm in Shenzhen, if they exist they should be available here. I want to buy some for a few bucks.
You can get cheap (22 USD) Arduino-compatible development boards here using HopeRF modules, which work great with the RadioHead library:
http://www.anarduino.com/miniwireless/ http://www.airspayce.com/mikem/arduino/RadioHead/
(I have no affiliation with the websites.)
You should be able to get some Sigfox-enabled TI CC1120 for a few $ easily.
https://www.kickstarter.com/projects/419277966/the-things-ne...
They seem to have set up an open LoRa network in Amsterdam.
Two way pagers have more or less died out for humans, but for M2M (machine to machine) communication they are alive and well.
However, if you are the adventurous type and don't mind working with unpolished libraries and figuring things out from function descriptions, there are tons of smaller people putting out boards on Tindie: https://www.tindie.com/
Tindie has a few LoRa boards, some with built in antennas and some without: https://www.tindie.com/products/DORJI_COM/long-range-semtech...
But bottom line is that this tech isn't (yet) popular enough to try without getting a little dirty. If you can afford a bigger battery, try 900 MHz Xbee transmitters for an easy to interface serial with long range.
For Sigfox, if you're not in an area with a Sigfox network, there's not much you can do. But TI has some killer FSK dev boards. http://www.ti.com/tool/smartrftrxebk and http://www.ti.com/tool/cc1101cc1190emk915
Ingenu has radio modules and dev boards, but I don't think they're set up to sell single-unit quantity.
If you're in San Francisco, we're making a going to be distributing dev boards that will work out of the box and come with a bunch of sensors. Just sign up on our website: www.beepnetworks.com
https://www.kickstarter.com/projects/419277966/the-things-ne...
Edit: fat thumbs, on mobile.
SX1278 is the string you want to search for on Aliexpress/Alibaba
If you want something a little more enterprisy and turn-key, try the new guys (I work for them). The Patch module has both a BLE and LoRa radio. https://www.filament.com
I attended this bootcamp in Zurich, Switzerland a couple of days ago and it was quite interesting. Swisscom, the biggest Telco here covered Zurich and Geneva already with a lorawan net and they will give access to it during an upcoming hackathon (http://iot-hackathon.swisscom.com/).
Where?
> Think kilobits-per-second, not megabits-per-second.
Well, voice is (or was...) 32kbps, so technically you could make a voice call over these radios, if they can give you 32kbps? I've heard of voice compression as low as 8kbps too. Imagine a cellphone that lasts months :)
http://rdepablos.merlitec.com/mixed/rfm69-library-for-raspbe...
Gets about 1.6 miles with basic wire antenna. More if you play with directional yagis or the like
The problem with LoRa is that yes you can get ten miles, assuming you chose the right antenna and radio, but you wont be able to transmit for very long.
I have a number of sensors that have RFM29 radios in them, and they run off solar and super caps. However they only transmit once a minute, and they don't stay on for a reply.
Power management is key at low power levels. To get ten years battery life, you either need massive batteries, or only transmit once every day/hour.
That means that with an 11Kbps line you are getting about 1,000 characters per second once you factor in other communication over head (stop bits, parity bits, etc). While this may sound fast it is painfully slow for anything other than typing in single line commands and reading single line responses. The transfer of a blank 4KB text file will take three seconds. The transfer of a plain text file the size of a book would take a few minutes.
With the additional overhead of SSH you will actually see the characters appearing on the screen like a lame 80s hacker movie.
These new technologies/products try to solve the problem from both ends. Increasing transmit power to the max allowed. Some early Zigbee chips for instance had transmit powers of 0db, big fail. These new radios transmit 10 to 20 db output power. On the receive side reduce bandwidth to increase the sensitivity by 10-30 db, at the expense of data rate.
The cost of all this is very low bandwidth. Not just in bps, but also packets per minute due to duty cycle regulations. This poses some problems if you want encrypt your packets. Add at least 32-64 bytes overhead. Another problem is as the coverage area gets wider so does the number of interfering radio's.
+ Sometimes you hear comments that spread spectrum allows you operate below the noise floor, but that's only for the spread signal. Once the signal is despread at the receiver, same rules apply.