[Hackrf-dev] HackRF_sweep

[Dominic Spill]

On 25 September 2017 at 16:04, Sebastiaan van Pelt <sebastiaanvanpelt at me.com>
wrote:
>
> To overcome the issue of the radio being stuck in transmit, every Python
file iteration is followed by running the hackrf_info to get the radio
ready for the next transmission. I am aware that some users have used
hackrf_spiflash -R but this didn't work for me as the resource was busy
every time this command was executed.

I'm currently working on trying to solve this, but knowing that hackrf_info
works when hackrf_spiflash -R doesn't is a useful data point.

> I'm now on to the stage (actually the first thing that needs to be
performed) where I want to scan or sweep a part of the spectrum to find
"white space" and have the transmitter use this found space to transmit a
file. To assure that the receiver is aware what frequency to listen on I
will implement a control channel via which I will send the found frequency
and switch accordingly. This is were it gets tricky:
>
> I'm currently scanning from 2.4 GHz to 2.42 GHz as I found that 20 MHz is
the minimum requirement and if set to less, hackrf_sweep will do this
anyway. I would like to scan the full ISM range from 2.4 to 2.5 GHz
dividing it in a 100 channels but realize this is quite a daunting task.

Is your plan to use sweep mode to find the quietest 1MHz channel of the
2.4GHz ISM band?

> Here are the actual problems I run into:
>
> 1. Can the default sampling rate of 20 MHz be adjusted using the
hackrf_sweep command? If I were to set this to lets say 5 MHz would the
sweep still be interleaved?

Theoretically this is possible, but we don't currently support it and it
would require some development time to change.  I'm not entirely sure I
follow why you'd like to do this, could you tell me what would be the
advantage to your use case if you could reduce the bandwidth?

> 2. What is the effect of the samples per seconds, and the multiples of
16384? How does changing this value affect the output in the CSV file? I
haven't got the maximum value here with me but for some reason this is not
a multiple of 16384, as stated when using hackrf_sweep -h.

This is the number of samples per frequency, not per second.  It's related
to the size of our USB buffers and is the dwell time between re-tuning in
terms of received buffers.

> 3. I need the CSV output to analyze where the white space is but but
because of the interleaving the data is spread out through the document.
Does anyone have some suggestions on how to either sort this data (I've
looked at the flattening.py file found on github but cannot get it to work)
or suggest a way that hackrf_sweep can output the sweep in a more
convenient way. I understand what dB columns correspond to what frequency
but find it hard to implement this in a script with my very limited python
knowledge.

My recommendation would be to use `hackrf_sweep -1 -f2400:2500` and when
you read the values in use the python CSV module to parse them.  The first
two values on each line are timestamps, which you can ignore in one shot
mode. The next two are the low and high frequency for that line, followed
by the bin width, which defaults to 1MHz, and then the number of samples.

The rest of the line contains the dB values.  If you start at the low
frequency and add the bin width for each dB value, then throw these values
in to a dictionary or some other data structure, you will get a value for
each 1MHz section of the band.

I hope this helps,
  Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170925/1e32334a/attachment.html>