2

I have recently had access to two SDRs a hackrf and a Plutosdr through my university.I am now trying to experiment and learn more about wireless communications and how to implement some examples on an SDR.

I have tried to implement a simple DVB-T loopback using the examples provided with gnuradio. the initial simulation without the sdrs work fine as expected but adding the sdrs to the equation ruins everything. I have tried to do this first using the plutosdr only as its full duplex however it still wouldn't work well so I would guess that my problem is not related to the LO mismatch between the two sdrs. plus, I would like to believe that channel equalization is not the issue as I have tried directly connecting the plutosdr to the hackrf with a sma cable.

I have attached a screenshot of the received spectrum by the hackrf and the flow graph I have used. Thus, I would really appreciate any help in troubleshooting this.

AND any resources that can help me learn more about Gnuradio and SDRs in general are welcome. gnuradio DVB-T flowgraph

received power by hackrf

Mike Waters
  • 7,843
  • 4
  • 16
  • 50
instantrame
  • 21
  • 1
  • 1
    "Throttle": never use together with hardware sinks and sources! Your GRC actually warns you about specifically that! https://wiki.gnuradio.org/index.php?title=Sample_Rate_Tutorial (search for throttle) – Marcus Müller Jun 21 '22 at 14:23
  • 1
    This might fail for several reasons: 1. I'm not sure both your hardware devices actually support the sample rate you set. I think it's unlikely the HackRF supports the rate. So you get a different signal than you think - read your console output closely! – Marcus Müller Jun 21 '22 at 14:23
  • 1
    2. in the simulation, you needn't achieve the 9.somehting Megasamples as *constantly processed* throughput – it still works, because DSP cares about the values of the samples, not how fast they come in. However, with hardware, you *must* send in the sample rate into the pluto sink, and must process the sample rate coming from the hackrf, or else there would be buffer overruns and underruns, respectively. – Marcus Müller Jun 21 '22 at 14:27
  • 1
    3. Over the air, there's noise, nonlinear distortion, clock offsets, and other imperfections. (This makes receiving usually harder than transmitting correctly ;) ) Just because it did work in simulation without these doesn't imply it works in reality from the start :) – Marcus Müller Jun 21 '22 at 14:29
  • Dear Mr. Marcus Müller, Thanks for your very helpful pointers. I believe that both sdrs are capable of sampling at the set sample frequency. However, what you stated about the clock offset is something I have faced while trying to get other modulation schemes such as QPSK and ASK to work. I was able to transfer simple text files but when it comes to large files I always end up with corrupted data at the RX side. further, Is the poor non-linear performance because I could be saturating either the tx or the rx side? – instantrame Jun 22 '22 at 16:14
  • I am a noob at gnuradio and programming in general but I would like to pick this up as a hobby. From your experience, what would be the best way of learning how to use gnuradio properly? – instantrame Jun 22 '22 at 16:19
  • 1
    your spectra look fine, so the nonlinearity is probably not to blame. drift and insufficiently exact timing and frequency synchronization is more likely problematic, and of course noise, unless you're doing adequate forward error correction. – Marcus Müller Jun 22 '22 at 16:25
  • thanks for your help. – instantrame Jun 22 '22 at 16:38

0 Answers0