2
$\begingroup$

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

Improve this question
$\endgroup$
8
  • 1
    $\begingroup$ "Throttle": never use together with hardware sinks and sources! Your GRC actually warns you about specifically that! wiki.gnuradio.org/index.php?title=Sample_Rate_Tutorial (search for throttle) $\endgroup$
    – Marcus Müller
    Jun 21 at 14:23
  • 1
    $\begingroup$ 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! $\endgroup$
    – Marcus Müller
    Jun 21 at 14:23
  • 1
    $\begingroup$ 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. $\endgroup$
    – Marcus Müller
    Jun 21 at 14:27
  • 1
    $\begingroup$ 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 :) $\endgroup$
    – Marcus Müller
    Jun 21 at 14:29
  • 1
    $\begingroup$ 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. $\endgroup$
    – Marcus Müller
    Jun 22 at 16:25

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .