SOFTWARE-DEFINED RADIO (SDR) is a relatively new technology but one that many people use daily but are not aware of. SDR is a key component of most modern cell phones. If SDR did not exist, then the same would likely be true of cell phones and a lot more technology on which modern societies depend. This chapter’s purpose is to make you aware of the basic SDR functions through some fun experimental projects using a RasPi and a few inexpensive SDR parts. However, before I launch into the projects, I believe a brief background discussion on how SDR functions should enrich your experience.
Most readers are already likely familiar with these basic concepts, but a quick review never hurts. All radio communications rely on a carrier wave, which is typically a constant-frequency, constant-amplitude electromagnetic radiofrequency (RF) wave (shown graphically in Figure 7-1 ).
The waveform shown in the figure is also called a continuous wave (CW), and it “carries” information via a process known as modulation . Technically, the CW carrier can transmit information alone simply by being switched on and off in a predefined manner representing the information or data. This operational mode is commonly known as Morse code or the more familiar “dit-dahs” associated with amateur radio operations.
Figure 7-1 Radio carrier wave.
Three very common modulation techniques are used in RF communications:
Amplitude modulation (AM).
This modulation method changes the amplitude of the RF carrier in direct correspondence to the data being transmitted.
Frequency modulation (FM).
This modulation method changes the
instantaneous frequency of the RF carrier in direct correspondence to the data being transmitted.
Phase modulation (PM).
This modulation method changes the instantaneous phase of the RF carrier in direct correspondence to the data being transmitted.
There are many other modulation schemes in current use, but almost all are some combination of the basic modulation schemes just detailed. FM will be used for this chapter’s projects because FM is the scheme used by the data transmitters being monitored. Figure 7-2 shows a carrier wave that was frequency modulated by two digital pulses.
Figure 7-2 Digital pulse FM waveform.
The waveform modulation is apparent in the figure by the close spacing of the peaks and troughs of the CW carrier, while the digital pulses are in their high state. This change in frequency is called deviation and is directly proportional to the amplitude of the data signal. For digital signals, the deviation typically will be 0 Hz for the low portion and approximately 5000 to 10,000 Hz for the high portion. This type of FM is two-state modulation, with either a 0- or 10-kHz deviation appearing in the waveform. I will not be discussing how to implement digital FM transmission because this chapter’s project is focused only on receiving and decoding radio waves using SDR techniques.
The process of receiving and retrieving data sent by digital radio involves two techniques known as heterodyning and demodulation . Heterodyning involves the use of a radio tuner whose purpose is to convert the very high-frequency (VHF) radio wave to a much lower-frequency wave known as an intermediate frequency (IF). This IF is then sent to the demodulator. Demodulation is the precise counterpart to modulation, which encoded the original transmitted RF wave. As such, you would require an FM demodulator to decode the received FM radio wave.
In an analog FM receiver, an initial RF mixer is used to initially translate the VHF radio waves to a much lower IF, usually about 10.7 MHz for consumer FM radio. You may have heard of super-het radios, which are simply radios containing multiple heterodyne stages used to increase receiver selectivity. Figure 7-3 shows a block diagram of a typical analog FM receiver RF front end.
Figure 7-3 Analog FM receiver RF front-end block diagram.
The LO shown in the figure is short for “local oscillator,” whose purpose is to generate a RF signal precisely equal to the carrier frequency. The mixer shown in the figure generates sum and difference frequencies when the received RF signal is “mixed” with the LO frequency. Only the difference frequency is used because it contains the useful data signal. The RF amplifier shown in the figure amplifies the relatively weak RF signal coming from the antenna before it is put into the mixer. This greatly improves the signal-to-noise ratio, which is effectively the radio’s dynamic range. A wide dynamic range enables the radio to handle both strong and weak signals efficiently. You will shortly see that SDR dongles also have RF amplifiers, but they are termed low-noise amplifiers (LNAs).
The IF from the tuner is next sent to the demodulator. This signal contains a replica of the original data in the form of two analog signals: the I and Q waves, as shown in Figure 7-4 , which is a simplified block diagram of an analog demodulator.
Figure 7-4 Block diagram of an analog demodulator generating I and Q waves.
The I wave is an in-phase replica of the original data, while the Q wave is a quadrature or 90° out-of-phase replica of the same signal. Both I and Q waveforms are needed by the SDR to complete the demodulation process and re-create the original data.
While the classic demodulation circuit is still widely used in modern radios, SDR typically employs another circuit that is highly effective and is a good match to meet SDR requirements. This circuit is called the Tayloe detector and is shown in the block diagram in Figure 7-5 .
Figure 7-5 Block diagram of a Tayloe detector.
I will not provide a detailed description of the operation of a Tayloe detector other than to say that the incoming IF signal is sampled and “held” for a very brief time such that the I and Q signals can be extracted from the received waveform. The switching or commutation speed denoted as Fc in the figure is set as one-quarter of the sampling frequency Fs . Fs , in turn, is set at the IF, which is typically at or below 10 MHz for SDR dongles. The switching and sampling actions are accomplished in a single digital demodulator chip, which I discuss in a later section.
The next section details how the SDR uses the I and Q signals to re-create the original data signal.
The next step in the SDR processing sequence is to convert the I and Q waveforms into their digital representations. This is accomplished by using two 8-bit analog-to-digital converters (ADCs), as shown in Figure 7-6 .
Figure 7-6 SDR digital signal-processing block diagram.
The two newly digitized waveforms are then sent serially over a USB connection to a computer, which is running the actual SDR program. The digitization and conversion of the I and Q data streams are also done in the same chip described in the preceding section.
The blocks shown in the figure’s computer-designated area represent logical processing modules and not any actual hardware. This virtualization of hardware is the essential feature of SDR, which makes it so versatile. The abbreviations in the figure are detailed as follows:
ADC
: analog-to-digital converter
FFT
: fast Fourier transform
IFFT
: inverse fast Fourier transform
FIR
: finite-impulse filter
F
s
: sampling frequency
I will not discuss how this block diagram functions because it is not critical to implementing the project. I will say that the logical blocks will change according to the type of signal being processed. This diagram is suitable for digital, narrow-band FM demodulation, while a completely different diagram might be used for single-sideband voice demodulation. Such a difference only requires changes in the program code but no changes as far as the I and Q signals are concerned.
In addition, the associated data displays are completely software dependent, which again makes it so easy to accommodate the various types of radio signals to be handled by the SDR system. This chapter’s project will use a simple console display to show the received text messages. Other displays can and usually are far more sophisticated. I refer readers to investigate Flex Radio’s PowerSDR software to see an excellent example of a professional SDR control and display program. It is freely available and has a demo mode by which you can run it without attached hardware.
The demodulated signal line shown at the far right in Figure 7-6 can be linked to more software modules to further process the received signal. In our case, the demodulated signal will be decoded to reveal the text messages contained in the original radio signal. Other SDR systems might have actual voice, which would require a digital-to-analog converter (DAC) to change the digital signal back into its original analog form suitable to be heard.
At this point, it is time to discuss the project because I believe that I have provided you with a sufficient background in SDR technology to understand what happens when you actually run it.
The key piece of hardware required for this SDR project is actually a digital TV tuner device, affectionately termed an SDR dongle . Figure 7-7 shows the SDR dongle used in this project.
Figure 7-7 SDR dongle.
How the dongle TV tuner became an inexpensive SDR is a bit of a serendipitous story. Back in 2010, a fellow named Eric Fry was experimenting with this dongle type using a packet sniffer, hoping to get a digital TV broadcast data stream (DAB+) working with a Linux application. He confirmed that the I and Q signals generated by the dongle were suitable for not only DAB+ but also for the more general VHF signals not necessarily related to TV broadcasts. Eric and Antii Palosaari confirmed that the Realtek 2832U chip contained in the TV tuner dongle was perfectly capable of creating a wide range of I and Q signals suitable for use in SDR applications. Things progressed rapidly from that point, thanks to many smart and clever open-source developers. Today, quite a few SDR programs are available, including one made specifically for the RasPi, which I will use in this project.
Returning to Figure 7-7 , you will notice that there is a small antenna connector located on the side. This is a U.FL micro coaxial connector, which is designed to be used with the small, collapsible stick antenna that is normally supplied with the dongle when you buy the package. Figure 7-8 shows this antenna with its cable connector.
Figure 7-8 Collapsible stick antenna.
Now the small stick antenna might be fine when used in a strong signal area, but I found it to be a very poor performer where I live, in a somewhat rural area. I therefore purchased a U.FL-to-BNC adapter, which allowed me to connect an excellent outdoor VHF antenna to the dongle. Figure 7-9 shows this adapter, which I highly recommend along with an outdoor antenna because it will help to turn your SDR dongle into a viable receiver.
Figure 7-9 U.FL-to-BNC adapter.
All SDR dongles have two main components: the tuner chip and the demodulation chip. All SDR dongles use the Realtek RTL2832U demodulation chip, which leaves the tuner chip as the principal difference between dongles. Some are better than others depending on your specific requirements. Table 7-1 lists all the available tuner dongles at the time of this writing along with their covered frequency bands.
Table 7-2 is list of all the available dongles along with their tuner.
TABLE 7-2 Available SDR Dongles
NOTE
Data for Tables 7-1 and 7-2 were obtained from the Osmocom.org website.
The vendor ID (VID) and product ID (PID) are also listed in Table 7-2 to help verify the dongle in use. Both the VID and PID are enumerated when the USB connection is made and may be read from the display console when the appropriate command is issued. I plugged the generic SDR dongle I purchased into my MacBook Pro and issued this command in a terminal window:
Figure 7-10 is portion of the resulting display concerning the dongle.
Figure 7-10 USB enumeration for a generic SDR dongle.
The VID was 0x0bda, confirming it was a Realtek chip, and the PID was 0x2832, confirming that it was also a genuine RTL2832U. I had purchased a generic SDR dongle package on eBay, and I had previously determined that it had a Rafael Micro R820T tuner. I will also demonstrate how to determine the VID and PID using the RasPi when I discuss software installation.
A good antenna, an SDR dongle, and a RasPi are all the hardware needed to build your own SDR receiver. Of course, installing the proper software also will go a long way toward ensuring that you have a great SDR experience. The next section shows you how to install a great software package named rtl-sdr, which will allow you to monitor some status data sent from commercial aircraft.
To start, I will show how to install the rtl-sdr software package. It has essentially all that is needed to get the SDR dongle up and running. After completing the rtl-sdr installation, I will show how to install the GNU Radio software package, which contains some enhanced packages that provide additional functionality to the SDR experience. You should install rtl-sdr first because it has some important configuration steps that are needed to ensure that the SDR dongle works properly with the RasPi.
Please carefully follow all the following steps in order to install the rtl-sdr
software library. Note that you may have already completed some of these steps from an earlier project, but that’s okay. The RasPi will simply report that the particular software package is already installed and no action was accomplished. You also will need the RasPi connected to the Internet to download the required software libraries.
1.
sudo apt-get update
2.
sudo apt-get install git-core
3.
sudo apt-get install git
4.
sudo apt-get install cmake
5.
sudo apt-get install libusb-1.0-0-dev
6.
git clone git://git.osmocom.org/rtl-sdr.git
7.
cd rtl-sdr
8.
mkdir build
9.
cd build
10.
cmake ../-DINSTALL_UDEV_RULES=ON
11.
make
12.
sudo make install
13.
sudo ldconfig
14.
cd ~
15.
sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/
You will next need to create a new configuration file to deactivate the TV DVB driver that was installed by default when the rtl-sdr
package was loaded. Technically, this is known as a Dump1090 failure
, but the fix is relatively easy. Follow these steps:
1.
cd /etc/modprobe.d
2.
sudo nano no-rtl.cong #
(Create a new file using a nano named no-rtl.conf.)
3. Add these lines to the new file:
4. Save and close nano.
Next, plug the SDR dongle into the RasPi, and enter the following command to check the USB enumeration:
This command displays the following regarding the SDR dongle:
This result confirms that the RasPi successfully enumerated the dongle and that the VID and PID matched what was expected. You now need to create a new rule that will allow non-root users to access the dongle. You do this by creating a new rules file using the nano editor:
1.
sudo nano /etc/udev/rules.d/20.rtlsdr.rules
2. Add this line into the file:
3. Save file and exit nano editor.
4.
sudo reboot
After the reboot completes, enter this next command to determine whether the rtl-sdr
installation was successful:
You should see what is shown in Figure 7-11 if you had a good installation.
Figure 7-11 Successful rtl-sdr installation test.
Note that no antenna is needed for this test because it only checks whether samples are being sent from the dongle to the RasPi. The next test will require an antenna because you will try to tune to a local FM station. You probably can use the small stick antenna for this test because most likely you will have available a very strong signal from a local FM station. The following is the command I entered to conduct this test. Obviously, the FM station frequency you enter will differ unless you happen to live in my neighborhood.
NOTE
The FM frequency I used was 97.5. Change this to suit your requirement, but keep the e6
suffix because it represents a million. All the other command elements should be unchanged.
After I entered this command, I immediately heard the local FM station audio coming from my monitor’s speakers because the RasPi was connected using an HDMI cable to the monitor. If you do not have this arrangement, then you should use the RasPi’s headphone jack to listen to the audio output. Enter the following command to ensure that the audio is being directed to the headphone jack:
The last test I conducted was really more of a proof-of-performance check. This test involves trying to determine the maximum sample rate that could be set before any data packets are dropped or lost. This next command sets the sample rate at 3.2 × 106 samples per second, which is above the maximum sample rate that most SDR dongles can effectively handle:
Figure 7-12 shows that packets were being consistently lost, which would result in poor to nil data reception.
Figure 7-12 Maximum sample data rate test output.
I next reran the test using lower and lower sample rates until packets were no longer being dropped. I determined that a sample rate of 2.76 × 106
was the maximum that could be used with no data being dropped or lost. This sample rate is probably very typical for commodity SDR dongles and more than adequate to meet all rtl-sdr
software package requirements.
At this point, you are ready to install the GNU Radio package, which will enable the SDR dongle to receive a great variety of signals.
The GNU Radio software package is not contained in the current Debian Wheezy release but instead is a part of a testing release named jessie . Fortunately, it is easy to access the jessie packages from Wheezy simply by adding the jessie repository to the Wheezy sources list. You do this by using the nano editor and following these steps:
1.
sudo nano /etc/apt/sources.list
2. Add this line into the file:
3. Save the file and exit the nano editor.
4.
sudo apt-get update
You will now need to download and install the GNU Radio runtime and development software packages. Please be patient because it does take a while to complete this 351-MB installation. Enter the following command to start the install:
After the install finishes, you still have one more package to install, which contains some higher-level GNU Radio applications. Enter this command:
Please notice that the great folks at Osmocom created these applications to enhance the SDR experience. In fact, enter the following command to see one of these applications run:
Figure 7-13 shows a screenshot from the RasPi while this application was running.
Figure 7-13 osmocom_fft screenshot.
This application runs a fast Fourier transform (FFT) on the sampled data streaming from the SDR dongle. FFTs transform time-sampled data into their equivalent frequency-domain data points. The figure shows a region of these frequency data points or spectrum centered at 895 MHz with a split bandwidth of ±125 kHz or 250 kHz of total bandwidth. This is a relatively narrow bandwidth when you consider that the carrier frequency is 895 MHz. Using such a narrow bandwidth allows for some very close scrutiny of the RF wave, but more important, it provides excellent selectivity, which helps to “pull” true data signals from the noise.
I have included the following sidebar for readers who wish to learn a bit more about FFTs. Feel free to skip it and just realize that time and frequency data are two sides of the same coin. You can’t have one without the other.
A classic sine waveform signal is shown in Figure 7-14 , where the vertical axis is amplitude measured in voltage and the horizontal axis is time in milliseconds (ms). The period of this signal, or time between positive peaks, is shown in the figure as 1 ms. This period measurement means that the signal repeats itself 1000 times per second. The inverse of the period is called the sine wave’s frequency , which in this case would be equal to 1000 Hz. Hertz (Hz) used to be known as cycles per second (cps), but I think that it is far better to use the Hz suffix. This frequency is plotted in Figure 7-15 using a horizontal scale of hertz, while the vertical axis is in decibels (dB) referenced to 1 V, which is typical for frequency spectrum plots.
Figure 7-14 Sine wave time plot.
Figure 7-15 Sine wave frequency plot.
The famous mathematician Jean-Baptiste Joseph Fourier discovered many years ago that any arbitrary continuous mathematical waveform could be represented by an infinite series of sine waves. Of course, if the initial waveform was only at a single frequency, then obviously only one sine wave would be necessary, as shown in Figure 7-15 . However, if you were to represent a perfect square waveform using sine waves, then you indeed would need an infinite number of sine waves to accomplish that feat. Figure 7-16 is a replica of a spectrum analyzer plot for a 1-kHz square wave showing the initial sine waves needed in this series up to 20 kHz.
Figure 7-16 Square wave spectrum.
The 1-kHz square wave spectrum starts with a 1-kHz sine wave and then an additional 3-kHz sine wave, 5-kHz sine wave, and so on. Note that all the sine wave frequencies beyond the first one are at odd harmonics of the initial sine wave, which is also known as the fundamental harmonic . In addition, the amplitudes of all the odd harmonics decrease as their frequency increases. Spectrum displays are very useful and can provide much information about a signal that is not obvious from viewing a time-based display of that signal.
The data stream coming from the SDR dongle is in the form of digital numbers representing sampled values of the analog waveform. Figure 7-17 shows how these samples relate to the original waveform.
Figure 7-17 Sampled sine wave.
The problem now is how to convert these digitized samples into a matching digitized Fourier transform. The answer lies in the use of an algorithm known as the discrete Fourier transform (DFT). Through a series of trigonometric multiplications and summations, a sampled time series can be converted into its DFT. However, an inherent problems arises with the DFT in that it is computationally very expensive, meaning that it takes a long time to do a single transform given any reasonably sized sample set. The number of operations is approximately N 2 , where N is the size of the sample set. For a relatively small sample set of 1000, this would mean that it would take approximately 1 million operations just to compute one DFT. Of course, with larger sets, the increase in time would grow exponentially larger. This was an unattractive option even with extremely fast computers.
The solution to the roadblock arose in the mid-1960s with the creation of the fast Fourier transform (FFT). Two brilliant IBM scientists named Cooley and Tukey published a paper showing the world how to compute a DFT using a clever scheme that reduced the number of mathematical operations from N 2 to N × log2(N ). This last notation should be read “N times the log of N to the base 2.” For example, the number of operations for a 1024 sized data set goes from slightly over 1 million for the DFT to 10,240 for the FFT, a reduction of almost 100 to 1. Real-time FFT computations thus were made possible. Today, every application that converts sampled time data to frequency data uses the FFT. Amazingly, IBM never patented or protected this intellectual property and graciously made it available to everyone for the promotion of science and technology.
The SDR dongle is well suited to receiving aviation data signals, of which there are plenty constantly being broadcast. This next section describes how to monitor Mode-S transponders.
An aircraft Mode-S transponder consists of a radio system that transmits a data packet when it receives an incoming radar ping from an air traffic control (ATC) facility. It is important to realize that receiving these data packets will in no way harm or affect any aircraft operations.
Much of the following was based on a blog from Andrew Beck describing the gr-air-modes
software package, which allows the SDR dongle to receive Mode-S airborne data signals. Enter the following command to start building this software:
The source code has to be downloaded next by entering this command:
The next steps in this process involve building and installing the source code. Follow these steps to complete the software installation:
1.
cd gr-air-modes
2.
mkdir build
3.
cd build
4.
cmake ../
5.
make
6.
sudo make install
7.
sudo ldconfig
The application is now run by entering the following command:
Figure 7-18 shows an output from this program. There are only a few entries because the location where I ran the program was a poor reception area for these types of signals.
Figure 7-18 Example output from the modes_rx application.
Mode-S signals are not the only interesting aviation data packets that may be monitored using an SDR dongle. The next section describes another airborne data type that you may be interested in checking out and was also involved with an incident that made the worldwide news.
Have you ever wondered as you gazed at contrails high in the deep blue sky where those airplanes were coming from or going to? The Aircraft Communications Addressing and Reporting System (ACARS) is your answer. It is a digital data-link system for the transmission of short messages between aircraft and ground stations via airband radio or satellite. The ACARS Protocol was created and deployed in 1978 and follows the Telex format. It was designed by Aeronautical Radio, Inc. (ARINC) to promote safe and efficient airline operations. ACARS includes both Airline Operational Control (AOC) and ATC digital messages with an average message volume split of 80 percent for AOC and 20 percent for ATC. Table 7-3 shows the variety of information sent through ACARS.
As you can see from the table, a great deal of information is constantly being exchanged between an aircraft and appropriate ground stations. The ACARS system is autonomous in operation and cannot be shut down by the pilots. This fact played a key role in the search for the Malaysia Airlines MH380 that disappeared several years ago over the southern Indian Ocean. For unknown reasons, all the pilot-controlled communications with the ground ceased as the aircraft deviated from its preplanned flight path. However, ACARS continued to broadcast from the plane for several hours until it suddenly stopped. ACARS transmissions to satellites provided valuable tracking data to forensic engineers, which allowed them to provide searchers with probable locations to begin searching for the aircraft.
This procedure presumes that you already have downloaded and installed the rtl-sdr software package, as described earlier in this chapter. The ACARS package depends on having rtl-sdr available and in working order. Please follow these next steps in the order presented. Note that the version I downloaded was 3.1, but this might change when you download it because upgrades are constantly being done to this software. I would check the website http://sourceforge.net/projects/acarsdec/ to determine the current version. Then substitute that version number for 3.1 wherever it appears in these procedural steps:
1.
cd ~
2.
mkdir acars
3.
cd acars
4.
wget http://sourceforge.net/projects/acarsdec/files/latest/download
-O acarsdec-3.1.tar.gz
5.
tar xvfz acarsdec-3.1.tar.gz
6.
cd acarsdec-3.1
7.
sudo apt-get install libsndfile1-dev
8.
sudo apt-get install libasound2-dev
9.
sudo apt-get install librtlsdr
10.
sudo ldconfig
11.
make
I have also included Figure 7-19 , which is a screenshot of the acarsdec help page to explain the options that are available when you run this application.
Figure 7-19 acarsdec help screen.
Notice that the -p
option is a frequency correction, which is in parts per million. Correcting the receiver frequency should allow the tuner in the dongle to promptly lock onto the desired ACARS frequency. The next section details a calibration procedure to determining the appropriate frequency correction value.
Let me start by stating that the program used to determine the calibration value is actually named Kalibrate . This program uses any nearby cellular GSM base station as a frequency reference. In the United States, the AT&T cellular network uses GSM, which should mean that a base station will likely be able to be heard by the dongle. I believe that GSM is also widely used in Europe and likely as well in other parts of the world.
Please follow these steps to install and configure the Kalibrate program:
1.
mkdir ~/kal
2.
cd ~/kal
3.
sudo apt-get install libtool autoconf automake libfftw3-dev
4.
git clone https://github.com/asdil12/kalibrate-rtl.git
5.
cd kalibrate-rtl
6.
git checkout arm_memory
7.
./bootstrap
8.
./configure
9.
make
10.
sudo make install
Please be patient because some of these steps do take some time to complete.
Enter this next command to determine any local GSM channels that can be received:
Figure 7-20 shows the result of my initial GSM frequency search. Your results will be different depending on the local GSM base station configuration.
Figure 7-20 Initial GSM frequency search.
As you may clearly see, I received only two GSM channels owing to the poor RF reception in my location. But that’s okay because some data regarding frequency correction is much better than none.
You will next need to have kal compute the frequency offset. Select two of the channels with the largest power values and separately enter their channel numbers into kal to do an offset computation. Use the following command template:
Figure 7-21 shows the result of one of these frequency-offset computations for one of my two GSM channels.
Figure 7-21
kal
frequency-offset computation.
The average absolute error shown in the figure is –32 ppm, so the correct offset would be +32 ppm because you are correcting for the error in absolute frequency. I would strongly suggest that you rerun the offset computations several times and then average all the resulting offset corrections to arrive at a representative value for the true dongle frequency correction. I reran the offset computations three times for each channel and found that the values returned were very close. My final average offset correction was +29.9, which was rounded to the nearest whole integer, or +30.
You should next try to run the acarsdec program using the computed frequency correction as I did in the sample-run section.
Before you can properly run the acarsdec program, you will need to know the ACARS frequencies that are in use for your region in order to monitor these data. Table 7-4 is a current ACARS frequency list.
TABLE 7-4 ACARS Frequency List
CAUTION
The acarsdec program is a multichannel receiving program, meaning that it is capable of simultaneously receiving up to four separate ACARS radio channels. However, because of a sampling constraint, there cannot be more than 625-kHz bandwidth separating the highest and lowest channels. This means that monitoring 131.550 and 131.025 is permissible, but trying to monitor 131.550 and 129.125 is not and will generate the error shown in Figure 7-22 .
Figure 7-22 acarsdec frequency-separation error.
The program will still appear to be operating, but it will not display any results.
I entered the following command to run the multichannel ACARS decoder application at my home. Note that I used two of the frequencies from Table 7-4 that were appropriate for my region and within 625 kHz of each other.
Figure 7-23 shows a sample of the ACARS messages received after I entered the preceding command.
This figure is a composite of some of the messages I received while I monitored the ACARS for approximately 1 hour. I do wish to further explain two messages that appear at the start of the figure because it will highlight why ACARS is so interesting. These two messages were sent 6 seconds apart from an aircraft that was flying over my home. The messages themselves do not contain anything of substance other than the aircraft registration and flight ID, which in this case were N822NW and NW0065, respectively. A quick Google search revealed that N822NW was an Airbus 242t A330-300 registered to Delta Airlines, which also meant that the flight ID referred to Delta Flight 0065 because NW is Delta’s company designator. I next made a quick check on Flight Aware’s website (www.flightaware.com ) and entered Delta 65 as the flight number. Figure 7-24 shows the actual track of this aircraft, and you can see that it was over my home state of New Hampshire when I queried its status on the Flight Aware website.
Figure 7-24 Delta flight 65’s Flight Aware track.
Figure 7-23 ACARS messages received at my home.
Figure 7-25 shows much more information regarding the point of origin and destination for this flight.
Figure 7-25 Flight itinerary for Delta flight 65.
Finally, I was interested in the aircraft itself. It turns out that this Airbus A330-300 is the newest addition to Delta’s fleet and is used primarily for long-range trips such as this nonstop from Italy to Washington, DC. The 242t in the model descriptor refers to the gross weight, which is 242 metric tons, where 1 metric ton is equal to 1000 kg. Translated, this means that this type of aircraft carries almost 300 passengers. I believe Delta is replacing its 747 aircraft with this new type because it is so much more fuel efficient while carrying the same approximate payload of passengers and baggage. Figure 7-26 shows the aircraft that flew over my home that day.
Figure 7-26 Airbus 242t A330-300, Delta N822NW.
I was also curious as to how the ACARS monitoring would function at a commercial airport, so I traveled to my closest airport, which was at Manchester, NH (KMHT is the IAOC designator). I needed to make my system completely portable, so I used a battery-operated 7-inch HDMI monitor for the display and ran the RasPi, SDR dongle, keyboard, and mouse using an external cell phone battery eliminator, which I discuss in a later section. Figure 7-27 shows a composite of some of the ACARS messages I monitored while being parked about a half mile from the airport. I only used the stubby antenna with this system, and it worked perfectly because the signals were quite strong.
Figure 7-27 ACARS messages received at KMHT.
Several messages in this figure refer to an aircraft with registration N339NG, but no flight ID is shown. A quick check on Google for this registration number revealed that it was a United Express Dash8-400 twin turbo-prop commuter airliner that just happened to be passing overhead coming from Liberty Airport in Newark, NJ, and going to Portland, ME (KPWM). The messages associated with this flight contained some ATC content consisting of the current weather conditions at KPWM. These types of messages are known as METARS and are used extensively in aviation worldwide. In this case, I decode the METAR in the following sidebar for your information and to help you decipher any similar messages that you might monitor.
The next section changes the pace a bit. I will show you how to build and use a portable spectrum analyzer.
This section is based on a great tutorial by Tony DiCola that is available from learn.adafruit.com . In this SDR project, I used a dongle, a RasPi, and a PiTFT touchscreen display, which is the same one that was used in the Chapter 2 project. I mentioned back in Chapter 2 not to dismantle the project if you intended to complete this project. I will refer you back to the Chapter 2 discussion on how to install the PiTFT on a RasPi and use a custom case if you are so inclined. No other hardware installation is necessary because the SDR dongle simply plugs into one of the RasPi USB ports. Figure 7-28 shows the PiTFT mounted in the PiBow case along with the SDR dongle plugged into one of the RasPi’s USB ports. I also used a USB extension adapter, which allowed me to plug additional USB cables into the RasPi’s ports, which might otherwise be blocked by the dongle.
Figure 7-28 Spectrum analyzer assembly.
The RasPi also was connected to the Internet with an Ethernet patch cable. The whole assembly was powered by a wall-wart cube, which I highly recommended during the software installation. Later on in this section I discuss how to make this project completely portable, which includes making it battery powered.
The next section discusses the software installation, which is the key to a successful project.
This project requires a fresh rtl-sdr installation in order to properly configure the RasPi with the PiTFT. I would not suggest trying to overlay this project’s software with the previous rtl-sdr software because this software package uses Python and some other modules not found in the previous package. Just start with a fresh Wheezy distribution and you should be fine.
NOTE
I used an SSH connection from my MacBook Pro to the RasPi to accomplish all the following steps.
Please follow these steps to start the installation and configuration:
1.
sudo apt-get update
2.
sudo apt-get install cmake build-essential python-pip libusb-1.0-0-dev python-numpy git
3.
cd ~
4.
git clone git://git.osmocom.org/rtl-sdr.git
5.
cd rtl-sdr
6.
mkdir build
7.
cd build
8.
cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
9.
make
10.
sudo make install
11.
sudo ldconfig
12.
sudo pip install pyrtlsdr
The preceding steps have downloaded, built, and installed all the dependencies required for the source code. The next steps are to download and run the application named freqshow . Follow these three steps to do this:
1.
cd ~
2.
git clone https://github.com/adafruit/freqshow.git
3.
cd freqshow
All that is needed now is to run the program. Plug in the SDR dongle with an antenna attached and ensure that you are in the freqshow folder. Enter the following command:
Figure 7-29 shows the PiTFT screen in the instantaneous frequency spectrum display mode.
Figure 7-29 PiTFT screen displaying an instantaneous frequency spectrum.
The 97.5-MHz peak is the very strong radio signal from a local FM station. The 51-dB level shown on the left of the display indicates that it is indeed a very intense signal.
Touching the Switch mode button will change the screen display from the instaneous frequency to a waterfall display. This display is shown in Figure 7-30 for the same 97.5-MHz FM radio station signal.
Figure 7-30 Waterfall display.
The waterfall display plots the signal intensity versus time, with the latest traces starting at the bottom and scrolling to the top. The traces are color-coded, with blue being a weak signal and red being the strongest. The 97.5-MHz signal in the center of the waterfall is quite red, indicating that it is the most intense signal shown within this particular spectrum bandwidth. Many experienced radio operators feel that the waterfall display is by far the best way to detect weak signals that are embedded in a noisy spectrum. The characteristic line is easy to discern. while a small peak that is bobbing around in an instantaneous display is almost impossible to detect.
Setting the center frequency is simply a matter of touching the Config button in the top left-hand corner. Once you do this, the screen shown in Figure 7-31 appears.
Figure 7-31 Config input screen.
Touch the Clear button to remove the existing entry, and then touch the buttons for the new center frequency. Figure 7-32 shows the entry for a 315-MHz center frequency. You must click the Accept button to enter the new frequency into the program.
Figure 7-32 New center frequency entered.
I chose the 315-MHz center frequency to see if I could monitor the transmissions from a small RF key fob that I had used in a previous experiment. Sure enough, the analyzer detects the transmission, as shown in Figure 7-33 . I did have to fiddle with the camera shutter and the key fob to capture the instant the data packet was sent.
Figure 7-33 315-MHz key fob transmission.
My last test used a hand-held amateur radio transmitter set to the 2-m band at a frequency of 145.000 MHz. Please do not try this unless you are a licensed amateur radio operator, as am I. Figure 7-34 shows that the carrier wave was precisely at 145 MHz, as I expected.
Figure 7-34 145.000-MHz CW transmission from an amateur radio transceiver.
In the next section, I will show you how to make this analyzer completely portable and boot right up into the freqshow
program.
It would certainly be advantageous to make the spectrum analyzer completely portable, meaning that it would be self-contained and battery powered. It would also need to be booted directly into the analyzer control program because it is not practical to carry around a keyboard to manually enter the login information. It turns out that it is relatively easy to do both these tasks.
The RasPi and PiTFT are already in a PiBow case, as described in Chapter 2 and shown in Figure 7-29 . No more physical modifications are required with regard to the physical case. The battery-operation part was also very easy in that I used an external cell phone power pack, as shown in Figure 7-35 .
Figure 7-35 External power pack.
This particular power pack is rated at 5600 mAh, which should power the analyzer for at least 5 hours, assuming an average current draw of approximately 1 A.
Having the RasPi boot directly into the Python program named freqshow.py does require a series of modifications to several files. All the changes are noted next. Just carefully follow the steps and you should be fine.
NOTE
I used the nano editor to make all these changes.
1. The file /etc/inittab needs to modified as follows: comment out the line that starts with:
and replace it with:
2. Add this line to the bottom of the file /etc/profile:
3. Make these two additions/changes to the freqshow.py code:
a. Add this line to the very top of the program:
b. Change the line:
to
4. Do a reboot:
Now you can try the auto login by disconnecting and reconnecting the RasPi power supply. I know that it is probably not the best way to reboot, but it is the only way I know of to reboot with the RasPi, which lacks any proper reset or power-switch circuitry. The PiTFT should now display the instantaneous frequency spectrum, as shown in earlier figures.
Figure 7-36 shows the complete kit for the portable spectrum analyzer, including the battery and antenna. There is also a waterfall display shown on the PiTFT receiving two local FM stations.
Figure 7-36 Complete portable spectrum analyzer kit.
This last section concludes my experiments with this portable spectrum analyzer. I will say that it was very easy to use and had a remarkably clear display. It certainly would be useful in many situations where you might need to determine the properties of unknown RF transmissions. Commercial units with similar characteristics cost many hundreds of dollars. This project cost less than US$100 and had the additional advantage of being an educational experience.
I began this chapter with a brief review of some fundamental radiofrequency (RF) concepts because they should help you to understand the important ideas behind software-defined radio (SDR). I and Q signals were discussed next because they are key components in creating a functioning SDR system. SDR simply will not work without I and Q signals. The next section discussed the low-cost SDR dongles that are readily available along with their constraints and limitations. However, having a US$10 to US$20 SDR dongle available to experiment with is really quite a remarkable bargain.
The key rtl-sdr library was next discussed. I showed you how to receive and listen to an FM station using an application contained in the library. The GNU Radio software package was installed next because it is a prerequisite to monitoring many different types of aviation data signals, including Mode-S transponders and ACARS data packets. I went into several in-depth demonstrations of how to monitor and decode ACARS transmissions. I believe that you find this to be a very interesting subject once you start monitoring these aviation signals.
The chapter concluded with another demonstration project of a portable spectrum analyzer based on using the PiTFT-RasPi combination discussed in Chapter 2 . This project used the SDR dongle to receive and display small sections of spectrum ranging from 24 MHz up to 1766 MHz.
