Listening to FM Radio in Software, Step by Step
My article “GNU Radio: Tools for Exploring the Radio Frequency Spectrum” [LJ, June 2004] provides an overview of how the GNU Radio system works and discusses a couple hardware options for getting the RF signals digitized and into the computer. This article takes a look at how to use GNU Radio to listen to FM radio.
The hardware setup used in this article is shown in Figure 1. It's the brute-force, no-frills approach and is good for explaining how everything works. Later in the article, we discuss the Universal Software Radio Peripheral (USRP) and what it can do for you.
Our setup consists of a conventional FM dipole antenna, a cable modem tuner module mounted on an evaluation board and a 20M sample/second PCI analog-to-digital converter (ADC) card. The antenna plugs in to the input of the tuner module. The tuner module IF output is connected with a piece of coaxial cable to the ADC input on the back of the computer. The tuner module eval board is connected to the PC's parallel port so that we have a way of controlling the module.
The specific hardware we're using is a Microtune 4937 DI5 3X7702 cable modem tuner module and a Measurement Computing PCI-DAS 4020/12 ADC board. This particular tuner module is hard to get, but others, such as those from Sharp Microelectronics, ought to work fine (see the on-line Resources section).
The cable modem tuner functions as our RF front end and is responsible for translating the radio frequency signals that we're interested in down to a range that our ADC can deal with. In this case, the module translates a selectable 6MHz chunk of the spectrum in the range of 50MHz–800MHz down to a 6MHz chunk centered at 5.75MHz. For more background on these concepts, see the June article mentioned previously.
First off, let's take a look at what happens when we tune our front end to the middle of the FM band, say 100.1MHz. Figure 2 shows the received samples vs. time. This view, the time domain, is what you'd see on an oscilloscope. It's not particularly enlightening, but it does show that our samples are in the range of –170 to –70, which is fine. In an ideal world, they would be symmetric about zero. For our purposes, the offset won't matter.
The frequency domain provides additional information. In this case, we grab 1,024 samples at a time and compute the discrete Fourier transform using the fast Fourier transform (FFT) algorithm. This gives us a representation of the frequencies that are contained in the input signal. Figure 3 shows the resulting spectrum. The x-axis is frequency, and the y-axis is power in decibels (10 * log10 power). The low end is at zero Hz, and the top end is at 10MHz, half our sampling rate.
Each of the spikes in Figure 3 is a radio station. Our software sees them all at once! To listen to a station, we need a way to separate it from all of the others, translate it to baseband (DC, 0Hz) and reverse the effect of the frequency modulation. We work through this step by step, but first let's talk about FM.
To understand how an FM receiver works, it's helpful to know a bit about how FM signals are generated. With FM, the instantaneous frequency of the transmitted waveform is varied as a function of the input signal. Figure 4 shows m(t), the input signal (the message, music and so forth), and s(t), the resulting modulated output. To be rigorous, the instantaneous frequency at any time is given by the following formula:
f(t) = k*m(t) + fc
m(t) is the input signal, k is a constant that controls the frequency sensitivity and fc is the frequency of the carrier (for example, 100.1MHz). Remember that frequency has units of radians per second. As a result, frequency can be thought of as the rate at which something is rotating. If we integrate frequency, we get phase, or angle. Conversely, differentiating phase with respect to time gives frequency. These are the key insights we use to build the receiver.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Linux In Government: Interoperability
- Linux in Government: Winning in the Big Enterprise Space
- Linux in Government: Open Source Innovation within the DoD
- Linux in Government: An Interview with John Weathersby of OSSI
- Linux in Government: GNU/Linux Clears Procurement Hurdles
- Convert Filenames to Lowercase
- Tech Tip: Really Simple HTTP Server with Python
- Getting Started with Salt Stack-the Other Configuration Management System Built with Python
- Concerning Containers' Connections: on Docker Networking
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide