Rob Rhinehart
A portrait of the engineer as a young man
A Modern Software Defined Radio for the Masses
Lately while reading up on Ham Radio I stumbled across Gerald Youngblood's (AC5OG) excellent article series "A Software Defined Radio for the Masses". It was a 4-part series published in QEX from August 2002 to April 2003. I strongly recommend anyone interested in DSP, Ham Radio, and especially Software Defined Radio (SDR) to read this series. Copies of the PDFs are listed below.
Again, the series is excellent but the implementation is Windows only, uses Visual Basic as well as an outdated version of DirectX, and relies on Intel's discontinued DSP library. (It seems it has since been folded in to their Math Kernel Libraries (MKL) which is not free). I aim to provide a cross-platform, more efficient software implementation. The Tayloe detector is an ingeniously simple mechanism for capturing the signal so the hardware will likely remain the same, but the software will be completely rewritten.
Hardware
Since Youngblood did such an excellent job of explaining above, I'll skip much of the DSP theory. Suffice to say, we are capturing a signal and feeding it to a PC's sound card for processing. The bread and butter of signal processing: mixing, downconverting, filtering, sampling, and analyzing, will take place entirely in software. This means it should be comparatively trivial to change the functionality of the system, such as switching modulation techniques or frequencies.
The hardware is purposefully kept to a bare minimum. The core is an ingenious device known as a Tayloe detector. See Youngblood's diagram for an explanation. Notice the overall hardware architecture contains very few components other than the Tayloe detector.
Software
The system uses Quadrature sampling, a technique enabling demodulation of virtually anything with just two values, the I (In-Phase) and Q (Quadrature) components. See Quadrature Signals: Complex but not Complicated by Richard Lyons. Try not to facepalm once you get the joke.
Software architecture from Youngblood:
Once the I and Q signals are passed to the sound card the software takes over. For this project I will first implement a 'mock up' in Python for clarity and ease of prototyping and then write the real version in C++ for performance. However, the Python implementation seems to be running quite fast so far, probably because I am utilizing the excellent NumPy and SciPy libraries, which have routines such as the FFT written in FORTRAN.
First I use PyAudio to capture the data from the sound card. The C++ implementation uses OpenAL for cross platform support. After sampling a "chunk" (1024 bytes), the bytestream is converted to an array of signed integers, and the Discrete Fourier Transform, or Fast Fourier Transform (FFT - a fast way to take the DFT based on the seminal Cooley-Tukey algorithm) is taken to convert the signal from the time domain to the frequency domain. The C++ implementation will either use a hand-written FFT routine or a trial version of Intel's MKL for performance. I am also investigating CuFFT, nVidia's massively parallel FFT implementation using the GPU. We now have an array of complex values (love Python's built in complex number support!) which we treat as cartesian in the complex plane and convert to Polar form. Now shift it to the Intermediate Frequency (IF) and demodulate appropriately.
If we are receiving CW (Carrier-Wave) signals we are pretty much done, but let's do SSB (Single Side Band) demodulation just to show the power and simplicity of the SDR. Now zero out the appropriate half of the array for sideband selection and run a simple convolution filter.
Now regardless of modulation technique we reverse the first few steps from before. Convert from Polar back to complex cartesian, and run the Inverse FFT (also provided by SciPy) to convert the signal back to the time domain. From here we can perform additional processing such as filtering and providing automatic gain control (AGC), and write to a .wav file or send it to the audio output buffer for listening.
I'm kind of a minimalist so most of my C and C++ experience is with gcc and vim on linux. For this project though I decided to teach myself Visual Studio and work with win32 and the microsoft compilers. Even though MSVC still doesn't even support ANSI99...it's good to have diverse experience. The finished code will compile and run on linux and mac as well.