rpp0 / gr-lora

GNU Radio blocks for receiving LoRa modulated radio messages using SDR
GNU General Public License v3.0
537 stars 115 forks source link

Message not displayed #34

Closed 97aditi closed 7 years ago

97aditi commented 7 years ago

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.

rpp0 commented 7 years ago

Hi! Could you upload the files somewhere? I will take a look at the problem.

On Jun 13, 2017 22:03, "97aditi" notifications@github.com wrote:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rpp0/gr-lora/issues/34, or mute the thread https://github.com/notifications/unsubscribe-auth/AH4HCMjF5b9NuQiZKbZsUxc5pQZcXi1eks5sDusXgaJpZM4N5Awm .

97aditi commented 7 years ago

I have attached the file contaning the samples and the screenshot of the flowchart and output as well.

lora.cfile.tar.gz screenshot from 2017-06-13 15-17-43

rpp0 commented 7 years ago

Hi, the problem is probably that the sample trace contains an incomplete LoRa packet. As can be seen from the screenshot, only part of the preamble is captured:

image

97aditi commented 7 years ago

I am totally at a loss here, some signals do get decoded while others do not. I have attached a file as well as the spectrogram of the same here, it is not getting decoded. The spectrogram looks correct. Any help will really be appreciated.

lora3.cfile.tar.gz lora3

rpp0 commented 7 years ago

I've tested the lora3.cfile and it seems to work for me. From the spectogram you can see that it is transmitted at 867.9 MHz with SF12, so you need the following settings for the LoRa receiver: image The resulting output I get is: Bits per symbol: 60 Bins per symbol: 4096 Header bins per symbol: 1024 Samples per symbol: 32768 Decimation: 8 e0 0b 03 40 78 46 05 74 16 10 04 10 5f 4f 80 8d 7f e0 0b 03 40 78 46 05 74 16 10 04 10 5f 4f 80 8d 7f e0 0b 03 40 78 46 05 74 16 10 04 10 5f 4f 80 8d 7f e0 0b 03 40 78 46 05 74 16 10 04 10 5f 4f 80 8d 7f e0 0b 03 40 78 46 05 74 16 10 04 10 5f 4f 80 8d 7f e0 0b 03 40 78 46 05 74 16 10 04 10 5f 4f 80 8d 7f

It should be noted however, that the decoding accuracy of SF 12 is low due to clock drift between the chipsets and the SDR (so the decoded data may be wrong). I'm currently working on this issue, but it proves to be a difficult one to solve.

97aditi commented 7 years ago

Thank you. This works but the decoded data doesn't seem to be right for even lower spreading factors when I transmit using Microchip LoRa Mote(RN 2483).

rpp0 commented 7 years ago

That shouldn't happen for lower spreading factors. If you could provide me with your samples transmitted at SF 7 and the expected payload, I can take a look at why the decoder fails.

Just to be sure: did you disable encryption on the device?

97aditi commented 7 years ago

No, I haven't disabled encryption. This is at sf9 and the desired payload is 12345 in ASCII. https://drive.google.com/file/d/0B2WC2ahm7Pl0dlJwbzFsNjFZeTQ/view?usp=sharing

rpp0 commented 7 years ago

Thanks for sending the file! Since gr-lora only implements the PHY layer, you will have to decrypt the data manually with your key after receiving in order to show the ASCII payload. Perhaps at some point in the future, I could add support for the MAC layer as well.

97aditi commented 7 years ago

Okay, thank you. So, basically it should work when encryption is disabled?

rpp0 commented 7 years ago

Yes, it should. You can use the 'radio tx' command to send without encryption.

On Jun 22, 2017 11:10 PM, "97aditi" notifications@github.com wrote:

Okay, thank you. So, basically it should work when encryption is disabled?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/rpp0/gr-lora/issues/34#issuecomment-310503696, or mute the thread https://github.com/notifications/unsubscribe-auth/AH4HCJV8K8tFkTvRHMvyNYn3p0N1kLUMks5sGthVgaJpZM4N5Awm .

97aditi commented 7 years ago

Thank you!

dimka-rs commented 7 years ago

Hello. I have same problem - I see signal on FFT, bot nothing is decoded. Tried to set receiver just like you posted on Jun 21, but it does not help. Source is RTL-SDR.

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp miri hackrf bladerf rfspace airspy soapy redpitaya 
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Bits per symbol:    60
Bins per symbol:    4096
Header bins per symbol: 1024
Samples per symbol:     32768
Decimation:         8
[nothing more]

Has PLL not locked something to do with it? I've also tried file lora3 by 97aditi and got same result - FFT, but no data. Where should I start?

rpp0 commented 7 years ago

Hi! Could you post a screenshot of your grc? And at which frequency does your LoRa transmitter send data?

dimka-rs commented 7 years ago

Sending at 868.1M SF12. Tried SF7, no luck either. 8681-sf12

Executing: /usr/bin/python -u /home/dimka/repos/gr-lora/apps/lora_receive_realtime.py

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp miri hackrf bladerf rfspace airspy soapy redpitaya 
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Bits per symbol:    60
Bins per symbol:    4096
Header bins per symbol: 1024
Samples per symbol:     32768
Decimation:         8

>>> Done
rpp0 commented 7 years ago

Your node appears to be sending at 868 MHz instead of 868.1 MHz. So the LoRa block should have as Channel List: [868e6]. I recommend testing at SF7 because the higher the SF, the worse the clock drift will be, resulting in damaged packets.

dimka-rs commented 7 years ago

I've played with freq and SF but it changed nothing. So I decided to start with gr-lora-samples and check just decoder. It fails. FFT shows up for a second then disappears. Here is log:

Executing: /usr/bin/python -u /home/dimka/repos/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

>>> Done (return code -11)

Sometimes there is (return code -11), sometimes not. Just default flow and samples from zip. I've tried almost all files with the same result. What could be wrong? fail

rpp0 commented 7 years ago

Could you try to update to the latest version? After that, first run the program and then please send me the file /tmp/grlora_debug_txt.

dimka-rs commented 7 years ago

First, I've once manged to get this with new version and grlora_analyze.py not running, though I cannot repeat it...

Bits per symbol:    35
Bins per symbol:    128
Header bins per symbol: 32
Samples per symbol:     1024
Decimation:         8
 71 11 0b 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22
 71 11 0b 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88
 71 11 0b 12 12 12 12 12 12 12 72 12 12 12 12 12 12 12 12 12 12 13 12 12 12 12
 71 11 0b 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22

Second, here is /tmp/grlora_debug_txt

Cu: 0.995059
Cd: -0.995059
Cd: -0.995393
Cd: -0.995133
Cd: -0.995135
Cd: -0.995772
Cd: -0.995575
Cd: -0.0825872
Cd: 0.115656
Cd: 0.99659
SYNC: 0.99659
11111 21

And third. Here is why FFT stops:

$ ./apps/lora_receive_file.py
Bits per symbol:    35
Bins per symbol:    128
Header bins per symbol: 32
Samples per symbol:     1024
Decimation:         8
Segmentation fault (core dumped)

Here is strace tail

clock_gettime(CLOCK_MONOTONIC, {434478, 273337424}) = 0
clock_gettime(CLOCK_MONOTONIC, {434478, 273363325}) = 0
clock_gettime(CLOCK_MONOTONIC, {434478, 273389225}) = 0
clock_gettime(CLOCK_MONOTONIC, {434478, 273414955}) = 0
sched_yield()                           = 0
futex(0x5578af58ae80, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x5578ae27ab50, FUTEX_WAKE_PRIVATE, 1) = 1
recvmsg(3, 0x7ffebf9ca2d0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=9, events=POLLIN}], 3, 14667 <unfinished ...>
+++ killed by SIGSEGV (core dumped) +++

Full strace attached lora.zip