QSpectrumAnalyzer now works with LimeSDR!

I’m guessing he means produce an output on a TX port that tracks the analyser sweep, so that you could use it as a spectrum analyser with tracking signal generator, which I have to admit would be very cool indeed.

1 Like

It works! After doing deactivateStream before setFrequency and then activateStream again, everything looks great, no more artifacts from previous frequency hops!

But now I have different problem, if I am running big sweep (e.g. 80 MHz - 1080 MHz, with 61.44MHz sample rate and bandwidth), after some time I got many SQL errors on terminal (after every setFrequency call):

[INFO] SoapyLMS7::setFrequency(Rx, 0, RF, 978.88 MHz)
SQL error: (null)
SQL error: (null)
SQL error: (null)
[WARNING] SQL error: (null)

Do you have idea what can be causing it?

Well, I don’t have signal processing / RF engineering background (I am programmer and SDR is only hobby for me ;-)), so I am not sure how to implement something like this. Could you link me some informations about it?

Or even better if someone with good understanding of the field (and some Python knowledge) can implement it, that would be really great, like I said before I am open to pull requests.

Some info here:

http://www.edn.com/electronics-blogs/emc-emi-rfi-esd/4396464/Using-a-tracking-generator

Could be a fun project for someone to add this capability :slight_smile:

Thanks, I will look at it.

Btw. what about SoapySDR not working on Windows 7 Pro (x64) in VirtualBox, is there some known problem? Can you tell me who can I contact to help me resolve this issue? I would like to make QSpectrumAnalyzer installer for Windows before next release.

Hopefully @joshblum can advise.

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…