bastilleresearch/gr-lora

GNU Radio OOT module implementing the LoRa PHY, based on https://github.com/matt-knight/research/tree/master/2016_05_20_jailbreak

gr-lora's Issues

B200

can i run these grc files on B200 device, or i need to change channel number somewhere?

Explicit HDR

I am currently improving rpp0/gr-lora as part of my bachelor thesis.

Like in #12, I am trying to run captured files with this repository to be able to compare the accuracy and run time. However all these files have packets containing an explicit header and data, which this repo apparently cannot handle.

e.g.
Data sent with RN2483 with coding rate = 4/5, bandwidth = 125k, spreading factor = 8, CRC = on:
0x01 0x23, 0x45 0x67 0x89 0xAB 0xCD 0xEF

And received:

• rpp0/gr-lora: (which is expected)
  80 0b 00 01 23 45 67 89 ab cd ed
• BastilleResearch/gr-lora with
  BW = 125k, SF = 8, offset = -100k, frequency = 868M, CR = 4, ldr = False and header = True:
  7f fd 1c 86 ec 32 19 7d ce 3a 46

What should I change to be able to decode the data? (Decoding the header is currently not necessary.)

Can the decoded data packet be sent to the network server intact

I haven't been in touch with software defined radio, but I'm curious about whether this work completely covers lorawan's network server, application server and other structures.

about the gray coding

Hi @matt-knight I've been reading your ppt and watch the video, I have read all the program of the gr-lora, because i don't have the usrp board, i use ad9364 instead, i have demod the lora signal, but when dealing with decode, I am confused, why use to_gray() in the decode program, other than using from_gray().
thanks!!!

unable to run the default examples

Dear all,

I installed GNURadio and drivers for my USRP N210 on Ubuntu 16.04 LTS using the following commands.

`sudo apt-get install libuhd-dev libuhd003 uhd-host GNURadio
After setting the IP of my PC ethernet to 192.168.10.3, I am able to successfully communicate with the USRP and its FPGA too was upgraded to latest firmware. Although, I did try using PPA;s for installing UHD drivers and GNURadio, their combination didnt work. Installing from default repos got me to the point to use the USRPs.

My intension is to receive LoRa packets using the USRP N210. Hence, I did the following,

git clone git://github.com/BastilleResearch/gr-lora.git
cd gr-lora
mkdir build
cd build
cmake ../
make
sudo make install
sudo ldconfig

All the above commands ran with no problem.

I then went into examples folder and tried to run the tx_usrp example. But I keep receiving the following error message. I just want to get these examples to work so that I can work my way up.

<<< Welcome to GNU Radio Companion 3.7.9 >>>

Preferences file: /home/user/.gnuradio/grc.conf
Block paths:
	/usr/local/share/gnuradio/grc/blocks
	/usr/share/gnuradio/grc/blocks
	/home/user/.grc_gnuradio

Loading: "/home/user/Downloads/txrx_usrp.grc"
>>> Done

Showing: "/home/user/Downloads/txrx_usrp.grc"

Loading: "/home/user/gr-lora/examples/tx_usrp.grc"
>>> Done

Showing: "/home/user/gr-lora/examples/tx_usrp.grc"

Generating: '/home/user/gr-lora/examples/top_block.py'

Executing: /usr/bin/python -u /home/user/gr-lora/examples/top_block.py

linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
    Unable to set the thread priority. Performance may be negatively affected.
    Please see the general application notes in the manual for instructions.
    EnvironmentError: OSError: error in pthread_setschedparam
Using Volk machine: avx2_64_mmx_orc
Traceback (most recent call last):
  File "/home/user/gr-lora/examples/top_block.py", line 228, in <module>
    main()
  File "/home/user/gr-lora/examples/top_block.py", line 222, in main
    tb = top_block_cls()
  File "/home/user/gr-lora/examples/top_block.py", line 137, in __init__
    self.lora_mod_0 = lora.mod(spreading_factor, 0x12)
AttributeError: 'module' object has no attribute 'mod'

>>> Done (return code 1)

Generating: '/home/user/gr-lora/examples/top_block.py'

Executing: /usr/bin/python -u /home/user/gr-lora/examples/top_block.py

linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
    Unable to set the thread priority. Performance may be negatively affected.
    Please see the general application notes in the manual for instructions.
    EnvironmentError: OSError: error in pthread_setschedparam
Using Volk machine: avx2_64_mmx_orc
Traceback (most recent call last):
  File "/home/user/gr-lora/examples/top_block.py", line 228, in <module>
    main()
  File "/home/user/gr-lora/examples/top_block.py", line 222, in main
    tb = top_block_cls()
  File "/home/user/gr-lora/examples/top_block.py", line 137, in __init__
    self.lora_mod_0 = lora.mod(spreading_factor, 0x12)
AttributeError: 'module' object has no attribute 'mod'

>>> Done

I did not chose a specific location to install GNURadio and I am doubting if thats the reason for my errors.

I noticed that in the wiki, there are instructions to set some PATH variables. I understand how to generally set PATH variables in GNU/Linux but I do not know where exactly to set these paths to as I did the normal installation; not to a specific installation directory. I also do not know how to figure out where those path variables must be set to. I did try compiling GNURadio from source but it didn't work out for me.

I would really appreciate some advice, the strategic approach to get these default examples to work.

Thanks a lot.

Decode data from RN2483

Hi,

Thanks for the cool product.
Interesting thing to test, but I was not able to get proper data from RN2483.

I am sending this data to the modem:

mac pause
radio set mod lora
radio set sf sf8
radio set freq 869100000
radio set cr 4/8
radio tx 1234 (this in a loop)

With 'rpp0/gr-lora' I can decode the data properly, and get output like '02 90 70 12 34 c8 ea' - "12 34" is there.

With BastilleResearch/gr-lora I am getting wrong data: 'df f7 2b 56 5b 02'.
Parameters (SF, bw, others looks the same).

Is it a bug, or I'm doing something wrong, or this library is not compatible with RN2483?

GRC and IQ file in attach:
lora_test.zip

Thanks.

Import LoRa Error

Hi all,
I just installed GNUradio and gr-lora on my PC running windows 10. After solving a few issues concerning "Missing xterm", I am facing another issue pasted below. Please can anyone kindly provide a way around this problem. Thanks in advance!

line 15, in
import lora
ImportError: No module named lora

Done

Port gr-lora from GR3.7 to GR3.8

Hey all,

This is not an issue but I don't know where to post. I'll close it few days later if I don't receive any response.

As a beginner, I just started to working on the development side of OOT for gnuradio and lora.
Very keen to upgrade this code to gnuradio 3.8 to make it compatible with python3. Facing some python bindings issues and unable to solve by myself.
Would love to collaborate and share ideas if anyone interested to work on this.

Cheers!!

Camke error

hello i am getting the error for CMP00XX ...
can anyone help me to resolve this error.

-- Build type not specified: defaulting to release.
CMake Deprecation Warning at CMakeLists.txt:39 (cmake_policy):
The OLD behavior for policy CMP0026 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

CMake Deprecation Warning at CMakeLists.txt:44 (cmake_policy):
The OLD behavior for policy CMP0045 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.35") found components: filesystem system
-- Using GMP.
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.71.0") found components: date_time program_options system regex thread unit_test_framework
CMake Warning (dev) at /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:35 (if):
if given arguments:

"ON"

An argument named "ON" appears in a conditional statement. Policy CMP0012
is not set: if() recognizes numbers and boolean constants. Run "cmake
--help-policy CMP0012" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
Call Stack (most recent call first):
CMakeLists.txt:124 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) in /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:
Policy CMP0011 is not set: Included scripts do automatic cmake_policy PUSH
and POP. Run "cmake --help-policy CMP0011" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

The included script

/usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake

affects policy settings. CMake is implying the NO_POLICY_SCOPE option for
compatibility, so the effects are applied to the including context.
Call Stack (most recent call first):
CMakeLists.txt:124 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Error at CMakeLists.txt:128 (message):
GnuRadio Runtime required to compile lora

-- Configuring incomplete, errors occurred!
See also "/home/vboxuser/gr-lora/build/CMakeFiles/CMakeOutput.log".
See also "/home/vboxuser/gr-lora/build/CMakeFiles/CMakeError.log".

Dragino setup > no documentation

Hello,

You could provide more documentation. You say that you can only use the Dragino for transmit not receiving, why is that when it is a transreceiver?!
I managed to compile and install this on my pi:

-- Installing: /usr/local/lib/cmake/lora/loraConfig.cmake
-- Installing: /usr/local/include/lora/api.h
-- Installing: /usr/local/include/lora/demod.h
-- Installing: /usr/local/include/lora/decode.h
-- Installing: /usr/local/include/lora/mod.h
-- Installing: /usr/local/include/lora/encode.h
-- Installing: /usr/local/lib/libgnuradio-lora.so
-- Installing: /usr/local/lib/python2.7/dist-packages/lora/init.py
-- Installing: /usr/local/lib/python2.7/dist-packages/lora/init.pyc
-- Installing: /usr/local/lib/python2.7/dist-packages/lora/init.pyo
-- Installing: /usr/local/share/gnuradio/grc/blocks/lora_demod.xml
-- Installing: /usr/local/share/gnuradio/grc/blocks/lora_decode.xml
-- Installing: /usr/local/share/gnuradio/grc/blocks/lora_mod.xml
-- Installing: /usr/local/share/gnuradio/grc/blocks/lora_encode.xml

This is all I got. Don't you provide a daemon to run which captures packets like kismet?
I eventually want to implement 2 way communication between 2 dragino unos, completely opensource, no things network.

Thanks

Can this code run in 2.4GHz?

Since I only have USRP N210 only support 2.4GHz and 5GHz, I want to simply have a test in 2.4 GHz band. However, I find that the signal received in the RX is very different from the sent signal and cannot maintain the shape of the "chirp" sweeping the bandwidth. I want to know what the problem is and Can anyone give some suggestions. Thanks!

CMake Warnings

Update CMakeLists.txt to address CMP0045 and Policy CMP0026 warnings. The path of least resistance is to force the use of old/pre-3.0 API behavior.

Build succeeds even if SWIG is not found, breaking examples.

Building without SWIG seems to work fine but it breaks the examples, resulting e.g. in #11.

Is SWIG always required for gr-lora to work? If it is, we should make the build fail if it can't be found, by changing CMakeLists.txt line 31 to

find_package(SWIG REQUIRED)

If there are cases where you want to just skip the Python bindings, we could instead add a warning before CMakeLists.txt line 34 like

message(WARNING "SWIG or Python-libs not found. Skipping Python bindings.")
message(WARNING "Note that examples won't work!")

Since I'm a total GNUradio noob, I can't tell which one is right, so not opening a PR yet ¯\_(ツ)_/¯

gr-lora does not receive the messages

I'm working with an HackRF One and a Dragino LoRA shield (v1.4, this one) + Arduino Uno. I also using the LMIC library with the example sketch (Arduino sketch).
The setup is:
Frequency: 686MHz
Spreading factor: 8 (Can be set from 7 to 12)
BW: 125K
The sketch sends a message ("Hello, world") every 5 seconds.
I tried several configurations of the rx_ursp sketch (I attached the modified file), but I can not receive any message.
I tried to receive the same message with gr-lora/rpp0 and it worked(also attached).
I'm not sure what I am doing wrong but I really would like to use this lora package to receive AND send lora packets.
Does somebody has the same experience or any clue, what the reason could be?
Both files are here

the ralationship between spread factor and header?

I am learning the source code and when I read the encode_impl.cc file, I read the code as this:

I do not understand the ralationship between sf and header.
Why header_nybbles' length is (d_sf - 2)？
Thanks!!!

PHY CRC support

The optional PHY CRCs should be deduced and implemented. #2 and possibly #3 are blocking items.

SX1272 - SF6, Implicit header, CR4/5, LDR enabled

Hi, I'm working with an SX1272 using SF6, implicit header, CR4/5 and LDR enabled. The header portion correctly decodes however the payload does not. Is there an obvious reason why this isn't working that I am missing?

I'm unable to determine if SF6 should correctly decode as most testing seems to have been performed with SF's 7-12.

Receive incorrect data on Pycom LoPy LoRa

I am sending 'Hello mitcoe' message from file source as well as socket using USRP B200 hardware
Parameters :
Frequency: 868MHz
SF: 8
Code rate: 4
BW: 250KHz
Sampling Rate: 250 KHz
Header: True
and i want to receive this on Pycom LoPy LoRa node.
same parameters on LoPy LoRa node.
But i receive on LoPy LoRa some things like this
Received data:
1 b'\xe7\xe7+\xfa\x00MB'
2 ��+�MB
3 b'e7e72bfa004d42'
Rx_cnt:1
(rx_timestamp=676924426, rssi=-98, snr=0.0, sfrx=8, sftx=0, tx_trials=0)
Received data:
1 b'\xe7\xe7\xeb\xfa\x00MB'
2 ����MB
3 b'e7e7ebfa004d42'
Rx_cnt:2
(rx_timestamp=677851000, rssi=-98, snr=0.0, sfrx=8, sftx=0, tx_trials=0)

My LoPy code to receive data is:
print("In Receive Mode")
s.setblocking(False)
while True:
data = s.recv(64)
if(data):
print("Received data: "+"\n1",data)
print ("2",data.decode('utf-8'))
print("3",binascii.hexlify(data))
i+=1
rx2tx_data = 'Rx_cnt:'+str(i)
print(rx2tx_data)
print(lora.stats())

I am not able to receive correct data.

Also i am sending message multiple times but lora only receives twice or thrice.

Resampling

Hi!
I started working with SDR and GNU Radio not long ago and have a misunderstanding.

As far as I understand, the generated chirps in /lib/mod_impl.cc have the bandwidth 2*pi.
Then in the flowgraph the interpolation by factor sample_rate/bandwidth is applied and the signal is transmitted. What is the sampling frequency after the modulator? It should be bandwidth rate (250e3, for example). But how is it achived?

The reason I'm asking is that I want to add noise after the modulator and measure the error rate and can't figure out what signal bandwidth to choose to get the right noise power value.

Each and every advice is appreciated)

Ettus E313 SDR module' object has no attribute ‘demod'

Hello!

I am trying to install the module on my Ettus E313 - embedded SDR with AMR Cortex A9. The OS seems to be a custom flavour of Debian. I follow the instructions given here and I set my system paths as

export LD_LIBRARY_PATH=/gr-lora/lib:$LD_LIBRARY_PATH
export CPATH=/gr-lora/include:$CPATH
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:/gr-lora/lib/python2.7/site-packages:$PYTHONPATH
export GRC_BLOCKS_PATH=/gr-lora/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH

The error I get in grc is
File "/home/root/grc_programs/Kyp/433_LoRa/I433_LoRa_scan.py", line 86, in init
self.lora_demod_0_0 = lora.demod(spreading_factor, ldr, 25.0, 2)
AttributeError: 'module' object has no attribute ‘demod'

Any help is appreciated. I have tried all the suggestions in #12 and #11 . Another thing to note is that when I run the ldconfig command at the end of the process I get /usr/lib/libstdc++.so.6.0.20-gdb.py is not an ELF file - it has the wrong magic bytes at the start.

Any help is appreciated. Please let me know if you require more information.

which is type of gr-lora input modulator?

it's input modulator has gray input, why we have not data type complex,float and...so on........
your example can not work with file source in gnuradio
best regards stackprogramer

Corrupt packets received from HopeRF RFM98W at 434MHz

I'm trying to receive LoRa packets sent by my Raspberry Pi LoRa shield with RFM98W chip, but I've only succeeded to receive corrupt data (very randomly).

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.

I've tested another gr-lora implementation (by rpp0) and had similar problems: rpp0/gr-lora#15 although I was able to receive parts of the data correctly.

I'm submitting the same example IQ file and the GNU Radio graphs for this project to help development. (Unfortunately, my skills in signal processing are almost nonexistent, so I'm not able to contribute to the code...)

I've made a cfile (converted to complex from rtl_sdr bin capture) of using settings: SF7, CR4:8, bandwidth 125kHz, 2M sample rate and preamble of 0x08, and tested that reception "works" from the file in GNU Radio. I verified that packets are missed and data in all packets is corrupt. All data in packets should be plain text (as listed below).

I've attached the GNU radio graph here:
rtlsdr-lora-receive-mattknight.grc.zip

(BTW Why are the additional resampler and rotator elements needed? This could be added to the documentation.)

The captured signal cfile can be downloaded here (for the next 48 hours):
https://expirebox.com/download/cb1750ca2f660e6290186ff0cedf79a7.html

For capturing the signal I used the following command:

rtl_sdr -f 434250000 -s 2000000 capture-lora-rfm98w-434250000-sf7-bw125k-cr48-crcon-2msps.bin

And for conversion I used this GNU Radio graph: http://ham.stackexchange.com/a/2117

The transmission contains the following messages (without the quotes):

2016-12-20 08:55:04.512213 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0001: SHORT MESSAGE END"
2016-12-20 08:55:04.598480 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0002: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:05.012920 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0003: SHORT MESSAGE END"
2016-12-20 08:55:05.092218 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0004: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:05.505725 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0005: SHORT MESSAGE END"
2016-12-20 08:55:05.585291 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0006: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:05.995854 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0007: SHORT MESSAGE END"
2016-12-20 08:55:06.074197 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0008: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:06.486301 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0009: SHORT MESSAGE END"
2016-12-20 08:55:06.564632 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0010: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:06.976913 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0011: SHORT MESSAGE END"
2016-12-20 08:55:07.055899 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0012: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:07.468894 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0013: SHORT MESSAGE END"
2016-12-20 08:55:07.547670 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0014: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:07.959763 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0015: SHORT MESSAGE END"
2016-12-20 08:55:08.037965 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0016: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:08.447643 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0017: SHORT MESSAGE END"
2016-12-20 08:55:08.526002 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0018: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:08.938190 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0019: SHORT MESSAGE END"
2016-12-20 08:55:09.017061 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0020: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"

What I receive in Wireshark is just garbage in the data portion of the UDP packets.

LoRa RX/TX example doesn't receive data

I complied the gr-LoRa project successfully by running the commands,

git clone git://github.com/BastilleResearch/gr-lora.git
cd gr-lora
mkdir build
cd build
cmake ../
make
sudo make install
sudo ldconfig

I am using USRP N210 device with compatible daughter-board from which I have already viewed a LoRa chirp using GNU/Radio spectrogram.

After successfully compiling the gr-LoRa project and prior to opening the txrz_usrp.grc example I opened a UDP netcat server so that the socket PDU on port 52002 would safety connect. On the other terminal I had a UDP client running on port 52001. However, although I keep writing to the UDP 52001 socket, I get nothing on the other socket (52002). My settings are described below.

Observations:
All I see is a 'U' in the debug output in GNU Radio terminal for every character I send to UDP socket 52001 through my client. I also see the LED light B blinking for every character I send through UDP client.

My netcat terminals if required are below,

I would so much grateful if someone can help me rectify this error.

Support additional spreading factors and code rates

At this time gr-lora supports only SF8 and CR4/8. It should be extended to support code rates 4/[5:8] and arbitrary spreading factors.

Improve the whitening sequence

The whitening sequence implemented in gr-lora was experimentally derived by @matt-knight during the course of his initial blind signal analysis. While it has been adjusted over time, it is still riddled with errors. Additionally, the portion of the whitening sequence that applies to the PHY header (first 8 octets of the sequence, or 8 symbols at 4/8) is not correct due to limitations of the Microchip RN2903 being used to deduce the sequence. Thus, the whitening sequence should be:

• Updated for accuracy
• Extended to cover the first 8 symbols/PHY header

examples give me ```ImportError: No module named lora```

When I try to run the given gnuradio examples, they return:

ImportError: No module named lora

The whole project was installed as described in the README.

Adding Encrypt/Decrypt LoRa

inf thanks for this great research and thanks for your great talk! researching undocumented de-chirp, unwhite etc. may sound (to most people) far more easy then it is in RF land.

have you planned to include LoRA encrypt and decrypt functionality or would you be happy to get a pull request with that :) ? (like https://github.com/jieter/python-lora).

Gtk-Warning: attempt to allocate widget with width -5 and height 20.

I run lora_receive_file.py for test decoding and getting an "Gtk-Warning: attempt to allocate widget with width -5 and height 20".
I tried decoding my lora and got infinitely symbol "O"(OOOOOOOOOOOO...).
How to fix my problem?

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

I'm not quite sure if this is really an issue, but I tried to use the lora-samples from rpp0 with this repository. I modified rx_ursp.grc to:

After executing the project, I'm getting the error message:

Executing: /usr/bin/python2 -u /home/user/gr-lora/examples/top_block.py

16:28:21: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8).
Traceback (most recent call last):
  File "/home/user/gr-lora/examples/top_block.py", line 236, in <module>
    main()
  File "/home/user/gr-lora/examples/top_block.py", line 230, in main
    tb = top_block_cls()
  File "/home/user/gr-lora/examples/top_block.py", line 133, in __init__
    self.lora_demod_0 = lora.demod(spreading_factor, ldr, 25.0, 2)
AttributeError: 'module' object has no attribute 'demod'

The path /usr/local/lib/python2.7/site-packages/lora/ is in my $PYTHONPATH variable.
Is it possible, to use this repo without a lora-device?

decoded payload ok with SF8, but nibbles get shuffled with SF7 or SF9

I was testing to decode some messages sent from my Inair9 LoRa transceiver.
Communication between two of my hardware LoRa modules is working well, but using constant payload on TX side gives different decoded messages with gr-lora when changing the SF settings.

Settings used for TX module and gr-lora:
Implicit Header
BW 125kHz
Hamming 8,4 aka 4 Parity Bits
low datarate opt
payload CRC OFF
Preamble length 8
869.3 MHz

On RX side I used the provided example flowgraph "rx_usrp.grc" but USRP Source was replaced with RTL-SDR Source using 1e6 sample rate. Distance TX to RX was about 2 metres.

Using SF7, SF8 and SF9 the same payload of 7 bytes was sent out several times with the Inair9 module:
TX (hex): "12, 34, 56, 78, 9a, bc, de"

gr-lora gives reliably these outputs:
RX SF7: "24, 16, 35, 78, 9a, ce, bc, d0,"
RX SF8: "12, 34, 56, 78, 9a, bc, de"
RX SF9: "24, 16, 38, 57, 9a, bc, de"

Decoding works like a charm with SF8.
The bold marked data is correct and sitting at the right place inside the sequence.

When using SF7 or SF9 something strange is happening with the arrangement of the original half-bytes.
It looks like the decoding process places the correct half-bytes into wrong order.
(with one exeption: the leading 7 bytes are missing a "d" nibble at SF7 ... but there is a suspect "d" nearby inside the 8th decoded byte )

I uploaded the GRC flowgraph (used for playback/capture and live reception) to my gdrive together with recorded samples at SF7, SF8, SF9.
https://drive.google.com/drive/folders/0B_V_Uy5rS1foY21qRWtNY2FhZHM

Are there similar observations of other users?
Might something be wrong with my setup?

AttributeError when running examples/txrx_sim.grc

When running examples/txrx_sim.grc, I get

File "/gr-lora/examples/top_block.py", line 89, in main
    tb = top_block_cls()
  File "/gr-lora/examples/top_block.py", line 35, in __init__
    self.lora_mod_0 = lora.mod(spreading_factor, 0x12)
AttributeError: 'module' object has no attribute 'mod'

Seems like unlike in #7, the module is found but it does not contain the mod function. Could this be an issue with swig? I'm running on Debian Stretch.

Error on tx_usrp example

Hi I'm trying to use gr-lora with an USRP N210, but when I run the tx_usrp. I'm always receiving this error message:

Warning: failed to XInitThreads()
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock

Could anyone please help me?

PHY header support

The optional PHY header should be deduced and implemented. #2 is a blocking item.

Source - out(0): Port is not connected.

i'm a noob in using GNU radio.

I've some red blocks:

• pfb_arb_resampler
• 2x Missing block key lorademod

It said: Source - out(0):

Trying to connect an rtl2832 (dvb-t) stick to it. Any solutions?

Thanks for the cool work

Investigate alternative demodulation strategies

While the synchronized FFT strategy works, there may be more accurate and/or computationally efficient means of demodulating LoRa than the one implemented here.

Error in the modulator block

Issue with Decoding!!

Hello Matt(@matt-knight ),

Hope you are doing fine due to this pandemic. I was trying to do my Bachelor's Engineering Thesis on LoRa communication with GnuRadio and I found your project gr-lora really useful for it. But somehow I am experiencing some problem with Demodulation and Decoding blocks.

I am using LimeSDR (Chipset - LMS7002M) as the hardware, and gnuradio version 3.7. While demodulating and decoding, I am receiving different values than transmitted values, but I have seen in your video on youtube, that you could receive everything perfectly.

So I am now getting surprised about my setup and all, if I made some mistakes or not. I am using the LoRa standard of Europe now as I am from Poland. Hence, if you please guide me a little bit through it, I will be really grateful to you. Thank you in advance!! Smile

With Warm Regards

--
Ritankar Sahu

Student of B.Sc [Macro]

DEPARTMENT OF AUTOMATICS, ELECTRONICS AND COMPUTER SCIENCE
SILESIAN UNIVERSITY OF TECHNOLOGY

gr-lora decode faild

Hi @matt-knight I've been reading your ppt from
https://static1.squarespace.com/static/54cecce7e4b054df1848b5f9/t/57489e6e07eaa0105215dc6c/1464376943218/Reversing-Lora-Knight.pdf
It really cool！

But when i used gr-lora rx_usrp.grc to decode lora data ,nothing print on the nc console.

data samplefile：https://drive.google.com/file/d/1FniqHAiDO5owvK8XuVo5ErkYIP5PJ5QJ/view?usp=sharing

frequency：492.25e6
bandwith:125k
spreading_factor:11
code_rate:5

https://drive.google.com/open?id=1bmpmJA8X696Y5VAR5n06CxXcVwm0s0zQ

and the code_rate only 5-8(maybe) , it not 4?

Look forward to your reply,thanks!

Deinterleaved codewords incorrect order

Hi,

Thank you for your 2016 paper and presentation.

I am trying to experiment with the {de}interleaver from your repository, and have simply copied the relevant functions into a single file. When I try to hamming encode, interleave, deinterleave, and hamming decode a payload, the order of the deinterleaved codewords is incorrect. (Using SF8, any coding rate)

For example, {0xA, 0xB, 0xC, 0xD, 0xE, 0xF, 0x1, 0x5} becomes {0x1, 0xB, 0xE, 0x5, 0xC, 0xF, 0xA, 0xD}. The correct bytes are all there, but they are in the wrong order.

If I change the deinterleave function for the SF8 case so that the order elements are inserted into codewords matches the SF8 case in interleave (0,7,2,1,4,3,6,5) I get the output I expect.

if (ppm == 8)
{
    codewords.push_back(block[0]);
    codewords.push_back(block[7]);
    codewords.push_back(block[2]);
    codewords.push_back(block[1]);
    codewords.push_back(block[4]);
    codewords.push_back(block[3]);
    codewords.push_back(block[6]);
    codewords.push_back(block[5]);
}

I think this is a bug, but I'm not sure whether interleave is incorrect, deinterleave is incorrect, or maybe even both.

The code: gr-lora.cc.txt

tr_usrp.grc not transmitting via usrp

i tried to transmit LoRa signal by running tr_usrp using USRP B200, but nothing is transmitted. red light LED is OFF only.

low data rate opt set to 0 will not work

Hi, I have decode with sf=8,low data rate = 1,BW = 62.5k, and implicit head mode. but when I change the low data rate to 0, the program can't work right, then I use Whitening sequence derivation function, I find that the whitening sequence changes every time from the 9th bit, but when I change the low data rate to 1, the whitening sequence doesn't change. do you know this is why, and how to deal with it, Thanks

UDP stream

Hello, I'm trying to recieve data over the udp stream, but when I start up netcat I get nothing, using the rx_usrp example on port 52002 @ 127.0.0.1

$~ nc -l -u 52002

I am recieving/Viewing lora in a waterfal sink, and FFT sink. Also if someone could link a good resource to learn about gnucompanion/how to record the chirps. not able to zoom in enough on the waterfall sink.

Failure to decode messages from Multitech xDot

I'm experimenting with gr-lora, trying to decode messages sent by a Multitech xDot (915MHz).

So far I am able to receive PDUs but the payload is incorrect.

The example is the peer_to_peer_example.c from these examples.

I zeroed the application and network keys, and also the payload, which is just { 0x00, 0x00 }.

I do not know if the xDot library sends an explicit header or not. I could not find that information. If that is the case, I understand the decoder will not be able to decode the messages.

Can someone confirm if this is what happens by inspecting the receiver output pasted below?

* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd a6 cc c3 4f 32 3f 30 0a 10 
0010: 16 2d f5 38 25 14 3b 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd 97 dc c3 4f 32 1d 84 3a 49 
0010: a4 00 8b 36 a3 18 3b 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd 86 cc c3 4f 53 39 51 c9 5b 
0010: 1f c7 66 06 a3 18 3b 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd b7 d8 c3 4f 63 6b 4b 93 61 
0010: 7b 9a f6 24 a1 18 3b 
***********************************

Thanks!