search

glv2 / ofdm-transfer

Send or receive data by SDR using OFDM modulation
GNU General Public License v3.0
22 stars 6 forks source link

ofdm-transfer does not work on uBuntu 22.04 #1

Closed righthalfplane closed 1 year ago

righthalfplane commented 2 years ago

I tried ofdm-transfer on uBuntu 22.04 using a Hackrf One and a RTL stick and a SDRplay RSP2. I used your examples. The Hackrf One would transmit the file and stop, but on the receiving end the devices just timed out and left an empty file. Since I used your example with the same devices, I was hoping that it would work. The gnuradio-companion ofdm routine are very picky and only work with a small range of gains - are your routine picky or will they work with a large range of values ?

glv2 commented 2 years ago

One thing that can make the transfer fail is the frequency offset caused by not very accurate clocks. If the offset between the center frequencies of the sender and the receiver is bigger than 1% of the OFDM signal bandwidth, the receiver will probably not be able to decode the frames (see https://github.com/jgaeddert/liquid-dsp/issues/279). It can happen if the HackRF or RTLSDR don't have TCXOs (or an accurate external clock signal), or when doing a low bit rate transfer at a high frequency. The '-c' option of the program can be used to compensate such a frequency offset.

A DC spike from the SDR device inside the OFDM signal can also cause problems. The '-o' option can be used to move the DC spike away.

Concerning the gain settings, the transfer should work as soon as they are high enough (but not so high that the receiver gets overloaded). If I remember correctly, for the example in the README file with a gain of 30 for the HackRF and a gain of 20 for the RTLSDR, the distance between the devices was around 10m with a wooden wall in the middle.

righthalfplane commented 2 years ago

The RTL-SDR.com stick has a TCXO so frequency there should not be a problem. The Hackrf One frequency control is not so good - at the higher frequencies the decode frequency often needs to be shifted for SSB to decode correctly. I give my BladeRF a try.

righthalfplane commented 2 years ago

I tried playing with the gain and one time got the message "Frame 1 for '' : corrupted payload" and it had transferred about five lines of the file, but with identical setting and near by setting it happened only once. The BladeRF transmits the data, but does not exit (I waited several minutes) the program until I give it a cntl-c.

righthalfplane commented 2 years ago

I move to the Macintosh and tried many combinations with the HackRF One, BladeRF, RTL-Stick and SDRplay RSP2. One time it transferred the same 5 lines that I got before.

When I started six years ago using the SoapySDR library, I used the C routines, but during the development of SdrGlut - I ran into problems with the C routines and I had to shift to using the C++ routines - perhaps you are hitting one of the bugs in the C routines.

glv2 commented 2 years ago

What kind of problems did you have with the C version of SoapySDR functions?

I just tested a transfer between two HackRF One devices (with 0.5 ppm TCXOs), and it worked fine. Receiver:

ofdm-transfer -r driver=hackrf,serial=12345678 -s 8000000 -f 434000000 -o 100000 -b 9600 -g "LNA=32,VGA=20" -T 10 output.dat

Transmitter:

ofdm-transfer -t -r driver=hackrf,serial=87654321 -s 8000000 -f 434000000 -o 100000 -b 9600 -g 30 -w 1 input.dat