Hacker News new | comments | show | ask | jobs | submit login
LoRa Backscatter [pdf] (washington.edu)
135 points by feelthepain 9 months ago | hide | past | web | favorite | 39 comments

It says regarding CSS "That makes even faint LoRa signals easy to distinguish from background noise, which fluctuates randomly".

Is CSS better than FSK than in this respect or..?

Edit: http://www.akermann.bg/files/Semnrs/H2016/Module3.4_100km%20...


"Spreading codes does not improve sensitivity over FSK systems, for usable datarates you get similar sensitivity using standard FSK modulation"

>background noise, which fluctuates randomly

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.

That's very interesting cheers. Just to clarify that quote was from the article this post originally linked to, rather than the paper it now links to.

CSS is an analog (continuous frequency function) modulation where the CSS standard specifies that only linear encoding be used while FSK is a digital modulation that can employ pseudo-random keying and operates at discrete frequency keys. Without these restriction imposed by standards, FSK would be a special case of CSS, at least mathematically.

"So, we reverse-engineer the LoRa physical layer using the patents filed by Semtech [27, 57], which is the key LoRa chipset manufacturer. We also use the Semtech 1276 starter kit [10] that provides an interface to transmit LoRa packets with various bitrates and an arbitrary payload. Finally, we analyze the transmissions from the LoRa chipsets on a USRP."

This is some impressive work.

There has been some prior work on this:

- 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...

This paper to be presented in ACM SenSys in November actually demonstrates ability to backscatter to distances as high as 3.4 kilometers at 70 microwatts using narrow band FSK transmissions.


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.

Anyone know of any notable related research on real world use of this tech?

Best I was able to find was "An Investigation of Fading on a Short Range 900MHz radio link":


You might have more luck looking at Active RFID. The same technology in any meaningful sense.

I worry about encryption of sensitive data.

I don't doubt it can be done, but can their "twenty-cent" chip handle it without messing up its lightweight low-power nature?

Modern microcontrollers can be had in the sub-$5 range that support hardware implemented encrypting algorithms. Mostly it's a worthless feature but we aren't far out from it being more or less standard even in the $0.20 guys.

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?

> 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.

HN ate my reply, apparently I was posting too fast, but as a TLDR you can avoid the overhead of encryption and authentication by revisiting the trust framework in the design of your network and simply assuming that you don't trust your sensors. This moves the overhead from the sensors and the network which are heavily constrained to the processing of the central authority where you have a lot more lee-way and moore's law to help. If you are interested in learning more about this sort of system, it is a topic of research in control theory often lumped under robust systems.

I.e. you want to make the world less fun for the type of people who present the DEFCON talks. :(.

The Economist article for the same subject suggested using this in medical devices.

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.

Medical is just an example of the economist not understanding the product vs the buzzline. It is a terrible tech implementation for medical, but I agree that you generally want medical encrypted. However, if you are talking medical, the cost of the sensor device is tiny compared to other costs even for very expensive sensors.

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.

Since backscatter systems depend on on an RF source, I wonder if work has been done on encrypting the source signal (pseudorandom bit pattern for example), then modulating the random stream at the device and decoding the backscattered signal at the receiver - essentially a streaming XOR cypher.

In this system the RF source you are sending is effectively the IF component for the sensor's Tx chain. Because it is so high power and such a clean pilot tone, the sensor can eliminate it's IF generating oscillator and output amplifier by just mixing the data onto the receive pilot tone and retransmitting it. This is how the sensor is made so cheap and low power. If the pilot tone was cyphered, it wouldn't mean the data was. That is, you could recover the unencrypted data if you recorded a copy of the pilot by mixing. There is also the issue that, because the pilot tone provides the power to the sensor's carrier, any spreading of it's spectrum, which is what random xor encoding does, makes it harder to recover and use as the IF component for the sensor's radio chain. The last issue here is that the CSS standard does not allow this sort of non-linear modulation.

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.

>>> That is, you could recover the unencrypted data if you recorded a copy of the pilot by mixing.

Yes, thanks for the response!

It would be nicer if it were not proprietary.

Which font is used in the document?

Linux Libertine: https://en.wikipedia.org/wiki/Linux_Libertine

  $ 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

"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."

—Tanenbaum, Andrew S. (1989).

A more up-to-date take on this:

> Games on Disc More Energy Efficient than Downloads


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:


Yeah but latency sucks.

LoRaWAN packet received at record distance of 702 km | https://news.ycombinator.com/item?id=15201692 | (5 days ago, 178 points, 50 comments)

> 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.

This website is so brokenly slow. The initial load does 184 xhr-requests mostly in series, oh my god where does this end?

They're just cleverly preparing you for the experience of the first website served over LoRa.

Got a mirror? Website imposes a article viewing limit...

Disable Javascript for that site and it reads normally. I've found that most news sites become much more readable (and chew through far less of my CPU, and stop autoplaying loud videos, and skip paywalls) with JS disabled.

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.

YesScript worked for me on Firefox. Thanks for the idea. https://addons.mozilla.org/en-US/firefox/addon/yesscript/dev...

Just a note that YesScript isn't compatible with my Firefox Nightly now (due to the move to WebExtensions) and will probably stop working with Firefox in general in the future.

"Got a mirror?"

Ha! I thought you were going to propose a visible-spectrum variant of this tech.

Open in incognito

Here's the paper: https://homes.cs.washington.edu/~gshyam/Papers/loRaBackscatt...

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.

It's not a passive tag. If you only read 3 sentences into the abstract, you find out that it is an active device. This is repeated at the end of the abstract and right at the beginning of page 2 in the introduction.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact