10 ms·
This is un. fucking. real. I work in the IoT space (specifically on health devices), and something like this would be absolutely a GOD SEND for the things that
by blhack 11y ago
This is un. fucking. real. I work in the IoT space (specifically on health devices), and something like this would be absolutely a GOD SEND for the things that we're doing.
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/ 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 https://media.giphy.com/media/rl0FOxdz7CcxO/giphy.gif
- jazzyk 11y agoCool stuff, sure. But, in my opinion, IoT will be slow to take off until the security aspect is solved - and it is a tough one.
- dconrad 11y agoSecurity in the LoRaWAN standard is well thought-through, you might be surprised.
- StavrosK 11y agoThat's exactly my problem too, and I decided to develop a prototype protocol for it. I wrote a reference implementation in python, feedback very much desired: http://stringphone.readthedocs.org/ http://stringphone.readthedocs.org/
- bdamm 11y ago* The weaknesses you outline in the introduction are pretty serious. * 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.
- StavrosK 11y ago> The weaknesses you outline in the introduction are pretty serious. 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#discovery 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...
- CamperBob2 11y agoI can't think of any other technologies that have waited for the security aspect to be solved, can you?
- TeMPOraL 11y agoSolving security aspect will mean much less hackability, which means slowing down its development.
- Natanael_L 11y agoLink encryption and authentication is pretty much "solved" in that we have the components we need already. Then there's the issue of code bugs and lack of updates - I think this should be solved in most cases by devices exclusively talking over a filtered API via a trusted gateway to prevent exploit attempts from succeeding.
- dconrad 11y agoGlad you agree. :) 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.)
- blhack 11y agoWhat tech are you using for the base station? 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.
- dconrad 11y agoKiller -- where's your hackerspace? 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.
- blhack 11y agoMesa, AZ. http://www.heatsynclabs.org/ http://www.heatsynclabs.org/
- dconrad 11y agonice, hit me up, daniel@
- imrehg 11y agoHey, is there any chance for us putting something like this to the Taipei Hackerspace (Taiwan)? https://taipeihack.org https://taipeihack.org 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 https://hackpad.com/LoRa-USB-Communication-Stick-xKGgChuwbzL )
- 11y ago
- bravo22 11y agoCompromise is you'll get a few bits to 1kbps at best over a few Km of range. It would work for some applications but not for all of them.
- blhack 11y agoThis is all that IoT needs, though. It's not about streaming video or music or something, it's about a sensor that goes high when somebody is sitting in a chair, or that sends an integer value once every few minutes.
- vegabook 11y agoIs bandwidth realistically at least in the high hundreds/low thousands of bps? Or are we literally talking a couple of bytes per minute?
- bravo22 11y ago... so why not do it over WiFi? You use less power/bit and you get the data delivered to where it matters, local network. LoRa only makes sense (and I've seen it used) in large infrastructure type uses like sensors that monitor roads or bridges.
- ac29 11y agoI think you answered your own question -- of course WiFi makes sense for small/short range networks. Its cheap and fast. 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.
- ju-st 11y agoIs that 1kbps shared between all devices in range?
- 0898 11y agoJust curious – why is range limited by a protocol? Why couldn't you send Bluetooth over hundreds of miles with a big enough antenna, for example?
- blhack 11y agoNot limited by the protocol per se, but limited by the design requirements of BLE. 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!
- makomk 11y agoThey're achieving those ranges by being very, very slow. 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.
- slewis 11y agoYou can amplify a signal and send it far. But due to FCC regulation in the 900MHz band for example you can only instantaneously transmit at 30W. 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.
- nicolsc 11y agoIf you're skeptical about LPWAN range claims .. better thing to do is to test :) 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-connect-your-city-tickets-19092263474 https://www.eventbrite.com/e/smart-city-iot-hackathon-connec... More info about Sigfox on http://makers.sigfox.com http://makers.sigfox.com
- blhack 11y agoOh man... Unfortunately I'm going to be out of the country during that or I would be ALL OVER IT. Those dev kits are pricey... Is this the one? http://snootlab.com/shields-snootlab/829-.html http://snootlab.com/shields-snootlab/829-.html
- nicolsc 11y agoIn the SF event we'll hand out TI dev kits, Launchpad + CC1120 boosterpack (~ http://www.ti.com/tool/boostxl-cc1120-90 http://www.ti.com/tool/boostxl-cc1120-90) 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 !