Lora_RX does not receive frame from Lora_TX about gr-lora_sdr HOT 13 CLOSED

Hello,
There probably is an issue with the configuration of the bandwidth and sampling rates, or another parameter.
Can you provide me a screenshot of your flowgraphs, or report the value of the different block parameters you set?

from gr-lora_sdr.

Thank you for your response.
On both (RX and TX) I have the same settings, as I show in the screenshots below.

What do you suggest?
Thank you!

from gr-lora_sdr.

I don't see anything obvious here.
To debug, can you use a spectrum analyzer to check that the transmitter is really sending something?
You can quickly setup a gui_sink after your USRP Source (maybe with a higher sampling rate 1MHz to see better the frames) to check that the receiving USRP also work.
Let me know if it behaves as expected or not.

from gr-lora_sdr.

I tried placing the GUI_SINK after the USRP Source in the LoRa receiver, as you propose. It seems not to receive signal as being less than 50 cm away the spectrum shows no more than -100 dBm received, which does not change when I stop the transmission. In addition, I modified in TX and RX the center frequency according to the band assigned in my country and with a bandwidth of 125 KHz, which also showed no change.

from gr-lora_sdr.

Just to be sure can you use the max hold option? But it seems the transmitter is not working properly. If you add the gui sink on the TX side, parallel to the usrp sink, do you see frames samples? You can set a trigger at 0.5 on a time gui sink for example.

from gr-lora_sdr.

Thank you very much.
I did as suggested and found that you do see the LoRa plot chirps in the time domain, as expected. I have doubts about the fact that when looking at the frequency components in the spectrum, the entire spectrum width (1 MHz) occupied by the frame is displayed, which is not consistent with the system bandwidth (125 kHz in my case). Changing the sampling rate of the GUI_SINK the output still occupies the whole observation window.

from gr-lora_sdr.

This is normal that the signal occupies the full bandwidth. While sampled, we deal with normalized frequencies, and the waveform uses a bandwidth of 1. This gets translated to an actual bandwidth in Hertz only when the sampling rate is fixed (e.g. the samples are output by the frontend of a radio with a defined sampling rate.)
Since the samples seem to be generated correctly, but the radio doesn't output anything, I would try to be sure that the USRP configuration is correct.
Can you provide the output of the command uhd_usrp_probe --args="addr=192.168.X.X"
In addition, if you create a simple flowgraph with a "signal source" and the USRP sink, does your USRP output anything?

from gr-lora_sdr.

Thanks for the explanation about the spectrum, sorry for my ignorance.
I also realized that suddenly something was wrong with the configuration of the USRP B200, so I tried to transmit a 2.436 GHz signal and I managed to detect the signal in the receiver although at very low power for such a short distance (less than 20 cm). I attach the screenshots of the results. Before I could run lora-sdr I checked that the computers and gnuradio detected the USRPs, both with uhd_find_devices and uhd_usrp_probe.

I will keep checking and testing the USRP configuration in the LoRa-sdr, hopefully I can find the fault. Thank you very much for all your help.

from gr-lora_sdr.

Sorry, I forgot to attach screenshots of the uhd_find_devices and uhd_usrp_probe tests.
The B200 is connected by USB and not by ethernet that's why it has no IP assigned.

from gr-lora_sdr.

Hello!
I finally got to receive packets on the LoRa receiver, I had to adjust the channel gain (30dB) of the USRP and check that the other parameters are consistent with the rest of the lora_sdr code.
Thank you very much for all your guidance, as it was very helpful in managing to find the fault.
Attached are screenshots of the received frames.

from gr-lora_sdr.

Hello,
I'm glad to hear that! It is a bit surprising that the Tx gain needs to be as high but I don't know to what transmitt power it corresponds on a USRP B200.
Let me know if you face any other issues

from gr-lora_sdr.

Hi, this is Fengxu from Shanghaitech University. I followed your reverse work on LoRa two years ago. And I initially used B200 to reproduce but also have the same issues as this. Fortunately, I finally solved take two months. I think I can share some observations and suggestions about how to solve this issue.

1. Move to a more powerful platform. B200 has a very limited sample rate and is lower than other USRP productions in Ettus or NI. The Bxx serial is suited for beginners, but it does not work well for a lot of sequential execution, especially TX and RX are on one board. When I remove the encoding and decoding part, the symbol can be decoded successfully. So I think this is the hardware limitation. So I move to N210 or X310 platform with full-stack, and it works well.
2. Increase the sample rates or bandwidth of TX. 125k is not working but 250k or 500k is. From my experiment results with higher bandwidth, it sometimes transmits packets normally. But the packet reception rate is low than 30%.
3. Take a look at the USB interface and check if it is USB 3.0. 2.0 has lower datarate.

BTW, the packet with LDRO enabled has the CRC issues when tx to SX1276. I will open another issue to discuss it.

from gr-lora_sdr.

Hello @yangfengxu12,
I can't reproduce your issue with LDRO and CRC enabled. Can you provide more detail on the transmission parameters you use? (Indeed, opening in another issue would be better.)

from gr-lora_sdr.