search

tapparelj / gr-lora_sdr

This is the fully-functional GNU Radio software-defined radio (SDR) implementation of a LoRa transceiver with all the necessary receiver components to operate correctly even at very low SNRs. This work has been conducted at the Telecommunication Circuits Laboratory, EPFL.
https://www.epfl.ch/labs/tcl/
GNU General Public License v3.0
671 stars 70 forks source link

frequency variation and SF11/12 #100

Closed lGL00 closed 3 weeks ago

lGL00 commented 3 months ago

Hello,

I am currently playing with your module and i found something a bit strange for me.

I am using a semtech sx1272 (and its associated software) as a transmitter for LoRa, connected through SMA cables to a -100dB attenuator, and the "RX" port of a LimeSDR miniV2.2 that is connected to my pc with gnuradio. the Mini module is acting as receptor for LoRa frames.

As for gnuradio, i am using a soapy LimeSDR source directly connected to the LoRa RX bloc available from your module

Screenshot from 2024-07-15 17-18-26

I already used it for a couple weeks, and i just found that the sensibility of the frequency shifting isn't as i expected :

I tried sending frames to different spreading factors and bandwith with different frequencies (exemple : for a center frequency of 868MHz, sending 868.01MHz), and i found that for almost every combination of SF and BW, the limit before not receiving correctly the message was around +-21kHz for 125kHz BW and +- 42kHz for 250kHz and 500kHz BW, except for the SF 11 and 12 which are much more sensitive and would show errors for much closer frequencies.

I saw with semtech receivers and transmitters that i could go up to +-31kHz from the center frequency without much problems.

I also tried sending using the Mini V2 to check if it was from it but no problem here.

Do you have any idea from where this could be from?

Thanks in advance.

tapparelj commented 2 months ago

Hello @lGL00, Sorry for the delay. The method used to estimate the carrier frequency offset (CFO), is limited to +- 0.25 BW. When simulating both the CFO and sampling frequency offset (SFO), I can go up to the limit (at least with high SNR (-5dB)) for both SF 7 and 12. In our implementation, the estimation of SFO and CFO are linked as we assume they both come from the same mismatch of oscillator frequency. Therefore, if you only change the CFO by setting the center frequency with an offset, our receiver will try to compensate a SFO that does not exist and worsen the demodulation. Since the SFO accumulate for each sample, a wrong compensation is more detrimental the more samples there are in the frame (i.e. the larger the SF). As the Semtech chip can deal with the center frequency shift, I would think that they use a SFO estimation method independent of the CFO.

Let me know if that makes sense to you or if you think that it may come from somewhere else.

lGL00 commented 1 month ago

Hello @tapparelj, It does look like this is the source of my problem, when looking at the frame sync block Thanks for your reply, this helped me a lot.

tapparelj commented 3 weeks ago

As it seems that it solved your problem, I'll close this issue. Don't hesitate to reopen it if needed.