Closed 97aditi closed 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 .
I have attached the file contaning the samples and the screenshot of the flowchart and output as well.
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:
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.
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: 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.
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).
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?
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
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.
Okay, thank you. So, basically it should work when encryption is disabled?
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 .
Thank you!
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?
Hi! Could you post a screenshot of your grc? And at which frequency does your LoRa transmitter send data?
Sending at 868.1M SF12. Tried SF7, no luck either.
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
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.
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?
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
.
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
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.