[Hackrf-dev] HackRF_sweep

[Sebastiaan van Pelt]

Good evening,

I have got a question with regards to hackrf_sweep but I will give some background information first, which will hopefully help with answering my questions.

I am currently working on a project that involves the design of a SDR that can send and receive a file (txt) and has a cognitive element. I'm using two hackRF's and have successfully sent files two-way, using GFSK transmitters produced in GNU Radio. This has been done through the use of a shell script to send 5 files on 5 different frequencies within 10 secs. 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 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.

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?

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.

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.

I appreciate this is quite a lengthy question but any help one any of these questions would be great!

Seb

[Dominic Spill]

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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

Post by Sebastiaan van Pelt
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?

Post by Sebastiaan van Pelt
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?

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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

[Sebastiaan van Pelt]

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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. 

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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

 

[Sebastiaan van Pelt]

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.

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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. 

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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.

Post by Sebastiaan van Pelt
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