QSpectrumAnalyzer now works with LimeSDR!

I have tried it again and now it works, strange :slight_smile: Maybe reboot of Windows virtual machine has helped, as a long time Linux user I am not used to reboots anymore :wink:

@andrewback @joshblum Even if it works now in Pothos GUI, I still can’t get soapy_power to work. I am trying with RTL-SDR now and SoapySDR seems to communicate with it (I can set frequency and sample rate and start streaming), but every time I try to actually read stream, I get error -1 (TIMEOUT). Even if I set read timeout to some big number (e.g. 5 seconds), it always timeouts after it. There is no such problem in Linux and judging by that Pothos GUI works, there has to be something wrong in how I use SoapySDR from Python. But I could not figure out where is the issue :frowning:

After looking at the code I can see that a tracking generator would be another program that uses this SpecAn as the display.
There would be a GUI to input which TX output, signal level, begin and end frequency, sweep rate, maybe single or recurrent sweep, start, stop, freeze, etc. Then the analyzer would opt to follow the outputted signal directly or offset by either a multiple of the output or an added or subtracted value.
I won’t get my LimeSDR for another month so I can’t play with anything yet but it seems that the bandwidth of the inputs will be a problem. A spectrum analyzer has a setting to vary the sampled signal band for resolution, narrow bandwidth takes longer to sweep and generates more samples. So imagine opening a 10 KHz bandpass and sweeping it through 100 MHz in 10 KHz steps while sampling the peak value at each step. This is different than opening a 20 MHz or larger wide RX and sweeping it and then sampling the data 10 KHz at a time. From all the trouble I see people having with imaging I would think the bandwidth is too wide and non selectable to make a good SpecAn or tracking generator. But it would still be a good tool.

once hitting the 60Mhz bandwidth, the Lo need to be changed and then the sweep frequency back to what it stopped at …then continue on …

@mikos maybe file an issue here is fastest way??

I know, when I get time to tinker with Windows again, I will post proper bugreport. To be fair, I have to say that I don’t like the idea of tinkering with Windows much :-/ I know I can use that time much more efficiently (implementing new features, etc.). It would be great if some Windows user can do it instead.

I have prepared soapy_power and QSpectrumAnalyzer to work on Windows (I have fixed issue with pipes on Windows and even SciPy is now only optional dependency), so the only problem that remains is SoapySDR freeze (timeout error) in readStream.

I have now released soapy_power 1.3.0 and QSpectrumAnalyzer 2.0.0. There is changelog:

soapy_power 1.3.0:

  • soapy_power now uses new SimpleSpectral module for computing PSD, this removes hard dependency on SciPy
  • pyFFTW is now used by default (if available)
  • --tune-delay option now not only sleeps after changing frequency, but actually flushes buffers (this removes artifacts from previous frequency hops on HackRF)
  • new --reset-stream option which resets streaming after changing frequency (this removes artifacts from previous frequency hops on LimeSDR)
  • binary soapy_power_bin format now includes both acquisition start time and stop time

QSpectrumAnalyzer 2.0.0:

  • switch from PyQt4 to Qt.py, QSpectrumAnalyzer now supports both PyQt4, PyQt5, PySide and PySide2 (PyQt5 is used by default)
  • fix pipe used for communication with soapy_power process on Windows
  • allow backend executable in Settings to be composed of multiple words (so e.g. python /path/to/soapy_power.py can by used)

I know there are windows users here so maybe someone can have a look. I stopped using windows a long time ago.

I tested the simplesoapy example with ‘driver=lime’ on windows 10 and it gets the samples. Is the simplesoapy example a good minimum test case for the stream timeout failure issue? Perhaps we are looking at a windows 7 driver issue. Is the same code working on windows 8/9/10 for anyone else.

Yes, simplesoapy test case should be enough. I only have Windows 7 Pro license, so I can’t test anything else. It could be also problem only when running it virtualized in VirtualBox.

But now it seems that it is definitely driver issue, I have tried HackRF and that works with SimpleSoapy without problems. QSpectrumAnalyzer works with it too. I have been using only RTL-SDR for quick tests before, so it seems only SoapyRTLSDR driver is problematic.

Can you also look at SoapyRTLSDR driver? Or is it developed by someone else?

Now I have tested Airspy and it works too! But I couldn’t test LimeSDR because of problems with virtualized USB 3 drivers in VirtualBox. But so far it seems good - HackRF works, Airspy works, LimeSDR will maybe work too. So probably really only SoapyRTLSDR has to be fixed.

Can you try again without the 100 buffers line for the rtl? It makes it timeout or crash on my PC

I dropped windows 7 a while ago in favour of testing/building on windows 8.1. I skipped windows 9 for some reason. But recently I moved to windows 10 to keep up with things. Basically its free to download the complete ISO, and you dont need to activate it to use it fully. I use it in virtualbox without any issues. You just occasionally have to see a watermark in the corner, and some of the theming has to be done through the registry if you care about that sort of thing - https://www.howtogeek.com/244678/you-dont-need-a-product-key-to-install-and-use-windows-10/

Ah, I didn’t thought about this, it is not problem on Linux and with default 15 buffers I got USB buffer overflows. There has to be some problem with reading SoapySDR buffers from Python (it shouldn’t be that slow with NumPy to get buffer overflows, but nevertheless it is). I will remove it to maintain compatibility with Windows. It would be best to fix underlying problem with slow reading of buffers…

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 :slight_smile:

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() :wink:

Btw. does all drivers which supports filter bandwidths have getBandwidthRange() implemented? Or do I have to check both listBandwidths() and getBandwidthRange()?