I have a confession to make. I'm not a particularly dexterous person. I think — as odd as it sounds — that this explains my fascination with FPGAs. Even as a kid, I always wanted to build really massive electronic circuits, but as a kid I was lucky to cobble together some simple Heathkits without burning wires, lifting pads off PC boards, or otherwise destroying them.
I got a little better as I got older. I can even work with surface mount parts these days, but it is still a challenge for me. But the idea of building a CPU out of real parts (like http://www.bigmessowires.com/bmow1/ or even http://web.cecs.pdx.edu/~harry/Relay/) is a total pipe dream to me. On the other hand, armed with an FPGA, I can make machines that would dwarf Steve and Harry's computers (no offense, guys).
So I've satisfied my computer building desires, but oddly enough computers weren't my first electronic love. My first introduction to electronics was with radio. My dad knew a little about radios and I became fascinated with the whole subject. By age 14 I had a ham radio license and I still practice that hobby today. As with computers, my radio imagination was bigger than my skill at building radios. What I really need is a radio FPGA, so to speak.
Although that's the wrong terminology, such a thing actually exists. It is possible to get A/D converters that can feed radio signals to a computer where all the demodulation, decoding, and other radio work is done by the computer — either a general-purpose computer like a PC, or a specialized DSP chip. This is known as software-defined radio, or SDR. You can even go the other way and have the computer send out signals and transmit radio signals.
A surprising number of modern radios are using these techniques. Digital signal processing can produce razor-sharp filters and amazing flexibility in a radio. There are quite a few ways to experiment with SDR, ranging from dedicated units to radios that feed your PC's sound card (which is, after all, a pretty fair DSP processor).
However, I recently read that a chip commonly used in inexpensive USB TV receivers can be pressed into service as an SDR receiver. The device you want is actually made for receiving DVB-T (which is a digital television standard used in many parts of the world). You can find these online for about $20, usually under the name EZTV-668. They look like a large USB memory stick. Inside are two major ICs and just a few support parts. The ICs of interest are an RTL2832U SDR and a tuner. Not all of the devices use the same tuner and apparently the best results are with a chip known as an ET4000. With the right tuner, the device has an astonishing range of 60MHz to 1800MHz (with one small gap in the coverage for technical reasons).
Hardware setup is as simple as you'd like to make it. Plug in the included antenna (which is really not adequate, but sufficient to start with) and plug the USB end into your computer. The issue, of course, is the software. After all, the software that comes with it is for receiving DVB-T on specific channels.
Of course, you can find some prebuilt software, but one of the interesting things that can work with this makeshift SDR is a program called GNU Radio. GNU Radio is actually a bunch of Python libraries (some of which use C++ internally) that allow you to build software-defined radios. In addition, it includes a program called gnuradio-companion that lets you build quite a few things graphically, stringing together building blocks (which are actually Python functions). In fact, once I started playing with GNU Radio, I realized that it is a bit misnamed since it can do some experiments and useful functions with no radio at all. To quote the program's homepage:
While not primarily a simulation tool, GNU Radio does support development of signal processing algorithms using pre-recorded or generated data, avoiding the need for actual RF hardware.
In fact, even that's a little bit of an undersell since the tool can pick up data from a sound card as well. Just to give you a flavor of GNU Radio, I'll show you a simple audio-only tool. You shouldn't need anything special to run this other than a Linux PC with a working sound card.
When you open up a new gnuradio-companion document, there are two blocks in the main work area: an options block, and a sample rate variable block. The options block lets you set the name of your design and a few runtime options. For now, you don't need to change any of those.
samp_rate variable isn't special. It is just a variable, but many other blocks will refer to it by default for their sampling rate. You are free to change it, but it is handy to have it already filled in. For this example, double click the box and fill in the
Value field with 22050. Note that the program underlines the names of the fields in this dialog. This indicates the parameters can change at runtime (not all of them can).
There is a set of blocks on the palette to the far right. GNU Radio uses the notion of sources to represent SDR hardware, files of recorded data, or your sound card. A sink is a place where data goes, like a sound card, or a file, or a virtual instrument (like an oscilloscope).
To create the flowgraph (that's what a GNU Radio document is; see Figure 1), I added an Audio Source, a Delay, and an Audio Sink to the document. I also wanted some eye candy so I added a WX GUI Scope Sink and an WX GUI FFT Sink. These sinks will let you visualize the sound flowing through the "radio" (although this is really more of an audio processor).
You can see the important parameters in the blocks. Notice the sample rates all show as 22.05k, but they are not really set to that. They are set to
samp_rate and the display shows the value of
samp_rate. In general, you can put any Python expression you like in a field as long as it has the right type. In other words,
samp_rate*2 would be a legitimate value if you wanted to use double the sampling rate (in fact, that's what's really in the Delay box's
Speaking of types, this graph only uses floats, but GNU Radio knows about several different kinds of types. The orange ports indicate that the data produced or consumed is floating point data. Other types have different colors.
To connect the blocks, just click on one out port and then click on an in port. It is legitimate to split an output to more than one input (for example, the Audio Sink and the FFT sink both feed from the same output). You can download the completed graph here.
If you run the graph, you'll see something similar to Figure 2. If you aren't using Pulse audio you might need to change the Device Name in the Audio Source and Audio Sink blocks to match your system's sound hardware. If you speak into the specified recording device, you'll see your voice on the scope and the FFT (a frequency spectrum). You'll also hear your voice delayed by two seconds through your speakers. If there is too much feedback from your speakers to your mike, you could get in a feedback loop, so be ready to stop the playback or turn the volume down!
That was simple and you really don't need to know Python to make it work. You also don't need to know how to buffer audio from sound cards and other exotic techniques. Next time, I'll tell you more about the SDR USB device and how to use it to build (virtually) an FM radio.