Application of this project to the TTN (The-Things-Network)?

[bertrik]

Has anyone tried to decode signals from a LoRaWAN network, like the TTN, with this plugin? LoRaWAN (with a few exceptions) uses the 125 kHz bandwidth, coding rate 5/6, explicit header, CRC on, SF varying from 7-12, as described in this application note: http://www.semtech.com/images/datasheet/an1200.23.pdf

It would be awesome if you could use an rtl-sdr for receiving data on all 8 channels from TTN simultaneously, and send data using an RFM9x chip for example. This would make it a very inexpensive hacky alternative to a ready-made gateway which are usually > E250,-

Perhaps I can supply some reference recordings from TTN signals at various settings.

[rpp0]

Hi Bertrik, that's a cool idea! I only tested the project with a lora node close to the receiver, but it should work. However, I expect that a few packets will not be detected (the gr-lora sync algorithm should be improved to solve this) and that receiving on all channels simultaneously would require some tweaking and perhaps multiple RTL-SDRs. I'm currently working on this in my spare time. It would indeed be nice if you could supply a reference recording so we can test this.

[forrestfiller]

@bertrik I am very interested in working with a Rx SDR to forward packets up to TTN for building and testing nodes. I actually have been looking to put together a single channel Rx to send my test packets from various RF95W nodes (Adafruit M0 feather, mDots) to my application on the TTN backend. I have been starting to work a little bit with ESP8266/rPi/Arduino, however it seems like it would be very nice to do it in software with my existing SDR, utilizing gnuradio-companion + gr-lora. Thanks to you and @rpp0 both for your efforts!

[bertrik]

If you look at the semtech typical design of a gateway, you'll see two chips (sx1257) each producing an IQ stream and a single chip doing the decoding. Also, looking at the config of a multitech gateway, it becomes evident that internally it has two mixers. I think the absolute minimum a TTN gateway has to support is frequencies 868.1, 868.3 and 868.5, this would even fit in the bandwidth of a single rtl-sdr. LoRa as a modulation method should not be super-sensitive to a frequency error (as is typically the case for inexpensive rtl-sdrs).

I have a problem however trying out your code, I get the following:

bertrik@zenbook:~/code/gr-lora$ apps/lora_receive_file.py 00_crcon_cr1_sf7.cfile Using Volk machine: sse4_2_64_orc Bits per symbol: 35 Bins per symbol: 128 Header bins per symbol: 32 Samples per symbol: 1024 Decimation: 8 Traceback (most recent call last): File "apps/lora_receive_file.py", line 189, in main() File "apps/lora_receive_file.py", line 183, in main tb = top_block_cls() File "apps/lora_receive_file.py", line 72, in init self.lora_lora_receiver_0 = lora.lora_receiver(samp_rate, capture_freq, offset, 7, 1000000) File "/usr/local/lib/python2.7/dist-packages/lora/lora_receiver.py", line 70, in init self.msg_connect((self.c_decoder, 'debug'), (self, 'debug')) TypeError: msg_connect() takes exactly 5 arguments (3 given)

[rpp0]

Hi,

You're right, 868.1 - 868.5 MHz should be no problem for one RTL-SDR.

As for the error you get: msg_connect is an internal gnuradio function, and it seems you're using an old version as it does not unpack the tuple arguments. You can try to remove the parentheses or upgrade gnuradio to the latest version, but I'll check it more in detail tomorrow; I'm not at home today :).

Thanks for discussing this and for your involvement!

[rpp0]

Okay, I just checked. You need at least GNU Radio version 3.7.9. See this other project for more information: https://github.com/ptrkrysik/gr-gsm/issues/187

Note that upgrading might break compatibility with other GNU Radio projects you may have installed if they still use the old msg_connect convention. Perhaps I could create a Docker container for gr-lora so that it's easier to setup.

[bertrik]

I upgraded my system to debian unstable (which has gnuradio-dev 3.7.10 if I remember correctly) and things are compiling and running now. I still need to make the recordings. How did you make the recordings in https://github.com/rpp0/gr-lora-samples ?

[rpp0]

The samples from gr-lora-samples were recorded at 10 Msps using a HackRF One, with capture frequency 866 MHz, and RN2483 LoRa signals transmitted at 868.1 MHz (offset +2.1 MHz). However, nowadays I do most of my tests with 2 Msps captures using either the USRP, HackRF, or RTL-SDR and they work fine as well.

[forrestfiller]

@rpp0 @bertrik have you looked at this gnu radio block? by @ptrkrysik. I wonder if one could put several (or eight) rtl-sdrs/ together to eventually make a low cost SDR gateway, maybe throw in one that can TX like hackrf. He has a nice post here about his experiment. I figured you'd seen it, but it was new to me and looks neat.

[rpp0]

@forrestfiller Sorry for the late reply, yes I've seen it and it's indeed a very cool block :)! I think it can be done with only a few SDRs: i.e. similar to GSM, one RTL-SDR can decode multiple channels. The question is whether the host can keep up with the flow of samples; gr-lora is still quite slow and I didn't have the time yet to improve it.

[rpp0]

As an update to the original issue: in the current state the decoder can decode multiple channels simultaneously through the use of "gradient" decoding. This method is more sensitive to noise and thus requires a relatively high SNR / clean signal, but it allows for decoding multiple channels without retuning. You can enable the feature by selecting "Disable Channelization > Yes" in the "LoRa Receiver" block options.