On 25 September 2017 at 16:04, Sebastiaan van Pelt <sebastiaanvanp...@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
_______________________________________________ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
