Drivers – RTL2832U SDR
Before you run any software, you need to get the SDR device drivers. For windows this is done by replacing the default TV driver using Zadig. On Linux, rtl-sdr from OsmoSDR must be built from source. This part was rather painless, though I do suggest using the non-root install option during cmake.
SDRSharp or SDR# is a Mono/.NET application that is supposed to be cross-platform. However, after downloading, I quickly found that Linux wasn’t very well supported. To begin, the precompiled binaries threw exceptions and crashed. Support posts suggested compiling from SDR# source. I grabbed the latest from SVN after installing a slew of build dependencies. Then it is launched via mono SDRSharp.exe. However, there are some license issues with the RTLSDR linkage that prevented the inclusion of the SDRSharp plugin needed to use my SDR. Once you find the SDRSharp plugin, you need to edit SDRSharp.exe.Config to un-comment the plug-in. Then links need to be made to the RTL-SDR libraries. After that it runs… if you can call it that.
SDR Sharp UI Problems
First, the UI was so laggy that it was totally unusable. Two-five seconds delays when selecting options. Note that there is white text on white backgrounds (see image above) and very small text that overlaps other controls. After searching for 20 minutes, I found the only way to increase font size in mono was to lie to X11 and increase my system DPI settings. This helped the smaller text, but didn’t fix the broken panel controls like frequency manager. (see image below)
SDRSharp – Look at bottom left, panel won’t expand
This was all running in a small window. If I tried to maximize the application it basically locked up. Audio was okay without shutter, but the mono UI was very broken. Since it was Mono/.NET I tried this application on windows. It ran without any issues on Windows. It was smooth in fullscreen and reacted in real-time without even the slightest sign of lag. Of all the other applications, this one was my favorite for easy of use and simple interface… when you can get it to work. 🙂
Result: Linux unusable broken UI, Windows – Great!
Linrad (http://www.sm5bsz.com/linuxdsp/linrad.htm) is a no frills cross-platform SDR GUI. It isn’t very user friendly or as intuitive as other programs. Many of the functions are accessible only via keys that must find via the help and memorize. Everything was draw using basic lines. The spectrum display could desperately use some gradient or even solid fill to improve visibility. I have rather poor eyesight which made the small fonts and single pixel lines too hard to see at high resolution. While it did function for me, I found it too awkward to use and difficult for a beginner.
Result: User Interface awkward and too hard to use
While GnuRadio isn’t what I would term a SDR scanner/browser, it does have a huge rage of functionality. There are decoding plug-ins for a very wide range of signals. Real-time decoding can be done via FIFO files. I started trying Debian’s repository copy of gnuradio. While it ran, it was missing any RTLSDR sources. Checking the website revieled the need for a third party plugin gr-baz. This then gave me problems since it refused to compile missing Gurel, which was installed but not the development versions. That didn’t even appear to exist in Debian unstable.
More searching online to find additional solutions. This time I tried using the building script suggested on the gnuradio wiki page. I removed all repo versions of gnuradio binaries and let it run the script. After running for 20 minutes and chewing up 750MB of disk space, I got this:
Building Gnu Radio...
Exiting Gnu Radio build/install
I reran with verbose and got
make: *** No rule to make target `/usr/lib/python3.2/config/libpython3.2.so', needed by `gruel/src/swig/_pmt_swig.so'. Stop.
make: *** [gruel/src/swig/CMakeFiles/_pmt_swig.dir/all] Error 2
make: *** [all] Error 2
But I had python3.2 installed. Sure enough there is a libpython3.2mu.so. Turns out that gnuradio build/configure is broken.
Result: Failed to compile RTLSDR plug-in from source
Gqrx, website, looked like the perfect application for my Linux SDR problem. The UI looked easy to use and not overly complicated. The author suggest starting with the binaries first. Which I tried to only find that they were compiled for GLIBC_2.15 when Debian unstable is still at 2.13. Several minutes later, after finding tons of others complaints that Debian hadn’t updated, it seems that 2.14-2.16 were mostly updates for MAC/Windows and so they didn’t need to update. This of course means tons of other apps are broken too. (Like Steam) Okay, so I said “lets try the source.” I grabbed the latest versions and tried to install. The website suggested having GnuRadio installed should work. Maybe they meant the source version of GnuRadio because I could never get it configured to find it my versions. I even tried toying with the library paths of the qtcreator application. I have my doubts that it would have worked anyway since I couldn’t get the required third-party plug-in for GnuRadio to work.
Result: Failed to compile from source
SDRSharp – 0/10 – UI too buggy and slow on Linux – 8/10 on Windows
HDSDR – 0/10 – closed source with no Linux version – 5/10 Windows rather poor bitmap UI
Linrad – 4/10 – User interface awkward and too hard to use
GnuRadio – 0/10 – required third-party plug-in for SDR failed to compile
Gqrx – 0/10 – Failed to compile
QtRadio – 0/10 – too many dependencies that were not in distribution repositories
Excluding SDRSharp’s flawless performance on Windows, my results for trying to find SDR software on Debian Linux Wheezy were greatly disappointing. Hours of trial and error wasted on what should have been a rather simple “configure/make/install” process. The SDR drivers were working on Linux, but most of the applications had major issues. My only solution right now is to reboot into windows and use SDR#.