Communication between two USRP : mismatched spectra between transmission and reception 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. 


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




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.
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) : 





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
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.