[Hackrf-dev] sweep capabilities

[Michael Ossmann]

What can I expect exactly from a performance point of view? I've read
"sweep rate of 8 GHz per second" so does that mean that to scan
100MHz, it'll take 100M/8G=1/80s to scan? It should depend on the
capture time and tuning time, but maybe it's taken into account in the
8GHz/s?

That is correct. You'll get 80 sweeps per second across 100 MHz. (In a test I
just ran for verification, I had 81.37 sweeps per second.)

What kind of computer does one need to run something like hackrf_sweep
than returns the FFT, with a resolution of 100kHz ie 10 bins per MHz?

With 100 kHz bin width, my test used 20% of one core of this CPU:

model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
bogomips : 5427.48

Bin width is the main thing that affects CPU utilization.

Michael

[RizThon]

Thanks for the detailed info Michael.

Reading https://github.com/mossmann/hackrf/blob/master/host/hackrf-tools/src/hackrf_sweep.c
I see that the minimum number of samples per frequency is 8192. Would
it be possible to lower it to get, I suppose, shorter capture times?

I'm interested in signals in the ISM 2.4GHz band that may be short.
Even if I reduce the band to 80MHz, 1/100s may still be too slow.
Having a sweep taking 1/300s to 1/200s might be enough.

Post by Michael Ossmann

What can I expect exactly from a performance point of view? I've read
"sweep rate of 8 GHz per second" so does that mean that to scan
100MHz, it'll take 100M/8G=1/80s to scan? It should depend on the
capture time and tuning time, but maybe it's taken into account in the
8GHz/s?

That is correct. You'll get 80 sweeps per second across 100 MHz. (In a test I
just ran for verification, I had 81.37 sweeps per second.)

What kind of computer does one need to run something like hackrf_sweep
than returns the FFT, with a resolution of 100kHz ie 10 bins per MHz?

bogomips : 5427.48
Bin width is the main thing that affects CPU utilization.
Michael

[Michael Ossmann]

I see that the minimum number of samples per frequency is 8192. Would it be
possible to lower it to get, I suppose, shorter capture times?

Theoretically, yes, but there is a quite a lot of firmware work that would have
to be done in order to accomplish that, and I'm sure there would be diminishing
returns as more work is done.

Mike