LoRa Backscatter [pdf](homes.cs.washington.edu) |
LoRa Backscatter [pdf](homes.cs.washington.edu) |
Is CSS better than FSK than in this respect or..?
Edit: http://www.akermann.bg/files/Semnrs/H2016/Module3.4_100km%20...
Says
"Spreading codes does not improve sensitivity over FSK systems, for usable datarates you get similar sensitivity using standard FSK modulation"
From years of experience selling, supporting, and installing 900MHz ISM radios, I can tell you this is not the case in many, many places (it describes a greenfield application more or less correctly, though). 900MHz is heavily used in the US and describing the noise as "background" or "random" is disingenuous at best. I'd like to see someone install a LoRa hub on a tower with several other 900MHz radios (common) and see how well it works.
This is some impressive work.
- Decoding LoRa: Realizing a Modern LPWAN with SDR [1]
- Presentation on this work from GRCon16 [2]
- Slides from the above presentation [3]
[1] https://pubs.gnuradio.org/index.php/grcon/article/download/8...
[2] https://www.youtube.com/watch?v=-YNMRZC6v1s
[3] https://static1.squarespace.com/static/54cecce7e4b054df1848b...
http://www.ambuj.se/LoRea-CR.pdf
LoRa while achieves impressive sensitivity levels, this is for very low bitrates of tens of bps. For any practical data rate the sensitivity levels are similar to FSK.
Best I was able to find was "An Investigation of Fading on a Short Range 900MHz radio link":
https://mentor.ieee.org/802.11/dcn/10/11-10-1355-00-00ah-fad...
I don't doubt it can be done, but can their "twenty-cent" chip handle it without messing up its lightweight low-power nature?
The bigger issue is that the entire point of this system is to remove cost of deployment and maintenance for cheap highly distributed lo-fi systems. The cost of keying all those devices for encryption would defeat the purpose. Also the added data overhead of the encryption would possibly exceed the amount of actual data you are trying to get out of the system. Also, why do you even want to encrypt it in the first place?
I want to encrypt and authenticate any and all wireless gadget data because I've been paying attention to the last 5 years of defcon talks.
$ pdffonts loRaBackscatter.pdf
name type emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
OZJJTN+LinBiolinumTB Type 1 yes yes yes 116 0
LWEMPN+LinBiolinumT Type 1 yes yes yes 118 0
LWEMPN+LinBiolinumT Type 1 yes yes yes 119 0
LILBVD+LinLibertineT Type 1 yes yes yes 120 0
LILBVD+LinLibertineT Type 1 yes yes yes 121 0
...—Tanenbaum, Andrew S. (1989).
> Games on Disc More Energy Efficient than Downloads
http://www.notechmagazine.com/2014/09/games-on-disc-more-ene...
And if you really want to dive into the complications of this topic from a broader perspective of energy use, this piece is full of thought-provoking questions, even if you don't necessarily agree with the conclusions:
http://www.lowtechmagazine.com/2015/10/can-the-internet-run-...
> animats: Wow. Both the receiving and transmitting antennas were omnidirectional
> vvanders: I regularly see APRS packets of 120mi+, although probably at a lot more power.
> superkuh: I run two ubiquiti nanostation M900 at home on a 10m pole and in my car through the sunroof for a mobile data link.
> aw3c2: From a balloon in almost 40km altitude.
The Chrome plugin I'm using (Quick Javascript Switcher) disables on a per-domain basis and remembers the setting for each.
I'm a huge fan of SPAs and JS in the browser and yet I'm quickly blocking JS out of large swaths of the internet simply because it improves the browsing experience. I'm not quite sure what this lesson is teaching me.
Ha! I thought you were going to propose a visible-spectrum variant of this tech.
Tech like this already exists (look up "UHF RFID") and the picture they've got looks very similar to existing tags (image search for "alien rfid tag").
The interesting thing here is managing to implement LoRa's modulation scheme in a passive tag.
One-time keying may not be as expensive as you think, a simple matter of IC fuses, but you're right that key management and "enrolment" generally for these tiny things will be a pain.
All that said, it's not a fundamentally bad idea. Pseudo-random xor encoding of signals is a technique used all the time to increase orthoganality between signals for a variety of encoding schemes.
Fuse based programming would have a whole host of issues. You either need a destructive fill device or load at the factory. If you load at the factory you have to trust them to not retain copies, keeping in mind that it will probably me manufactured in China. If you use a fill device you open up for destructive programming (IC fuses) you open up a bunch of liability for accidental damage to the device plus the cost of a technician plus training can quickly swamp out the cost of your low cost sensor network.
Finally, these sorts of networks work best with asynchronous uni-diretional communication applications. This makes good crypto-practices very difficult. If you chose full crypto and handshake protocols, the amount of data you spend just exchanging keys and handshakes will exceed the data the sensors collect.
Yes, thanks for the response!