[Hackrf-dev] HackRF_sweep

Tue Sep 26 13:22:24 EDT 2017

Dominic,

To follow-up from my email earlier I have now organised the output of the sweep through the use of IFS in a shell script. This works really well and we are now trying to use this data to feed further stages of our cognitive radio design.

To be continued.

Op 26 sep 2017 om 02:21 uur uur schreef Sebastiaan van Pelt <sebastiaanvanpelt at me.com>:

Good morning Dominic, thanks for your quick and comprehensive response. The answers to your requests to clarify are below:

Op 25 sep 2017 om 16:28 uur uur schreef Dominic Spill <dominicgs at gmail.com>:

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?

*(1) Yes, that is one of the deliverables of the project. I will then try and prove my concept by generating signals throughout the band, to represent users occupying certain channels. My radio will have to avoid these channels and offer usable channels to my other radio(s).  I think dividing the full band into a 100*1MHz channels might be a bit much for the first iteration.  But depending on the progress in analyzing the CSV file I might go ahead and try this. 

> 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) If possible, I would like to utilise the full sampling rate of 20MHz that the HackRF offers.  The thing I was struggling with is how the data appears in the CSV file (see *(4)) and my idea was that if I only scanned 5MHz, the data would appear in my file in one single line making it easier to process.

> 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) This was a typo on my end, I did read that it was samples per frequency but could not see any changes in the output of my CSV file. I've just run 4 sweeps using one-shot from 2.4 to 2.5 GHz, incrementing -n from 16384, 163840, 1638400, 16384000.  I'm observing the filesize and the number of lines increasing by a factor 10 (and the one-shot time by about the same factor).  Is this simply the result of the frequency being sampled 10 more times? Would you say that this gives you an increased resolution of the spectrum when the output of the file is analysed? I don't want to alter the bin size to gain a better resolution so running one-shot simply using more samples per frequency seems a good trade-off.

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

*(4) Thank you for this great suggestion. I have been playing around with one-shot but every time I did this my CSV file was empty. This might have been because I was not sweeping a large enough part of the spectrum. This now works great and I will definitely proceed with one-shot since it is easier to incorporate in a shell script since it "shuts down the HackRF gracefully".

I will investigate the suggestion of the CSV module, there are some people around me who have implemented it in their solution (we've got 3 teams doing the same project). The only problem that I anticipate, is the issue of interleaving.  When scanning as you suggested `hackrf_sweep -1 -f2400:2500` the lines are interweaved as well, and I need to "untangle" this. To clarify, my first line displays 2400 MHz to 2405 MHz and the dB columns correspond to this. The next line, however, does not start at 2405 as you would expect but covers 2410 to 2415. This goes on throughout the file. I hope you see my problem here. I will do some rapid learning on the CSV module in Python but if you have any suggestions on how to organise my data I'm definitely open for it. 

I hope this helps,
  Dominic

_______________________________________________
HackRF-dev mailing list
HackRF-dev at greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170926/765a30c9/attachment.html>