Like I put in my Links Page, Owen Morgan has an article on using $20 TV dongle to do software-defined radio. That article was mentioned when Owen did a presentation with his dongle at KARS and I eventually found myself in possession of three of these dang things and the desire to use them.
The first step was to assemble the software. The directions that Owen linked to talk about using something called "build-gnuradio" to use the dongle with GNU Radio. I know that GNU Radio is this general SDR software suite and, as seems to be the way of anything associated with GNU, it was written to use some extremely expensive hardware, but that it works just fine with this cheap little thing. The thing is, "build-gnuradio" sounds like it wants to build GNU Radio from source and, since the first steps for using it call for downloading the source and modifying the script, I decided that I wanted no part of it if I could avoid it. The Linux distribution that I use is Debian GNU/Linux "unstable" or "sid" and it already has a late model version of GNU Packaged for it and building packaged software from scratch is only for people who have the time to keep track of stuff manually.
So, armed with nothing more than extreme ignorance, and copious free time, I ventured into the realm of osmocomSDR. Now, Osmocom's main thing is building an SDR device that while it is far less elaborate than the device that the GNU Radio folks what you got get, is also far more capable than the dirt cheap little TV dongle that I got. The thing is, they've decided that their hardware should make use of the GNU Radio software and their hardware is kinda-sorta similar enough to the TV dongle that you can use their software as a kind of a wedge to go between the TV dongle and GNU Radio.
Okay, that defined the problem: Build this software, and get it to talk to both the EZCap hardware and GNU Radio. The only thing left was to do it.
Once I understood what I was attempting to do, then the execution was a bit of an anticlimax. First, I installed gnuradio and gnuradio-dev. Then, I got the rtl-sdr source using git as described on this page. Building it required that I install libusb-1.0-0-dev. Then, I got the gr-osmosdr source as describe on that same page page. Building that required that I install libboost-system-dev and swig. You may have to install other packages to build this, depending on what you already have installed. I had everything else that I needed.
The only tricky bit that I ran into with the building is that you need to tell cmake the right thing in order to get it to work. I followed the directions on that same page page but I made so much more progress when I improved the cmake commands. You see, cmake, by default, wants to put the software under /usr/local and, by default, won't build or install the udev rules. The udev rules meant that the dongle wouldn't work and putting the software under /usr/local meant that GNU Radio wouldn't find it, anyway.
To fix those issues easily, we use different options to cmake. To fix rtl-sdr, use this command from .../rtl-sdr/build:
cmake .. -DINSTALL_UDEV_RULES=ON -DCMAKE_INSTALL_PREFIX=/usr
and then make and make install like normal.
To fix gr-osmosdr, use this command from .../gr-osmosdr/build:
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
and then make and make install like normal.
After being mystified by, well, the mysteries associated with rtl_test and utilities that didn't seem to want to die (I wound up just hitting ctrl-C multiple times until the program exited) I was then mystified by the set up and use of a program called "gnuradio-companion". "gnuradio-companion" is a graphical program that allows you to build a radio by "wiring" functional blocks together graphically, but it's not fool proof.
In a nutshell, here is what learned about SDR from usin gnuradio-companion: All the sampling rates have to match. The RF data comes in from the dongle at somewhere between 1 and 2 million samples per second. The audio out is probably going to be around 40,000 samples per second. In fact, I used 44,100 samples per second for my audio out. So, somewhere along the way, the number of samples per second must be reduced, using a process known as "decimation". Software-defined radio treats the signal as a calculation and one of the important facts used by the calculation is the sampling rate, so getting it wrong causes a lot of grief. The easiest thing to do is to sample the RF signal at some integer multiple of the final audio rate. So, I wound up using an RF sample rate of 2,822,400 and doing two "divide by 8" interpolations along the way. Once I did that, I could listen to FM radio through my SDR.
gnuradio-companion allows you to save your logical radios as these things called "flowgraphs". So far, I've created three of them. So, I give you the flowgraph for a spectrum analyzer display centered around a local repeater frequency, a receiver for the US FM Broadcast band, and a receiver for the local 2-meter repeater frequency. The NBFM one doesn't really work because the audio is quite low and I don't really know why. If you do, please drop me a line. I thought it was because the deviation was only 2.5KHz instead of 5KHz, but reducing the deviation didn't help. Maybe I've got it filtered too tight. Update: I'm now confident that it's because I need to renormalize the audio by doing a multiply by constant.
Update again: The GNURadio folks have changed the way that it works. It is no longer required to have different versions for complex vs floating-point variables. That means that the flowgraphs that I give above don't work. They're pretty easy to patch, though. The problem is that the computer I'm using right now doesn't do audio the way that it needs to. I have no idea why. It sounds like the sample rate might not be set correctly.
Anyway, that's as far as I've gotten. I may do more and, if I do, I may write about what I do.