0
$\begingroup$

I am transmitting a 1 kHz cosine wave with a HackRF One. I receive it with a NI2921 USRP at a sample rate of 200kHz. All the process is on GNURadio Companion.

I changed the sample rate at emission to see the impact. I started at 200kHz and lowered of 1kHz each time. The sample rate at reception stays the same : 200kHz. Here are the results :

Results

From 200kHz to 96kHz, nothing appeared. Then, at a sample rate of 95kHz at emission, the cosine spectrum showed two peaks at 13kHz and 87kHz, centered on 50kHz (DC component) giving a cosine of frequency 37kHz. All the frequencies on the table above are the only ones showing something on the FFT of the received signal.

My questions are :

  1. Why does the sample rate at emission impact the frequency seen at the receiver?
  2. Why are there frequencies that do not make the cosine spectrum appear? (Only the frequencies present in the table work). For example, if I have the two same sample rates at emission and reception (200kHz for our example), it does not work.
  3. Why are the frequencies seen on the FFT plot different from 1kHz, the real cosine frequency emitted with the HackRF One?
Improve this question
$\endgroup$
4
  • $\begingroup$ You seem to be using sample rates that aren't supported by the hardware. The hardware uses a different sampling rate. UHD will tell you that it used a different sampling rate. (MBaz' answer already highlighted that.( $\endgroup$
    – Marcus Müller
    Commented Jun 3, 2019 at 10:19
  • $\begingroup$ Indeed, I had an error message when I was sampling at a rate below 200kHz before and that is why I chose 200kHz as a sample rate for reception. I have not had any error message since (at the emission as well, no error message) $\endgroup$
    – Dylan
    Commented Jun 3, 2019 at 10:37
  • $\begingroup$ are you sure the HackRF supports the sample rates? It might simply not be warning you that it doesn't! $\endgroup$
    – Marcus Müller
    Commented Jun 3, 2019 at 10:39
  • $\begingroup$ The HackRF One does not show any error, indeed.. And you are right, it was the sampling rate at the HackRF which was too low. Thank you! $\endgroup$
    – Dylan
    Commented Jun 3, 2019 at 13:43

1 Answer 1

Reset to default
1
$\begingroup$

The HackRF doesn't support those sampling rates. From reading the firmware over reading libhackrf to reading the gr-osmocom hackrf_sink_c:

The set of supported sample rates is very limited:

osmosdr::meta_range_t hackrf_sink_c::get_sample_rates()
{
  osmosdr::meta_range_t range;

  /* we only add integer rates here because of better phase noise performance.
   * the user is allowed to request arbitrary (fractional) rates within these
   * boundaries. */

  range += osmosdr::range_t( 8e6 );
  range += osmosdr::range_t( 10e6 );
  range += osmosdr::range_t( 12.5e6 );
  range += osmosdr::range_t( 16e6 );
  range += osmosdr::range_t( 20e6 ); /* confirmed to work on fast machines */

  return range;
}

So, use 8 MS/s.

The hackrf is instructed to use a different sampling rate than you think it uses, which obviously "scales" the spectrum.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I confirm, that's it! Thank you very much. $\endgroup$
    – Dylan
    Commented Jun 3, 2019 at 13:42
  • $\begingroup$ I'll take an accepted answer as form of thank – not because I'm really after the imaginary internet reputation points, but because it marks the question as solved for others. $\endgroup$
    – Marcus Müller
    Commented Jun 3, 2019 at 16:06

Your Answer

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

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