So the SoapyRTLSDR basically has its own ring buffer outside of the rtl driver. The problem is that the number of buffers is used both for this rung buffer and rtlsdr_read_async() which affects libusb async buffer allocation. I should point out that setting a larger number of async usb buffers seems to be very fragile and inconsistent between platforms. SoapyHackRF on the other hand, uses this value for the ring buffer, but has no way to pass it into the libhackrf. And while buffer defaults are only 15 buffers again, its a massive amount per buffer (256k). It looks like rtl uses this larger default buffer size as well, so I dont know why SoapyRTLSDR defaults to such a small size. So, I made the following adjustments to the SoapyRTLSDR on the master branch, test it out if you can. You should not need special arguments. LimeSDR also has a large ring buffer, so that should not have any issues either.
Thanks, I will try it ASAP. Btw. talking about LimeSDR, why doesn’t SoapyLMS7 driver return usable list of sample rates and list of bandwidths like every other SoapySDR driver does? I had to add force_sample_rate and force_bandwidth options to SimpleSoapy (and soapy_power) just to deal with this peculiarity.
Is it work in progress or is there some specific reason why not make listBandwidths and listSampleRates work as usual?
Great, I don’t get any more USB buffer overflows with latest SoapyRTLSDR Git master (using default 15 buffers). Thank you!
- listBandwidths - deprecated
Basically its an analog range where the filters are tuned upon being set to hit the desired filter roll off. Its too many values to return or display. For this reason, and some other devices like this listBandwidths() is deprecated. Use getBandwidthRange() which provides a list of continuous ranges. If it so happens that the device has several enumerable discrete filter values, then each range is just one value where start=stop. This means you can usually create a slider for the result[0].start and result[-1].stop. But it could be a drop down widget if all of the ranges were start==stop. Its a little weird to have both modes like that, but gr-osmosdr does this and it seems to be ok for gqrx.
- listSampleRates - here is why its unusual
So if you happen to set the master clock rate first, the listSampleRates() does return a list of possible rates. But if the clock rate isnt specifically set, setSampleRate() will automatically set it to achieve the desired sample rate. So its just like the bandwidth options issue, there is a continuous range of possible rates. it seems as if the other sdr devices that have configurable clock rates, do not automatically set it, so they always gives you a set of discrete enumerated options. making limesdr set the clock rate automatically is really convenient, but doing so opened up this API issue, but it seems to be the only device with this issue. I could fix it like the bandwith and have a getSampleRateRange(), and this would also mirror gr-osmosdr, even though its usually discrete values.
So nothing is every easy 
Thanks for explanation, I will change SimpleSoapy accordingly. Btw. it would be great if API would be consistent between bandwidths and sample rates, so I am in favor of getSampleRateRange() 
Btw. does all drivers which supports filter bandwidths have getBandwidthRange() implemented? Or do I have to check both listBandwidths() and getBandwidthRange()?
When the module does not implement getBandwidthRange(), getBandwidthRange behaviour defaults to calling listBandwidths() internally to fill in the range. So it should be good to use regardless of the individual modules implementation.
I have looked at buffer sizes reported by getStreamMTU on most common SDR devices and now I have some questions. Those are the sizes (when using SOAPY_SDR_CF32):
- RTL-SDR (latest Git master) … 131072
- HackRF … 131072
- Airspy … 65536
- SDRplay … 65536
- LimeSDR … 1360
Why is MTU reported by LimeSDR so low compared to the others?
Is MTU of Airspy and SDRplay optimal for those devices or also fragment from the past like it has been with RTL-SDR before your last change (but if I am not mistaken, that MTU has been even lower)?
Btw. there seems to be bug in SoapySDRplay, it doesn’t fill getBandwidthRange() with data from listBandwidths() (getBandwidthRange returns empty tuple).
Why is MTU reported by LimeSDR so low compared to the others?
Its the size of the FX3 transfers. It is an interesting number, but I’m not sure about the reason behind this, but it could be related to FX3 memory limitation, or block ram buffers in the FPGA. I belive with some of the other FX3-based SDRs, this transfer size is also somewhat small. But I should note that there is quite a large ring buffer in the driver, so even with the smaller buffers, this should avoid the overflow issue we saw earlier with the RTL prior to the fix.
Is MTU of Airspy and SDRplay optimal for those devices or also fragment from the past like it has been with RTL-SDR before your last change (but if I am not mistaken, that MTU has been even lower)?
The goal of the MTU was to specify the “native” size of the transfers so the user could avoid working with buffer fragments. In most cases, this value comes from the size of buffers presented by the underlying driver.
I cant speak for all of these drivers, some of them may have different internal sizes, and they just hide it through the API. But I believe that for most of these, the MTU here is the size of the libusb bulk transfers, and thus the size of buffers when the libusb async callback occurs.
Also keep in mind that several of these drivers have configurable buffer sizes, you are just looking at the defaults, but quite a few of them if you pass a stream arguments like “buflen”, you can change the MTU and libusb transfer size.
Btw. there seems to be bug in SoapySDRplay, it doesn’t fill getBandwidthRange() with data from listBandwidths() (getBandwidthRange returns empty tuple).
I think the author missed the notes about the call. Its fixed. Thanks!
Not sure why this happens, but QSpectrumAnalyzer crashes here running under Windows10Pro when I click on start, UNLESS I send the terminal output to a file by starting the program with “qspectrumanalyzer > qspec.log” instead of “qspectrumanalyzer”. I used exact recipe for installing qspectrumanalyzer from the README.rst file:
- install Python 3.6 (64-bit) from python.org (
download <https://www.python.org/ftp/python/3.6.1/python-3.6.1-amd64.exe>_)
and add Python to PATH - install SoapySDR libraries and drivers (bundled as part of Pothos SDR installer:
download <http://downloads.myriadrf.org/builds/PothosSDR/?C=M;O=D>_) pip install PyQt5pip install QSpectrumAnalyzer
I figured that you should know about this even though I don’t need a fix as I can just always dump the terminal output to a file; as you know its only a few lines at the start of the program anyway.
Windows support is only in Git master branch of QSpectrumAnalyzer (there are more fixes). Can you please install it and tell me if it works for you?
Install Git for Windows, then:
- git clone https://github.com/xmikos/qspectrumanalyzer.git
- cd qspectrumanalyzer
- pip install .
Excellent, Mikos! I installed from git and it works fine now without the need to port the terminal output to a file.
Great program, and wonderful support. Thanks so much!
Sorry for the delay, but my Win installation is dual-boot with Linux and I was doing a release upgrade when I got your suggestion. That upgrade took quite a while to finish, and I couldn’t get back to Windows to do as you suggested until the upgrade finished. (qspectrumanalyzer works fine here on Ubuntu 16.04 too. It had problems on 14.04 due to numpy being stuck at 1.08, which is why I decided that it was finally time to do the upgrade).
Have a great week,and Thanks Again!
Dear Mikos,
can you please assist… with Win10
Git installed in accordance to above, but no luck with running.
73
Djani
C:\Users\Su>cd qspectrumanalyzer
C:\Users\Su\qspectrumanalyzer>pip install .
Processing c:\users\su\qspectrumanalyzer
Collecting soapy_power>=1.5.0 (from QSpectrumAnalyzer==2.1.0)
Downloading soapy_power-1.6.0.tar.gz
Collecting pyqtgraph>=0.10.0 (from QSpectrumAnalyzer==2.1.0)
Downloading pyqtgraph-0.10.0.tar.gz (1.5MB)
100% |████████████████████████████████| 1.6MB 306kB/s
Collecting Qt.py (from QSpectrumAnalyzer==2.1.0)
Downloading Qt.py-0.6.9.tar.gz
Collecting numpy (from soapy_power>=1.5.0->QSpectrumAnalyzer==2.1.0)
Downloading numpy-1.12.1-cp36-none-win32.whl (6.7MB)
100% |████████████████████████████████| 6.7MB 87kB/s
Collecting simplesoapy>=1.4.0 (from soapy_power>=1.5.0->QSpectrumAnalyzer==2.1.0)
Downloading SimpleSoapy-1.4.1.tar.gz
Collecting simplespectral (from soapy_power>=1.5.0->QSpectrumAnalyzer==2.1.0)
Downloading SimpleSpectral-1.0.0.tar.gz
Installing collected packages: numpy, simplesoapy, simplespectral, soapy-power, pyqtgraph, Qt.py, QSpectrumAnalyzer
Running setup.py install for simplesoapy … done
Running setup.py install for simplespectral … done
Running setup.py install for soapy-power … done
Running setup.py install for pyqtgraph … done
Running setup.py install for Qt.py … done
Running setup.py install for QSpectrumAnalyzer … done
Successfully installed QSpectrumAnalyzer-2.1.0 Qt.py-0.6.9 numpy-1.12.1 pyqtgraph-0.10.0 simplesoapy-1.4.1 simplespectral-1.0.0 soapy-power-1.6.0
than
C:\Users\Su\qspectrumanalyzer>qspectrumanalyzer .
Does nothing
*EDIT
After
pip install PyQt5
at last something… but crashes with press on start button
something is missing …
**EDIT
Must be Soapy problem because CubicSDR bundled with Photos installation can not see LimeSDR or SDRplay…
Mikos,
Got qspectrumanalyzer running under Win 10 64 bit! Tnx!!
Mike
Hi All,
I get issue with soapy_power on Win10 64b.
It seems it can not find SoapySDR module. PothosSDR installed
PS C:\projects\LimeSDR\qspectrumanalyzer> soapy_power.exe
Traceback (most recent call last):
File “C:\Program Files\PothosSDR\lib\python3.6\site-packages\SoapySDR.py”, line 14, in swig_import_helper
return importlib.import_module(mname)
File “c:\python36\lib\importlib_init_.py”, line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File “”, line 978, in _gcd_import
File “”, line 961, in _find_and_load
File “”, line 950, in _find_and_load_unlocked
File “”, line 648, in _load_unlocked
File “”, line 560, in module_from_spec
File “”, line 922, in create_module
File “”, line 205, in _call_with_frames_removed
ImportError: DLL load failed: The specified module could not be found.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “C:\Python36\Scripts\soapy_power-script.py”, line 11, in
load_entry_point(‘soapy-power==1.6.0’, ‘console_scripts’, ‘soapy_power’)()
File “c:\python36\lib\site-packages\pkg_resources_init_.py”, line 565, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File “c:\python36\lib\site-packages\pkg_resources_init_.py”, line 2631, in load_entry_point
return ep.load()
File “c:\python36\lib\site-packages\pkg_resources_init_.py”, line 2291, in load
return self.resolve()
File “c:\python36\lib\site-packages\pkg_resources_init_.py”, line 2297, in resolve
module = import(self.module_name, fromlist=[‘name’], level=0)
File “c:\python36\lib\site-packages\soapypower_main_.py”, line 5, in
import simplesoapy
File “c:\python36\lib\site-packages\simplesoapy.py”, line 5, in
import SoapySDR
File “C:\Program Files\PothosSDR\lib\python3.6\site-packages\SoapySDR.py”, line 17, in
_SoapySDR = swig_import_helper()
File “C:\Program Files\PothosSDR\lib\python3.6\site-packages\SoapySDR.py”, line 16, in swig_import_helper
return importlib.import_module('SoapySDR’)
File "c:\python36\lib\importlib_init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: DLL load failed: The specified module could not be found.
I have finally published new version with MSI installer for Windows:
QSpectrumAnalyzer 2.2.0
- hackrf_sweep backend fixes and rate limiting (thanks to @michaellass)
- better Python 3.4 compatibility
- many Windows fixes
- installer for Windows is finally available
- allow setting gain with more precision
- soapy_power dependency is now optional (it is still required in setup.py, because it is default backend, but QSpactrumAnalyzer will now actually run even without it)
You can get it from GitHub: download
Also few new versions of soapy_power are available for some time, look at GitHub releases page for changelog. soapy_power is bundled with QSpectrumAnalyzer in installer.
Windows is not my platform, Linux all the way! So try it and tell me how it works for you.
What is the proper device string to use and how do you select the antenna port etc…?
Selected device: LimeSDR-USB
Available RX channels:
0, 1
Available antennas:
NONE, LNAH, LNAL, LNAW, LB1, LB2
Thanks