Software Defined Radios on Linux

There are a lot of very powerful tools for using SDRs in Linux. There are not a lot of good documents for setting up SDRs in Linux. This page documents what I have learned setting up my own Linux-based SDR station. It will no doubt join the not-so-good documents for setting up SDRs in Linux.

If you're looking to set up a specific SDR program, you might want to jump to one of the following links:

Assumptions

This page assumes that you basically know your way around a Linux system, that you have a functioning build system (on Ubuntu, install build-essential, autoconf, and automake at the very least), and that your system already generally works. (For example, you can play audio files on your sound card.)

Hardware

As of February 2011, my SDR is a SoftRock RxTx version 6.3 built from a kit purchased from Tony Parks, the SoftRock radio designer, at kb9yig.com. The SoftRock radios are by no means the only SDR game in town, but they're affordable and fun, and work very well. I am controlling the Si570 programmable oscillator on the radio with a DG8SAQ AVR-USB-style USB interface adapter.

The upshot of this equipment setup is that this documentation will be oriented toward SDRs which are controlled by a USB interface to an Si570 and which present their received spectrum as I and Q (in-phase and quadrature) signals mixed down to baseband and input via a sound card interface.

I am using a Creative Labs Sound Blaster X-Fi Surround 5.1 USB sound card. While I am not going to go out of my way to recommend it, it seems to provide good audio input quality at a sampling rate of 96kHz (meaning that you can see 96kHz of RF spectrum at a time). They run about $50 new as of this writing.

Note that your radio, your audio cables, and your software all have to agree on which audio channel (left and right) represents which IF waveform (I and Q). Each of the applications below has a way to swap these around, if your particular setup is backward from what the software expects. In particular, the default setup for Quisk and the default setup for sdr-core seem to be reversed for me.

Note also that, where possible, I name sound devices using their ALSA "names". This is because ALSA device numbers are not necessarily static, particularly where USB sound devices are concerned. The aplay -l and arecord -l commands will list sound devices with their names (after the card number and before the square brackets).

The SDR Widget

In addition to my hardware, I have been working with an SDR Widget belonging to a friend of mine. There are some notes about setting it up, as well, where it differs from the simple SoftRock controller I have.

In particular, the Widget presents an ALSA sound device called "DG8SAQI2C", and (as you might guess from that name) also provides a DG8SAQ controller.

Software

The software situation for SDR on Linux is complicated. There are at least four major transceive-capable SDR applications (Linrad, DttSP (probably in conjunction with something like SDR-Shell), GNU Radio, and Quisk), as well as several receive-only applications. Each of these applications has different strengths and weaknesses, uses different sound interfaces and libraries, supports different modulation modes, etc. Picking it all apart and deciding what to use can be difficult, to say nothing of gathering all of the dependencies and components and making the thing actually work. It is not exaggerating to say that the documentation for Linux sound interfaces is some of the worst I have ever seen, and the documentation for SDR radio programs is not far behind. Since a working, possibly complicated, sound interface is required to get an audio I/Q SDR working in Linux, the adventurer entering this realm is in for a double whammy!

I have successfully set up each of these programs other than GNU Radio (just not there yet!), and this section will describe what I have learned in doing so.

Frequency Control

Frequency control in this setup is accomplished via the DG8SAQ USB-to-I2C protocol. The various SDR programs generally speak to the controller in one of two ways: directly, or via the program usbsoftrock.

If you have a fixed-frequency radio (e.g., a SoftRock Lite II Receiver), you won't need to mess with this at all.

usbsoftrock

usbsoftrock is a simple-to-use program by Andrew Nilsson which accepts convenient command line options (e.g., frequencies in MHz), speaks the DG8SAQ USB protocol, understands the Si570, and can act as a daemon listening over UDP for control messages.

The usbsoftrock sources are available for download in a Google Code repository.

usbsoftrock is simple to build and install, so I won't go through that here. Its only dependencies are ncurses and libusb, which, on Ubuntu systems, are provided by the libncurses5-dev and libusb-dev packages, respectively. Note that there is also a libusb-1.0-0-dev package, but it provides a slightly different API, and you'll need the older version for usbsoftrock..

Using usbsoftrock to change the frequency of your radio directly is very easy. Simply issue the command usbsoftrock set freq [frequency], where frequency is in MHz. For example, to set the center frequency to 7.030 MHz so that you can copy PSK31 at 7.035 MHz, you would run usbsoftrock set freq 7.030.

Note that while Si570 oscillators are accurate, they are not necessarily precise without some footwork. The reference in an Si570 is a crystal vibrator with a nominal frequency of 114.285 MHz, and all of its output frequencies are computed from this frequency. The actual crystal can vary by many kHz from this nominal frequency, however; my SoftRock v6.3's Si570 oscillates at 114.211833MHz, a deviation of more than 150kHz! In order to achieve precision, controlling software must use this crystal frequency in its configuration calculations. You can retrieve the frequency at which your Si570's crystal oscillates with the command usbsoftrock calibrate. You can then provide it back to usbsoftrock with the -x argument. To achieve a more precise tuning, the above 7.030MHz example for my SoftRock would be usbsoftrock -x 114.211833 set freq 7.030. You may need this crystal frequency for configuring other applications, as well.

If you are using the SDR Widget, it handles calibration itself, and you don't need to worry about this.

Permissions

The only tricky part about communicating with your DG8SAQ device is giving non-root users access to the device. You'll want to do this whether you use usbsoftrock or direct access, and whether you use a simple controller or something more sophisticated (such as the SDR-widget). This is accomplished via the udev device manager. Create the file /etc/udev/rules.d/99-softrock.rules containing the following line: 

SUBSYSTEM=="usb", ATTR{idVendor}=="16c0", ATTR{idProduct}=="05dc", MODE="0660", GROUP="dialout"

Note that case, precise characters, and spacing (it all has to be on one line) are important here. This recipe will allow access to the DG8SAQ to device to all users who are in the 'dialout' group. The popular recipe flying around the Internet uses MODE="0666", which allows access to all users; take your pick.

You will have to reboot for this change to take effect. It should be able to be accomplished without rebooting, but I don't know how. (Quite frankly because I only had to make the change once!) Reloading the udev config with service udev reload really ought to do it (and may).

Demodulation

Once you have tuning down, you're going to need a program which interprets those I and Q baseband IF signals and pulls usable audio out of them via normal SSB, AM, CW, FM, etc. demodulation methods. This is the piece of software which you might think of as the "radio"; in conjunction with the actual hardware, it does the heavy lifting. We'll go through the installation process of several of these programs.

Quisk

The first program on the list is James Ahlstrom's fantastic Quisk. It is probably the easiest of all of the SDR programs I have used both to set up and to use. As a bonus, it's even easy to hack! The links to the left of the Quisk page contain some really good information on SDR function, sound setup, and other topics which you might wish to peruse, as well.

Quisk is a Python application with a C core. In order to build it, you're going to need development packages for ALSA, portaudio, and libfftw3. On Ubuntu 10.10, these are provided by libasound2-dev, portaudio19-dev, and libfftw3-dev, respectively. We'll run into a little bit of a problem with that second one later, but for now, you need it. You will also need the Python packages for the wxWidgets library, which is provided by python-wxgtk2.8.

To build Quisk, fetch the tarball from PyPI, untar it, and then run make and then python setup.py build from the source directory. You may install it (sudo python setup.py install) if you like, although I don't, I just run it from the source directory. (It's easy to hack, remember?)

Configuring Quisk is done by way of the file ~/.quisk_conf.py, a number of examples of which are provided in the source distribution. The file I use for Quisk 3.5.1 may be helpful. The quisk_conf_defaults.py file that ships with the source distribution contains extensive comments on the configuration parameters. At the very least you are going to need to set your capture (radio) and playback (headphones) devices, as well as their sample rates. If you are using a DG8SAQ Si570 interface, you may want to set the si570_direct_control option to True and enter your Si570's crystal frequency (in Hz) in si570_xtal_freq. (You can retrieve that information from the usbsoftrock calibrate command, as above.)

Note: Quisk releases prior to 3.5.2 require this patch for calibrated Si570 device control. This functionality has been rolled into 3.5.2 and later releases.

At this point, I suggest you take a moment and just click around in Quisk for a while; it's a ball! The Help button tells you all you need to know about how to operate it; it's mostly self-explanatory, but there are some useful little tricks (such as how to fine-tune) in there.

I have thus far been unable to make Quisk talk directly to the SDR Widget controller. usbsoftrock works fine, however, so you may get some mileage out of the modified Quisk 3.4.8 by Alex Lee, 9V1AL, in the softrock40 Yahoo! group file section.

DttSP and SDR-Shell

sdr-shell software stack

Figure 1. The sdr-shell software stack. Arrows indicate direct communication between components.

DttSP and SDR-Shell are, unfortunately, not as easy to set up or to use as Quisk was, both because they are themselves more complicated, and because they require you to come to terms with a low-latency audio server called JACK. To compound the difficulty, while there are several sites with information about DttSP (also known as sdr-core) and SDR-Shell scattered around the web, most of them are wrong or out of date. The information presented here was distilled from several mailing lists, the DttSP wiki (at http://dttsp.org/wiki, which is down as of March 2011), various web pages, and the source code itself.

What DttSP and SDR-Shell are is a powerful combination of SDR software which plumbs in readily with other audio processing applications by way of the JACK service, including digital mode applications like Fldigi. sdr-core is also rather easier on the CPU than Quisk, so if you have an older or slower computer, you may find that it performs more adequately to your needs.

Fig. 1 depicts the relationships between the software components which form a working sdr-shell rig for a Si570-controlled soundcard I/Q radio. The Linux kernel sits at the bottom of the stack, managing access to the actual hardware devices (in this case, the sound card and the DG8SAQ USB device). JACK, usbsoftrock, and sdr-core act as "services" which provide various functionality to the application you, as the operator, will interact with: sdr-shell. JACK sits between sdr-core and the kernel, routing audio for both the RF interface (I and Q) and the operator interface (speaker and microphone). usbsoftrock sits between sdr-shell and the kernel, providing a UDP socket through which sdr-shell can tune the Si570 device. sdr-shell presents you with a GUI interface for radio control, then manages the Si570 oscillator and sdr-shell operating mode, including filters and modulation. This complicated stack is why sdr-shell setup is more tricky, but also what makes it powerful.

The first thing you're going to need to do to build these pieces of software is fetch a raftload of dependencies. Both the sdr-core and sdr-shell components are kept in Subversion repositories, so make sure you have the subversion package installed. In addition, sdr-core depends on liblo, libfftw3, the GNU Scientific Library, and JACK. sdr-shell depends on Hamlib and Qt4, and requires qmake-qt4 to build. You may have already installed some of these libraries for prevous programs on this page. You can fulfill these dependencies on an Ubuntu 10.10 system by installing:

Note: If you're on Ubuntu 10.10 (or probably some other distributions), and you've installed Quisk, apt-get is going to exclaim that bad things are happening and you have some incompatible software installed, and remove some of the portaudio packages in order to meet these dependencies. That is because portaudio on Ubuntu 10.10 is compiled against JACK 0.118, and we're installing 1.9.5. Your installed Quisk will continue to work (this only affects the development packages), but you'll have to do a bit of package shuffling to build Quisk again after this. Alternately, you can put the portaudio development headers someplace convenient and point Quisk toward them at build time.

After you have that, you need to grab an appropriate version of DttSP. The currently en vogue DttSP (according to the DttSP wiki and the DttSP Yahoo! group) seems to be a branch maintained by AB2KT. You can fetch it via Subversion with this command: 

svn co https://www.cgran.org/cgran/projects/dttsp/branches/ab2kt/sdr-core

You will have to accept a self-signed certificate to continue.

Change to the base/src directory and run the bootstrap script found there. Then, ./configure and make as normal. The documentation (somewhere, maybe with sdr-shell?) suggests using checkinstall to install sdr-core, but it really only installs one file, sdr-core. I suggest simply copying that file to somewhere in your path (perhaps /usr/local/bin).

Once sdr-core is installed, you're going to need sdr-shell. Again, the version du jour is SDR-Shell v4 from Subversion. Fetch it from Google Code with: 

svn co http://sdr-shell.googlecode.com/svn/branches/sdr-shell-v4

The README file in this directory contains some good information. You'll probably want to look through it at some point.

Having fetched the source, change to the sdr-shell-v4 directory and run qmake-qt4 and then make. This should build a sdr-shell binary. Copy it someplace convenient, as you did with the sdr-core binary.

At this point, we're ready to start up sdr-shell. As the sdr-shell README says, "Getting a radio working with sdr-shell, dttsp, and utilities is a lot like building your own radio, but with less solder." There are several steps to the setup process each time the radio is started. I have written a simple shell script which performs this startup sequence for you for a receive-only setup. It has a dozen or so commented configuration variables at the top that you may need to modify for your system.

For your edification (and in case you need to mess with it), the startup process goes more or less as follows:

If you use my sdr script, note that the demodulated audio output is on the JACK device sdr_rx. This is the device you would want to connect to, e.g., Fldigi.

Linrad

Coming soon, I'm running out of steam...

Questions? Comments? Contact me at elb@kb8ojh.net and let me know!

Creative Commons License This work by Ethan Blanton is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work from .