rpp0 / gr-lora

GNU Radio blocks for receiving LoRa modulated radio messages using SDR

gr-lora

The gr-lora project aims to provide a collection of GNU Radio blocks for receiving LoRa modulated radio messages using a Software Defined Radio (SDR). More information about LoRa itself can be found on the website of the LoRa Alliance.

Features

All features of the LoRa physical-layer modulation scheme are described in various patents and blog posts (for a good resource, see this RevSpace page). gr-lora supports most of these features, except for:

• CRC checks of the payload and header
• Decoding multiple channels simultaneously

This library was primarily tested with a USRP B201 as receiver and Microchip RN2483 as transmitter. If you encounter an issue with your particular setup, feel free to let me know in the 'Issues' section of this repository.

Update of 29th August, 2017

I'm happy to announce that as of gr-lora version 0.6, a new clock recovery algorithm has been implemented which fixes previous issues with long LoRa messages. Other components, such as whitening, detection and decoding have been improved as well (see the Git log for more details). Given a clear signal, the decoding accuracy is now close to 100% for all SFs, and I therefore consider LoRa fully reverse engineered. Future updates will focus on improving the performance and minor details of the specification.

Attribution

If you are working on a research topic or project that involves the usage of gr-lora or its algorithms, we would appreciate it if you could acknowledge us. We are currently working on a full writeup of the decoder, but in the meantime, you can cite this repository as follows:

Pieter Robyns, Peter Quax, Wim Lamotte, William Thenaers. (2017). gr-lora: An efficient LoRa decoder for GNU Radio. Zenodo. 10.5281/zenodo.853201

Installation

Installing gr-lora is possible in two ways: either by downloading the Docker container, which contains all dependencies and gr-lora packaged in a single container, or by manual installation.

Docker installation

To avoid installation errors and cluttering your system with the required dependencies, the best approach to install gr-lora is through a Docker container. Make sure the docker service is running, then perform the following steps:

git clone https://github.com/rpp0/gr-lora.git .
cd docker/
./docker_run_grlora.sh

The docker_run_grlora.sh script will download the Docker container and run it in 'privileged' mode (in order to access your SDR over USB). After that, you should get a shell inside the container:

[root@5773ed19d95d apps]#

See the 'Testing' section below for examples on how to use gr-lora.

Manual installation

If you prefer a manual installation, the following dependencies are required: python2-numpy, python2-scipy, swig, cppunit, fftw, gnuradio, libvolk, log4cpp, cmake, wx, and liquid-dsp.

The installation procedure is the same as for any GNU Radio OOT module:

git clone https://github.com/rpp0/gr-lora.git .
mkdir build
cd build
cmake ../  # Note to Arch Linux users: add "-DCMAKE_INSTALL_PREFIX=/usr"
make && sudo make install

Testing and usage

To test your installation, you can simply run the example app apps/lora_receive_file_nogui.py. The script will download an example trace, and attempt to decode it using gr-lora. You should see the following output:

$ ./lora_receive_file_nogui.py
[?] Download test LoRa signal to decode? [y/N] y
[+] Downloading https://research.edm.uhasselt.be/probyns/lora/usrp-868.1-sf7-cr4-bw125-crc-0.sigmf-data -> ./example-trace.sigmf-data . . . . . . . . . . . . . . . . . .
[+] Downloading https://research.edm.uhasselt.be/probyns/lora/usrp-868.1-sf7-cr4-bw125-crc-0.sigmf-meta -> ./example-trace.sigmf-meta . .
[+] Configuration: 868.1 MHz, SF 7, CR 4/8, BW 125 kHz, prlen 8, crc on, implicit off
[+] Decoding. You should see a header, followed by 'deadbeef' and a CRC 5 times.
Bits (nominal) per symbol: 	3.5
Bins per symbol: 	128
Samples per symbol: 	1024
Decimation: 		8
 04 90 40 de ad be ef 70 0d
 04 90 40 de ad be ef 70 0d
 04 90 40 de ad be ef 70 0d
 04 90 40 de ad be ef 70 0d
 04 90 40 de ad be ef 70 0d
[+] Done

Other example traces can be found in the gr-lora-samples repository.

If you have a hardware LoRa transmitter, you use apps/lora_receive_realtime.py to decode signals in real time. With a Microchip RN2483, you can use python-loranode to easily send messages via Python.

By default, decoded messages will be printed to the console output. However, you can use a message_socket_sink to forward messages to port 40868 over UDP. See the tutorial for more information.

Contributing

Contributions to the project are very much appreciated! If you have an idea for improvement or noticed a bug, feel free to submit an issue. If you're up for the challenge and would like to introduce a feature yourself, we kindly invite you to submit a pull request.

Hardware support

The following LoRa modules and SDRs were tested and work with gr-lora:

Transmitters: Pycom LoPy, Dragino LoRa Raspberry Pi HAT, Adafruit Feather 32u4, Microchip RN 2483 (custom board), SX1276(Custom Board with STM32 Support) Receivers: HackRF One, USRP B201, RTL-SDR, LimeSDR(LMS7002M)-LimeSDR USB.

Changelog

• Version 0.7 : Added support for downlink signals, reduced rate mode when using implicit header and arbitrary bandwidths (experimental).
• Version 0.6.2: Improved Message Socket Sink and higher sensitivity to low-power signals.
• Version 0.6.1: Minor bug fixes and improvements.
• Version 0.6 : Significantly increased decoding accuracy and clock drift correction.
• Version 0.5 : Major overhaul of preamble detection and upchirp syncing
• Version 0.4 : Support for all spreading factors, though SFs 11 and 12 are still slow / experimental
• Version 0.3 : Support for all coding rates
• Version 0.2.1: Fixed some issues reported by reletreby
• Version 0.2 : C++ realtime decoder, manual finetuning for correcting frequency offsets of the transmitter.
• Version 0.1 : Python prototype file based decoder, SF7, CR4/8

License

See the LICENSE file and top of the source files for the license of this project.

gr-lora's Issues

LoRa signals not decoded correctly

Hi,
I am sending 1 LoRa packet (1,2, or 3 bytes long) every second at 915 MHz (125 kHz bw) from a SX1272 LoRa end-node using the program https://os.mbed.com/users/dudmuck/code/sx127x_simple_TX_shield/. Using another SX1272 end-node as a receiver, I am able to receive and decode the message just fine. However, with my USRP B210 device using gr-lora as a receiver, I am not getting the correctly decoded payload. The payload being printed is incorrect and has incorrect number of bytes. I have tried various SF, and code rates, but it still doesn't work.

Only under 1 specific scenario, I see the packet payload being printed out partially correctly, but only after 7 incorrectly decoded packets.
This is the partially working configuration in gr-lora: code rate: 4/8, SF 7, BW 125kHz, freq: 915MHz, internal sampling rate (1Msps), implicit header, and CRC (True). I am using 3 bytes payload (AA,CC,88).

After sending 18 packets (in 18 seconds), only 3 packets were partially correct as shown below. one packet gets decoded after 7 incorrectly decoded packets.
ff 88 f2
aa cc 88 fd c1 e2 c3
6d 5f d7 da e1 61 42
73 a3 65 f1 f9 e4 46
9b be 30 b6 d0 c1 ce
fd 92 8a f2 7d 08 62
0f cd 27 31 b4 66 df
f8 2f 32 58 4a 85 2a
ff 88 f2
aa cc 88 fd c1 e2 c3
6d 5f d7 da e1 61 42
73 a3 65 f1 f9 e4 46
9b be 30 b6 d0 c1 ce
fd 92 8a f2 7d 08 62
0f cd 27 31 b4 66 df
f8 2f 32 58 4a 85 2a
ff 88 f2
aa cc 88 fd c1 e2 c3

I tried every possible configuration combination but only this seemed to work partially. At sender, I am using coding rate: 0 (I have tried 1-8 but they don't work). More than 3 bytes long payload, even this configuration doesn't work. Please let me know what am I missing. Thanks for your help.

Forgotten command for manual installation

git clone https://github.com/rpp0/gr-lora.git .
cd gr-lora
mkdir build
cd build
cmake ../ # Note to Arch Linux users: add "-DCMAKE_INSTALL_PREFIX=/usr"
make && sudo make install

WARNINGs of ./lora_receive_file.py

I had warnings as follow during the test of GRC.
What should I do for this?
I used 0000_crcoff_cr4_sf7.cfile for testing

Executing: /usr/bin/python2 -u /home/tomoaki/tmp/work/gr-lora/apps/lora_receive_file.py

Bits per symbol: 	35
Bins per symbol: 	128
Header bins per symbol: 32
Samples per symbol: 	1024
Decimation: 		8

(lora_receive_file.py:14329): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17

(lora_receive_file.py:14329): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17

(lora_receive_file.py:14329): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17

(lora_receive_file.py:14329): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17
 10 00 02 00
 10 00 02 00
 10 00 02 00
 10 00 02 00
 10 00 02 00

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

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.

Reception not working with SF > 9 and BW > 125 KHz

I'm doing some experiments using gr-lora on a USRP B210 and a Libelium Waspmote with SX1272 chip as a transmitter. Actually i can decode correctly (still loosing some packets as the receiver lost the synchronization with the preamble) the packets sent by the transmitter with the following parameters: Sampling Rate = 1 Msps; SF = 7, 8, 9; BW = 125 KHz; CR = 4/5, 4/6, 4/7, 4/8.
With SF = 10 the receiver recognize the preamble sometimes but never decode the packet correctly.
When i try with bandwidth 250 or 500 KHz (changing the BW hard-coded value and rebuilding), the receiver never synchronize with the preamble.
Is this behaviour a bug or an issue related to the processing of the samples?

Lora PHY

Hi @rpp0,

During the demodulation performed by gr-lora, each time I can see 3 bytes just before the LoRa Mac Layer.
In my case, you can see the LoRaTap header and the data

LoRaTap header
    Header Version: 0
    Padding: 00
    Header Length: 0
    Channel
    RSSI
    Sync Word: Unknown (0x00)
Data (21 bytes)
    Data: 1221f0608ca0f40c28e0b0006ba6b1cc9406933e8c
    [Length: 21]

In the data, the 3 bytes related to LoRa PHY are : 12 21 f0
60 8c a0 f4 0c 28 e0 b0 00 6b a6 b1 cc 94 06 93 3e 8c is the LoRaMac

Most of the time I'm getting only two possible values : 1221f0 or 0d2070
Did you have any idea about the meaning of these values ? Is it something we should map into the LoRaTap header ?

Problem with make in "void decoder_impl::samples_to_file" in "decoder_impl.cc"

You have to use this line
out_file.open(path.c_str(), std::ios::out | std::ios::binary);
instead of that line
out_file.open(path, std::ios::out | std::ios::binary);
for the make to proceed correctly.

Compile error

We tried to compile, but the compiler gives an incompatible function error. With this change in the code we could compile.

--- a/lib/message_file_sink_impl.cc
+++ b/lib/message_file_sink_impl.cc
@@ -701,7 +701,7 @@ namespace gr {
message_port_register_in(pmt::mp("in"));
set_msg_handler(pmt::mp("in"), boost::bind(&message_file_sink_impl::msg_handler, this, _1));

•    d_file.open(path, std::ios::out | std::ios::binary);
  

•    d_file.open(path.c_str(), std::ios::out | std::ios::binary);
  

  }

  /*

Problem with lora_receive_realtime flow

Hi,

Where can I see the decoded data while running the gnuradio flow lora_receive_realtime? I see no output in gnuradio or the terminal. There is just a real-time fft window.

I am actually conducting a real experiment with Semtech LoRa modules and I expect lora_receive_realtime to decode LoRa signals in realtime.

Thanks,
Rashad

Error Decoder

I have just finished installing the gr-lora without problems, however when executing examples on GNU-Radio I get the following error:

self.c_decoder = lora.decoder(out_samp_rate, sf)

AttributeError: 'module' object has no attribute 'decode

Any idea?

Required Dependency: liquid-dsp

The user should install liquid-dsp before installing gr-lora
https://github.com/jgaeddert/liquid-dsp

Failed to connect to analyzer.

Hi,
Trying this out to see if I can decode raw LORA test messages sent by my new LoPy device. When I run the lora_receive_realtime.grc flowgraph, I see "Failed to connect to analyzer." in the console output. Any idea why this might be?
This with latest code (as of yesterday) built freshly with pybombs.

High packet error rate, same error vector almost every time

Last night I was investigating a high packet error rate in the traffic received by lora_receive_realtime.
I had been observing a PER of 30% with code prior to v0.6.2, and had been seeing a very predictable/repeatable error vector occurring in corrupted packets. After updating to v0.6.2 I am still seeing the same thing

The traffic I am monitoring is beacon traffic between my pair of LoPys. The traffic is sent using sockets configured like so

        self.lora = LoRa(mode=LoRa.LORA, tx_power = config.tx_dbm,
                         bandwidth=LoRa.BW_125KHZ,
                         sf = 8, preamble=12, coding_rate=LoRa.CODING_4_7,
                         frequency=config.lora_freq)
        self.lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

This is in the 868MHz band. TX Power is 2dBm. Peak Rx signal is -30dBFS on HackRF One, using a loft-mounted discone antenna and 20dB mast-head preamp. Both LoPys are in the house below the discone antenna. There is about 6-10dB difference in signal strength of the two LoPys, as seen by lora_receive_realtime. The noise floor is about 35dB below the peaks of the weaker LoPy. The channel is reasonably clear and I would expect a very low PER. In fact the pair of LoPys very, very rarely report reception of corrupted traffic. To summarise, the channel is not challenged.

FYI, I've started to use the "WX fosphor sync" in lora_receive_realtime, it really is nice for a good visualisation of the LoRa waveform. Checkout the keybd shortcuts in the docs pane of the properties dialog.

The traffic is normally HMAC-MD5 + IV + CIPHERTEXT, but for experimental purposes I have switched to HMAC-MD5 + b'\x00'*(16+31). In my code that listens to the output of the message socket sync in lora_receive_realtime, when the HMAC fails, I XOR the known message payload with the received message payload (i.e. everything but the first 3and last 2 bytes) and print the error vector. It is almost always the same (the highly rare exceptions being attributed to transient channel state changes).

Here is a snippet of what my code reports:

2017-09-15 14:27:21.005451*** TEST VECTOR *** (*** AUTHENTICATED ***)
2017-09-15 14:27:29.132665 - Rx: HMAC failed! len: 66
*** ERROR PATTERN REPEAT *** 2563
Error vector: b'000000000000000000000000000000000000000000808000000000000000000000000000000000000000000000000000000000000000000000000000000000'
Error vector match rate: 84.83945713339953%
Packet Loss Rate:0.2986358244365362

This shows one test message being received and passing HMAC checks. The next packet fails HMAC verification. It has the expected payload length (I ignore the length in the first byte of the 3 byte preamble, and now also the 2 byte CRC suffix). The code then claims that the calculated error vector is the same as the previous 2563 error vectors. The error vector match rate really should show 99.99% as there had only been one error vector that did not match this pattern and that reset a counter used in my naff stats calculation.

Anyway, at byte 22 in the error vector, the 9 bit long error burst 0b100000001 (0x808) occurs. There may be errors in the 3 byte preamble (and now the 2 byte CRC that I'm not seeing).

I'm not sure if there is anything else I can add, other than perhaps recording some baseband for you to try and reproduce this.

I have no idea if this might be related, but Murphys law probably means that the same thing will probably go wrong in all of the gnuradio software that I use ;P
http://destevez.net/2017/07/degradation-bug-in-gnu-radio-decode-ccsds-27/

Thanks for your work on this, BTW.

P.S. I put my HackRF One inside a metal chassis in case there was anything funny going on with with the LoRa gadgets being closer in proximity to the HackRF than it's antenna system. That hasn't made any difference to the PER, but has quietened the spectrum a bit :)

Message File Sink buffered?

Having issues with frames not being written to disk. Quite randomly the frame is written when the project is killed in GNURadio. Is this a known issue?

Remove .log files from repository

The performance test .log files are useful for development, but should not be versioned. It would be interesting though to have a page on the wiki or section in the README.md file where the last accuracy results per device are listed. @Wosser1sProductions

AttributeError: 'module' object has no attribute 'decode`

Hello I tried To use You block in GCR but I have this error:

Traceback (most recent call last): File "/home/**/top_block.py", line 110, in <module> main() File "/home/**/top_block.py", line 104, in main tb = top_block_cls() File "/home/k/top_block.py", line 79, in __init__ self.lora_lora_receiver_0 = lora.lora_receiver(samp_rate, freq, 1, 7, 1000000) File "/usr/local/lib/python2.7/dist-packages/lora/lora_receiver.py", line 50, in __init__ self.c_decoder = lora.decoder(out_samp_rate, sf) AttributeError: 'module' object has no attribute 'decode

All dependencies are installed, cmake with swig as mentioned #13 .

Below is output of my sys.path

['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/k/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/python2.7/dist-packages/ubuntu-sso-client', '/usr/lib/python2.7/dist-packages/wx-3.0-gtk2']

Some enquiries on the LoRa encoder and decoder process

Hi mate,

I am so glad to see this gr-lora performing very well in some parameters settings. However, I found that in your code you have used deinterleave module in the demodulating stage, and then perform deshuffle, dewhitening, and hamming decoding. This is different from what I am understanding about LoRa.

1, Is the deshuffle process equivalent to de-gray?
2,I suppose the decoding process should be demod, de-gray(deshuffle?),dewhitening,deinterleaved and hamming decoding.

Could you please explain a bit more on this part and give me some advice? I want to reproduce the encoder for performance evaluation in more practical scenarios with our own design MAC layers, in which the performance limit of the LoRa must be investigated. For simulation, it would be easier to deploy a large number of LoRa end-devices.

Regards

Alex

Basic Instructions

Hi,

Sorry to bother, but would it be possible if there was a basic instruction guide to getting this working, not coming from an RF background it all seems rather complicated :)

We are using LORA to talk to units whilst flying paragliders and looking to read the packets via RTL-SDR devices, is this something we could possibly do with this software ?

Thanks

Phil.

Support all coding rates

4/8 coding is fully supported. Support should be added for 4/7, 4/6, and 4/5 coding.

AttributeError: 'module' object has no attribute 'lora_receiver'

It was working all good and then suddenly I got this error.

Scope for optimization

Not really an issue so much as wanting to reach out and maybe get involved if possible.

Long story short I'm trying to put together a package to build a LoRaWAN gateway using cheaper parts than the Semtech gateway chips. I'm aiming for a system using a cheap ARM board using an RTL SDR for receiving and a SX1276 module for transmitting.

Currently a common quad core 1.2ghz Cortex A7 board (OrangePi Zero) seems to be totally overwhelmed trying to decode a single channel and single spreading factor. A 2ghz quad A7 + quad A15 board (Odroid XU4) seems to just about be able to keep up.

For LoRaWAN I think at least 2 channels and multiple spreading factors need to decoded in realtime.
Is this in the realm of possibility? What areas do you think are obvious targets for optimization?
I'm not too familiar with gnuradio so this might be a stupid question but is there the possibility to maybe decode multiple SFs in parallel using multiple cores?

Docker container

Package gr-lora in a Docker container to mitigate system-dependent issues.

Supported platform

Does this project support USRP N210 and USRP 2901? Thanks!

Support of Wireshark via customized Message sink block

Hi @rpp0,

As discussed in another issue (closed now :) ), i'm trying to connect your project to wireshark.
Why wireshark, because since the dev version 2.5.0 the software include the support of LoRaTap and LoRaWAN.

But as LoRaWAN is not working on top of Ethernet, we need to modify the frame.
I finally succeed to make it works by following these steps :

• Run lora_receive_realtime with a message sink to docker0 IP address 172.17.0.1 instead of 127.0.0.1 (docker is not able to reach the host loopback address)
• Run the capture with tcpdump or wireshark.
• Apply the following filter to capture udp.dstport == 40868 && !icmp and save the capture (or filter directly with tcpdump)
• Remove Ethernet, IP and UDP headers (total of 42 bytes) and set DLT to 147 : bittwiste -I dump_lora_ethernet.pcap -O dump_lora_dlt_user.pcap -M 147 -D 1-42
• In Wireshark, edit the DLT_USER settings and set it : payload protocol : lorawan, header size : 18, header protocol : loratap. I used to 18 to include LoRaTap (15 bytes) and LoRaPHY(3 bytes)

We can also force to change the DLT to 270 (LoRaTAP) with editcap -T loratap dump_lora_ethernet.pcap dump_lora_dlt_user.pcap and use bittwiste to remove the headers without touching the DLT : bittwiste -I dump_lora_ethernet.pcap -O dump_lora_dlt_user.pcap -D 1-42

Maybe via a customized message sink block, we can change automatically remove the useless headers and set the DLT.
Please note that LoRaTAP have a dedicated DLT code (known by wireshark) : 270
--> https://www.tcpdump.org/linktypes.html (LINKTYPE_LORATAP)

AttributeError: 'module' object has no attribute 'channelizer'

After installation, I tried Testing. but I got error messages as follows:
I checked "Common compile and runtime errors" in wiki.
all yes except site-packages, lora module is in dist-packages.
files in lora directory:

/usr/local/lib/python2.7/dist-packages/lora$ ls
__init__.py   lora_decoder.py   lora_receiver.py   message_wireshark_sink.py
__init__.pyc  lora_decoder.pyc  lora_receiver.pyc  message_wireshark_sink.pyc
__init__.pyo  lora_decoder.pyo  lora_receiver.pyo  message_wireshark_sink.pyo

Error message:

$ ./lora_receive_file.py 
Using Volk machine: avx2_64_mmx_orc
Traceback (most recent call last):
  File "./lora_receive_file.py", line 188, in <module>
    main()
  File "./lora_receive_file.py", line 182, in main
    tb = top_block_cls()
  File "./lora_receive_file.py", line 72, in __init__
    self.lora_lora_receiver_0 = lora.lora_receiver(samp_rate, 868e6, ([868.1e6]), 7, 1000000, 0.01)
  File "/usr/local/lib/python2.7/dist-packages/lora/lora_receiver.py", line 43, in __init__
    self.channelizer = lora.channelizer(in_samp_rate, out_samp_rate, center_freq, channel_list)
AttributeError: 'module' object has no attribute 'channelizer'

cannot run the example

Hi,

I successfully installed the gr-lora, but when trying to run the example, error happens as follows:

./lora_receive_file_nogui.py
[?] Download test LoRa signal to decode? [y/N] y
[+] Downloading https://research.edm.uhasselt.be/probyns/lora/usrp-868.1-sf7-cr4-bw125-crc-0.sigmf-data -> ./example-trace.sigmf-data . . . . . . . . . . . . . . . . . .
[+] Downloading https://research.edm.uhasselt.be/probyns/lora/usrp-868.1-sf7-cr4-bw125-crc-0.sigmf-meta -> ./example-trace.sigmf-meta . .
[+] Configuration: 868.1 MHz, SF 7, CR 4/8, BW 125 kHz, prlen 8, crc on, implicit off
[+] Decoding. You should see a header, followed by 'deadbeef' and a CRC 5 times.
Traceback (most recent call last):
File "./lora_receive_file_nogui.py", line 96, in
tb = lora_receive_file_nogui(data_file_path, sample_rate, capture_freq, lora_config)
File "./lora_receive_file_nogui.py", line 30, in init
self.message_socket_sink = lora.message_socket_sink('127.0.0.1', 40868, False, False)
File "/usr/local/lib/python2.7/dist-packages/lora/lora_swig.py", line 784, in make
return _lora_swig.message_socket_sink_make(*args, **kwargs)
TypeError: message_socket_sink_make() takes at most 3 arguments (4 given)

Any ideas about that? I'm running on the Ubuntu.14.04

Nibbles seem inverted for PHDR

I've decoded some real LoRaWAN packets and I've noticed that the nibbles are inverted in the PHDR (at least in the first byte which is the length of the packet)

Examples are below. The 40, 80, 00 after the first 3 bytes are OK (it's the correct LoRaWAN MType for unconfirmed uplink, Unconfirmed downlink and Join Request respectively) but the first byte seems to be the LoRa packet length but with nibbles swapped.

Of course, it's not a big deal because the rest of the packet is OK.

By the way, does someone know the meaning of the other 2 bytes ?

 b1 13 0e 80 xx xx xx .. .. (length of the MAC packet is 27 or 0x1B)
 71 13 08 00 xx xx xx .. .. (length of the MAC packet is 23 or 0x17)
 71 13 08 00 xx xx xx .. .. (length of the MAC packet is 23 or 0x17)
 51 13 01 80 xx xx xx .. .. (length of the MAC packet is 21 or 0x15)
 11 13 0b 40 xx xx xx .. .. (length of the MAC packet is 17 or 0x11)

Decoding Lora packets with different spreading factors simultaneously

Hi, I synchronized two Lora transmitters in order to have a collision of two packets with different spreading factors at the receiver (e.g. one packet with sf=7 and one packet with sf=8). I set gr-lora with both spreading factors by I can't actually decode neither of them.
Is this an issue related to real time decoding or gr-lora doesn't support this feature yet?

Thanks in advance.

Improve synchronization

Since the project is still in early development, clock synchronization isn't ideal yet: this is done at the moment by looking for the slope of a downchirp and then performing a correlation of the transient with an ideal downchirp. If the argmax of the correlation result is not within a hardcoded range, the decoder will not see the frame.

This should be changed to be more flexible and not depend on a hardcoded value. For each of the samples given in gr-lora-samples, it should work decently (captured with a HackRF). For samples captured by other devices, this might not work at all.

Add the support of LoRaTAP and SNR calculation into the docker images

Hi rpp0,

You added the support of LoRa TAP and SNR calculation into dev and master branch but unfortunately when I'm trying to enable the feature I'm getting this error :
message_socket_sink_impl::handle: LoRaTap is not supported yet.

Did you have any plan to update your docker images with your last commits ?

Best Regards,
Thibault

Installation issue in mac

Hi,
I am trying to install the package in mac with all dependencies installed. However when I am trying to execute "make", I am facing an error:

[ 3%] Building CXX object lib/CMakeFiles/gnuradio-lora.dir/decoder_impl.cc.o
In file included from /Users/gr-lora/lib/decoder_impl.cc:31:
/Users/gr-lora/include/lora/utilities.h:128:29: warning:
range-based for loop is a C++11 extension [-Wc++11-extensions]
for (const T& x : v)
^
In file included from /Users/gr-lora/lib/decoder_impl.cc:32:
/Users/gr-lora/lib/decoder_impl.h:39:14: warning:
scoped enumerations are a C++11 extension [-Wc++11-extensions]
enum class DecoderState {
^
/Users/gr-lora/lib/decoder_impl.cc:53:33: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::DETECT;
^
/Users/gr-lora/lib/decoder_impl.cc:716:32: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
case gr::lora::DecoderState::DETECT: {
^
/Users/gr-lora/lib/decoder_impl.cc:716:22: error:
expression is not an integral constant expression
case gr::lora::DecoderState::DETECT: {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/gr-lora/lib/decoder_impl.cc:724:45: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::SYNC;
^
/Users/gr-lora/lib/decoder_impl.cc:733:32: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
case gr::lora::DecoderState::SYNC: {
^
/Users/gr-lora/lib/decoder_impl.cc:733:22: error:
expression is not an integral constant expression
case gr::lora::DecoderState::SYNC: {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/gr-lora/lib/decoder_impl.cc:744:41: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::FIND_SFD;
^
/Users/gr-lora/lib/decoder_impl.cc:748:32: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
case gr::lora::DecoderState::FIND_SFD: {
^
/Users/gr-lora/lib/decoder_impl.cc:748:22: error:
expression is not an integral constant expression
case gr::lora::DecoderState::FIND_SFD: {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/gr-lora/lib/decoder_impl.cc:762:45: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::PAUSE;
^
/Users/gr-lora/lib/decoder_impl.cc:771:49: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::DETECT;
^
/Users/gr-lora/lib/decoder_impl.cc:782:32: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
case gr::lora::DecoderState::PAUSE: {
^
/Users/gr-lora/lib/decoder_impl.cc:782:22: error:
expression is not an integral constant expression
case gr::lora::DecoderState::PAUSE: {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/gr-lora/lib/decoder_impl.cc:784:45: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::DECODE_PAYLOAD;
^
/Users/gr-lora/lib/decoder_impl.cc:787:45: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::DECODE_HEADER;
^
/Users/gr-lora/lib/decoder_impl.cc:793:32: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
case gr::lora::DecoderState::DECODE_HEADER: {
^
/Users/gr-lora/lib/decoder_impl.cc:793:22: error:
expression is not an integral constant expression
case gr::lora::DecoderState::DECODE_HEADER: {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/gr-lora/lib/decoder_impl.cc:817:45: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::DECODE_PAYLOAD;
^
/Users/gr-lora/lib/decoder_impl.cc:824:32: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
case gr::lora::DecoderState::DECODE_PAYLOAD: {
^
/Users/gr-lora/lib/decoder_impl.cc:824:22: error:
expression is not an integral constant expression
case gr::lora::DecoderState::DECODE_PAYLOAD: {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/gr-lora/lib/decoder_impl.cc:839:45: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
d_state = gr::lora::DecoderState::DETECT;
^
/Users/gr-lora/lib/decoder_impl.cc:848:32: warning:
use of enumeration in a nested name specifier is a C++11 extension
[-Wc++11-extensions]
case gr::lora::DecoderState::STOP: {
^
/Users/gr-lora/lib/decoder_impl.cc:848:22: error:
expression is not an integral constant expression
case gr::lora::DecoderState::STOP: {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
18 warnings and 7 errors generated.
make[2]: *** [lib/CMakeFiles/gnuradio-lora.dir/decoder_impl.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-lora.dir/all] Error 2
make: *** [all] Error 2

Problem with lora_receive_realtime.py

Hello,

I am always getting this error while lora_receiver.py. The error is:
"Module has no attribute decode" referring to
self.c_decoder=lora.decoder(sf)

I get this on Cmake:
disabling swig because version check failed

Thanks,
Rashad

Make failed at test-lora

Hello, I have this error when I try to run make during installation of gr-lora on ubuntu 16.04

Scanning dependencies of target gnuradio-lora
[ 4%] Building CXX object lib/CMakeFiles/gnuradio-lora.dir/decoder_impl.cc.o
[ 8%] Building CXX object lib/CMakeFiles/gnuradio-lora.dir/message_file_sink_impl.cc.o
[ 12%] Linking CXX shared library libgnuradio-lora.so
[ 12%] Built target gnuradio-lora
Scanning dependencies of target test-lora
[ 16%] Building CXX object lib/CMakeFiles/test-lora.dir/test_lora.cc.o
[ 20%] Building CXX object lib/CMakeFiles/test-lora.dir/qa_lora.cc.o
[ 24%] Linking CXX executable test-lora
CMakeFiles/test-lora.dir/test_lora.cc.o: In function main': test_lora.cc:(.text.startup+0x21a): undefined reference to CppUnit::XmlOutputter::XmlOutputter(CppUnit::TestResultCollector*, std::ostream&, std::string)'
test_lora.cc:(.text.startup+0x28b): undefined reference to CppUnit::TextTestRunner::run(std::string, bool, bool, bool)' CMakeFiles/test-lora.dir/qa_lora.cc.o: In function qa_lora::suite()':
qa_lora.cc:(.text+0x30): undefined reference to `CppUnit::TestSuite::TestSuite(std::string)'
collect2: error: ld returned 1 exit status
lib/CMakeFiles/test-lora.dir/build.make:130: recipe for target 'lib/test-lora' failed
make[2]: *** [lib/test-lora] Error 1
CMakeFiles/Makefile2:174: recipe for target 'lib/CMakeFiles/test-lora.dir/all' failed
make[1]: *** [lib/CMakeFiles/test-lora.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I have already install some dependencies mentions in previous issues like liquid-dsp and swig but it's still not working. I am very appreciated if someone can help me on this problem. I attach also the output of cmake in case it's needed.
cmake output.txt

Thank you so much

P/s: I'm using BladeRF for a Receiver LoRa and I didn't see it in the list of verified Hardwares for gr-lora. Does anyone have test already with this board ?

Reception on 434MHz band with HopeRF RFM98W not working reliably

I'm trying to receive LoRa packets sent by my Raspberry Pi LoRa shield with RFM98W chip, but I've only managed to receive a couple of packets randomly from almost a constant stream of packets. Also, the packet data does not seem to be starting from the very beginning of the packet payload. The small amount of data I managed to receive looks correct anyway.

I'm using the following settings: explicit LoRa header, SF7, BW 125k, CR 4:5, CRC on. I've tried other settings too (CR 4:8, smaller bandwidth and higher SF) but these are the only settings I've received any packets with.

I'm using 2M sample rate on 434.250 MHz frequency with NESDR SMArt (RTL-SDR) USB dongle and I've verified using Gqrx that when tuning to 434.250, it's receiving at the center of the signal bandwidth. 1M sample rate does not seem to produce any results.

The packets I'm sending are mostly very long, up to the maximum of 255 bytes.

Questions:

1. Does gr-lora detect bandwidth and coding rate automatically and support them all?

2. Does gr-lora add something to the beginning of the packet or will it output incomplete packets if it can't decode the whole packet?

3. Does the current implementation have restrictions on the length of the packet?

4. How does the preamble length affect the reception for gr-lora? I've noticed that having a longer preamble certainly helps reception with a LoRa chip, so I've been using preamble length of 0xC0.

5. What is the offset parameter on LoRa receiver module used for?

Installation dependencies after install instructions

The dependencies are listed after the installation directions which is not intuitive and can be confusing.

Fix 'make test'

The user should be able to run make test inside the build folder in order to run the unit tests, instead of executing the shell scripts in build/python.

Use Hamming functions from liquid-dsp

Currently, we use our own Hamming decoding functions for decoding LoRa messages. Using the Hamming functionality of liquid-dsp would reduce the amount of code and probably be more efficient.

AttributeError: 'module' object has no attribute 'decoder'

Hello,
I try to use your block LoRa receiver but i have the following error:
File "/home/mcharfi/top_block.py", line 76, in __init__ self.lora_lora_receiver_0 = lora.lora_receiver(1e6, 868e6, 100e3, 7, 1000000, 0.01) File "/usr/lib/python2.7/dist-packages/lora/lora_receiver.py", line 49, in __init__ self.c_decoder = lora.decoder(out_samp_rate, sf) AttributeError: 'module' object has no attribute 'decoder' OOOOOOOOOOO..
During the installation i had some warning after use the command line:
cmake -DCMAKE_INSTALL_PREFIX=/usr
result: install1.txt

and after the command make
result:install2.txt

after sudo make install:
install3.txt.

I tried the other solution discussed in issues #13 and #17. But without success.
Please note that i used Pybombs to install gnuradio companion.
Thanks.

Support all spreading factors

Spreading factor 7 is fully supported. Other spreading factors still need to be implemented.

Travis CI build time exceeds maximum limit

The build time for the project on Travis CI exceeds the maximum limit of 50 minutes, resulting in a build error.

Message not displayed

I am trying to receive messages on Ettus USRP N210 and transmitting with sx1276 programmed over nucleo board. I see peaks in the fft, but the messages are not displayed. I tried saving the samples to a file and then using a lora receiver but the problem still persists. Also, I can see unable to set thread priority warning with UHD. I also tried transmitting using Microchip RN2483 module in mobile mode, I don't see those messages either.

Must install Scapy

The user must install Scapy through
sudo apt-get install python-scapy
for ./lora_receive_file.py to work.

LoRa Transmission Functionality

Hello!
I first want to say thank you for all the hard work you've done on this. Every update seems to improve the module so much! The decoding works well with the boards I use currently (Custom Arduino Leonardo with a RN2093A @ 915MHz).
I'm starting to get more involved in research with the scalability of LoRa and LoRaWAN, specifically with multi-gateway and city-wide applications. With that said, is there any hope for a TX block in the future? I would love to be able to take this PHY layer implementation and put an open-source LoRaWAN MAC on top of it and turn the USRP's I have into gateways without the need to interface them with any external hardware.
Thanks!

AttributeError: 'module' object has no attribute 'decoder'

Hello, we are opening your example (same applies for file sync and realtime example) and we are getting this error:
Please take into account that we modified the source according to issue #12 in order to compile gr-lore.

Generating: '/home/guido/LoRa_GRC/gr-lora/apps/lora_receive_realtime.py'

Executing: /usr/bin/python2 -u /home/guido/LoRa_GRC/gr-lora/apps/lora_receive_realtime.py

linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.git-28-gc66cb1ba

Traceback (most recent call last):
  File "/home/guido/LoRa_GRC/gr-lora/apps/lora_receive_realtime.py", line 30, in <module>
    import lora
  File "/usr/local/lib/python2.7/dist-packages/lora/__init__.py", line 35, in <module>
    from lora_receiver import lora_receiver
  File "/usr/local/lib/python2.7/dist-packages/lora/lora_receiver.py", line 28, in <module>
    from lora import decoder
ImportError: cannot import name decoder

how to use grc block

Hello,

How to use these grc block with a hackRf for input (in order to decode traffic from my LoRa device)

Thanks,

testing

i tried to run python lora_receive_file_nogui.py file, but i got folloing error:

.. gr-lora/apps$ python lora_receive_file_nogui.py
Traceback (most recent call last):
File "lora_receive_file_nogui.py", line 11, in
from lora.loraconfig import LoRaConfig
ImportError: No module named loraconfig

TO-DOs

A list of small TO-DOs and future improvements for gr-lora.

• In some test files, in the last packet only the decoded HDR gets printed, without the payload. This might be caused by the failsafe if it reaches noise and the payload length was not satisfied.
• Add parity checks for all Hamming codes?
• Test with higher sample rate?
• Correct clock drift?
• Further FFT improvements
• Test decoding of packets with multiple SFs in same signal.
  • Use for example multiplication with ideal downchirp etc....?
  • Rework FFT to detect other frequencies?

error compiling on Ubuntu 16.04

Hello, I have installed the deps and ran the commands to build until make, that fails just here:

-- Configuring done
-- Generating done
-- Build files have been written to: /home/a/Documents/gr-lora/build

a@dspstv:~/Documents/bemap/gr-lora/build$ make
[ 4%] Building CXX object lib/CMakeFiles/gnuradio-lora.dir/decoder_impl.cc.o
In file included from /usr/include/c++/5/cstdint:35:0,
from /home/a/Documents/gr-lora/lib/utilities.h:4,
from /home/a/Documents/gr-lora/lib/decoder_impl.cc:32:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support
^
In file included from /home/a/Documents/gr-lora/lib/decoder_impl.cc:30:0:
/home/a/Documents/gr-lora/lib/decoder_impl.h:37:9: warning: scoped enums only available with -std=c++11 or -std=gnu++11
enum class DecoderState {
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.h:97:41: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
firdecim_crcf d_decim = nullptr;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.h:97:41: error: ‘nullptr’ was not declared in this scope
In file included from /home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:32:0:
/home/a/Documents/bemap/gr-lora/lib/utilities.h: In function ‘void gr::lora::print_vector(std::ostream&, const std::vector&, const string&, int)’:
/home/a/Documents/bemap/gr-lora/lib/utilities.h:46:24: warning: range-based ‘for’ loops only available with -std=c++11 or -std=gnu++11
for (T x : v)
^
/home/a/Documents/bemap/gr-lora/lib/utilities.h: In function ‘void gr::lora::print_vector_raw(std::ostream&, const std::vector&, int)’:
/home/a/Documents/bemap/gr-lora/lib/utilities.h:55:24: warning: range-based ‘for’ loops only available with -std=c++11 or -std=gnu++11
for (T x : v)
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc: In constructor ‘gr::lora::decoder_impl::decoder_impl(float, uint8_t)’:
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:57:39: error: ‘gr::lora::DecoderState’ is not a class or namespace
this->d_state = gr::lora::DecoderState::DETECT;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc: In member function ‘virtual int gr::lora::decoder_impl::work(int, gr_vector_const_void_star&, gr_vector_void_star&)’:
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:764:32: error: ‘gr::lora::DecoderState’ is not a class or namespace
case gr::lora::DecoderState::DETECT: {
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:783:55: error: ‘gr::lora::DecoderState’ is not a class or namespace
this->d_state = gr::lora::DecoderState::SYNC;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:797:32: error: ‘gr::lora::DecoderState’ is not a class or namespace
case gr::lora::DecoderState::SYNC: {
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:813:51: error: ‘gr::lora::DecoderState’ is not a class or namespace
this->d_state = gr::lora::DecoderState::PAUSE;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:818:55: error: ‘gr::lora::DecoderState’ is not a class or namespace
this->d_state = gr::lora::DecoderState::DETECT;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:829:32: error: ‘gr::lora::DecoderState’ is not a class or namespace
case gr::lora::DecoderState::PAUSE: {
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:830:47: error: ‘gr::lora::DecoderState’ is not a class or namespace
this->d_state = gr::lora::DecoderState::DECODE_HEADER;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:836:32: error: ‘gr::lora::DecoderState’ is not a class or namespace
case gr::lora::DecoderState::DECODE_HEADER: {
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:860:51: error: ‘gr::lora::DecoderState’ is not a class or namespace
this->d_state = gr::lora::DecoderState::DECODE_PAYLOAD;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:869:32: error: ‘gr::lora::DecoderState’ is not a class or namespace
case gr::lora::DecoderState::DECODE_PAYLOAD: {
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:887:55: error: ‘gr::lora::DecoderState’ is not a class or namespace
this->d_state = gr::lora::DecoderState::DETECT;
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:902:32: error: ‘gr::lora::DecoderState’ is not a class or namespace
case gr::lora::DecoderState::STOP: {
^
In file included from /home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:32:0:
/home/a/Documents/bemap/gr-lora/lib/utilities.h: In instantiation of ‘void gr::lora::print_vector(std::ostream&, const std::vector&, const string&, int) [with T = unsigned char; std::ostream = std::basic_ostream; std::__cxx11::string = std::__cxx11::basic_string]’:
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:532:74: required from here
/home/a/Documents/bemap/gr-lora/lib/utilities.h:47:30: error: use of local variable with automatic storage from containing function
out << to_bin(x, element_len_bits) << ", ";
^
/home/a/Documents/bemap/gr-lora/lib/utilities.h:46:20: note: ‘unsigned char x’ declared here
for (T x : v)
^
/home/a/Documents/bemap/gr-lora/lib/utilities.h: In instantiation of ‘void gr::lora::print_vector_raw(std::ostream&, const std::vector&, int) [with T = unsigned char; std::ostream = std::basic_ostream]’:
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:594:94: required from here
/home/a/Documents/bemap/gr-lora/lib/utilities.h:56:30: error: use of local variable with automatic storage from containing function
out << to_bin(x, element_len_bits);
^
/home/a/Documents/bemap/gr-lora/lib/utilities.h:55:20: note: ‘unsigned char x’ declared here
for (T x : v)
^
/home/a/Documents/bemap/gr-lora/lib/decoder_impl.cc:891:41: warning: ignoring return value of ‘int system(const char*)’, declared with attribute warn_unused_result [-Wunused-result]
DBGR_PAUSE();
^
lib/CMakeFiles/gnuradio-lora.dir/build.make:62: recipe for target 'lib/CMakeFiles/gnuradio-lora.dir/decoder_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-lora.dir/decoder_impl.cc.o] Error 1
CMakeFiles/Makefile2:137: recipe for target 'lib/CMakeFiles/gnuradio-lora.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-lora.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Speed up decoding of high SFs

Decoding of higher SFs, e.g. SF 11 and SF 12, is slow because of the high number of samples involved. A different approach must be used to decode messages with these SFs.

Downlink messages not decoded ?

Hi,

Is there any reason why the downlink messages are not decoded ? The structure is roughly the same (except there shouldn't be any CRC).

Is this intentional or is it linked to the way the dowlink packet is modulated ?