0
$\begingroup$

I am trying to make two USRP communicate between each other : for the transmission, I'm using an HackRF One USRP and for the reception a NI 2921 USRP. As a first test, I'm trying to send different basic signals like sine waves, square waves, triangle waves,... with the HackRF One and receive it with the NI 2921 USRP at a carrier frequency of 2.43GHz.

  1. Here is the block diagram for transmission, the time signal and FFT plot :

    block diagram FFT + time signal

    I'm sending the signal at 2.43GHz with a sample rate of 200kHz. Here the signal sent is a composition of a real component which is a square wave at 15kHz and an imaginary component which is a cosine wave at 10kHz.

  2. Here is the block diagram for reception, the time signal and FFT plot (once when I am not sending any signal and once when I am transmitting the composition of signals described above, such that we can see that the peak detected is well due to my emission) :

    Reception block diagram FFT + time signal FFT + time signal with peak

    I'm sampling at 200kHz and my center frequency is at 2.43GHz.

Whatever the signal I'm sending (a DC signal, a sine wave, a triangle wave,...), I always get the same peak (and only one) like the one on the picture. Normally, I should receive the same FFT as the one showed at emission on the picture. I notice also that this peak is located at a weird position (2.43GHz + 46kHz) compared to the center frequency (2.43GHz) with no link with the frequency of the signals sent. Moreover whatever the frequency of the signal emitted, the peak will always be located at this same position as well. I seems like they manage to communicate between each other given that there is this peak appearing when I am transmitting the signals but I do not understand the logic behind the spectrum received..

Can somebody enlighten me?

EDIT further to @MBaz answer:

  • I tried both osmocom and UHD at the reception of the signal to see if there was a difference but there is not. I will use UHD again.
  • I have just used GQRX as a spectrum analyzer to do some tests. Sending a sine wave at 10kHz gave me peaks at frequencies shifted of 50kHz on the FFT (if I send a signal at 2,429720GHz, the received signal showed a peak at 2,429770GHz on the FFT with GQRX). I am then sure the received peaks are due to the emission of signals with the HackRF One.
  • Changing the sine frequency from 10kHz to 20kHz does not change the location of the peak.
  • Trying to send two sine waves (10kHz and 20kHz) showed me one and only one peak at the same frequency location as before.
  • Changing the type of signal sent (triangle, square wave, sine wave) does not change the FFT of the signal received.
  • All the previous tests have showed the same results on gqrx and GNURadio Companion.
  • As you can see on the plot of the evolution of the signal in function of the time, this is a quite unusual low amplitude signal received.
  • No error is shown on the console of the NI 2921 receiver. On the emitting signal console, I have this output :

Warning: failed to XInitThreads() linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.11 built-in sink types: uhd hackrf bladerf soapy redpitaya freesrp file Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock Using HackRF One with firmware 2018.01.1

$\endgroup$
2
  • $\begingroup$ Welcome! As you probably saw by now, I edited your question to embed the images. Please make sure to always use Stack Exchange's image uploader, not any other service, so that images essential to a question do not disappear later. Also, screenshots are much more readable (and smaller and easier to upload) than photos. Both embedded and clearer images will help your questions get answers by making it more convenient for the answerer to understand what you're asking. $\endgroup$
    – Kevin Reid
    May 30, 2019 at 14:19
  • $\begingroup$ @KevinReid Thank you for your advice and remarks, you're right! I will pay attention to these points next time I post something. $\endgroup$
    – Dylan
    May 30, 2019 at 15:38

1 Answer 1

2
$\begingroup$

A few (hopefully useful) comments and ideas:

  • The HackRF One is not a USRP.
  • If you're receiving with an NI 2921 USRP, you should be using UHD to interface with it, not osmocom.
  • Use a standalone spectrum analyzer, first to double-check that nobody else is transmiting at that frequency, and then to study your transmitted signal.
  • Transmit a single sine wave and verify that both the spectrum analyzer and the USRP can see it. Verify that you're transmitting it with enough power.
  • If that works, try with two sine waves separated by a few kHz.
  • It is normal that the received signals are at a slightly wrong frequency. Each device has its own idea of what 1 Hz is; this is why receivers need to run a carrier synchronization algorithm.
  • Your devices may not support a sampling frequency of exactly 200 kHz and may be using the closest available frequency. Check any warnings on the console. This may result in impaired performance.
  • In general, pay attention to any output on the console: you may be overrunning or underrunning your flowgraphs, or something else may be wrong.
$\endgroup$
5
  • $\begingroup$ Thank you for your answer! I have just added an EDIT in my question further to your answer. $\endgroup$
    – Dylan
    May 30, 2019 at 9:54
  • $\begingroup$ Thanks for the additional info. You need to get those "Cannot connect" errors figured out. I'd recommend going to the UHD and GnuRadio mailing lists. If those are not the problem, then I'd say at least one of your radios is defective. $\endgroup$
    – MBaz
    May 30, 2019 at 13:30
  • $\begingroup$ The only answer received is that it must be "an issue with the HackRF One, not the NI USRP; could be configuring it, or some runtime issue; really not clear". The thing is that when I use the HackRF One on Windows instead of Ubuntu, I don't have any error message but the results are the same. I wonder if it is not a signal processing problem in my blocks? Unfortunately I do not find a simple project of communication between 2 usrp to check if they work correctly on the internet... $\endgroup$
    – Dylan
    Jun 2, 2019 at 14:06
  • $\begingroup$ The problem was a too low sampling frequency at the HackRF One as you predicted. The console does not warn about it : no error message but it was well that problem, thank you! $\endgroup$
    – Dylan
    Jun 3, 2019 at 13:45
  • $\begingroup$ You're welcome, good to hear you figured it out! $\endgroup$
    – MBaz
    Jun 3, 2019 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.