--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+ "docbookx.dtd" [
+ <!ENTITY dial_tone_example SYSTEM "dial_tone_example.xml">
+ <!ENTITY fm_demod_example SYSTEM "fm_demod_example.xml">
+]>
+
+<article>
+<articleinfo>
+ <title>Exploring GNU Radio</title>
+ <author>
+ <firstname>Eric</firstname>
+ <surname>Blossom</surname>
+ <affiliation>
+ <address>
+ <email>eb@comsec.com</email>
+ </address>
+ </affiliation>
+ </author>
+
+<revhistory>
+ <revision>
+ <revnumber>v1.1</revnumber>
+ <date>2004-11-29</date>
+ <revremark>
+ Revised and expanded. Examples now use 2.x code base.
+ </revremark>
+ </revision>
+
+ <revision>
+ <revnumber>v1.0</revnumber>
+ <date>2004-02-29</date>
+ <revremark>
+ Initial version published in Linux Journal, Issue 122, June 2004, as
+ <emphasis>GNU Radio: Tools for Exploring the RF Spectrum</emphasis>.
+ </revremark>
+ </revision>
+</revhistory>
+
+<abstract><para>This article provides an overview of the GNU Radio
+toolkit for building software radios.
+</para></abstract>
+
+</articleinfo>
+
+<sect1 id="intro"><title>Introduction</title>
+
+<para>Software radio is the technique of getting code as close to the
+antenna as possible. It turns radio hardware problems into software
+problems. The fundamental characteristic of software radio is that
+software defines the transmitted waveforms, and software demodulates
+the received waveforms. This is in contrast to most radios in which
+the processing is done with either analog circuitry or analog
+circuitry combined with digital chips. GNU Radio is a free software
+toolkit for building software radios.</para>
+
+<para>Software radio is a revolution in radio design due to its ability to
+create radios that change on the fly, creating new choices for
+users. At the baseline, software radios can do pretty much anything a
+traditional radio can do. The exciting part is the flexibility that
+software provides you. Instead of a bunch of fixed function gadgets,
+in the next few years we'll see a move to universal communication
+devices. Imagine a device that can morph into a cell phone and get you
+connectivity using GPRS, 802.11 Wi-Fi, 802.16 WiMax, a satellite
+hookup or the emerging standard of the day. You could determine your
+location using GPS, GLONASS or both.</para>
+
+<para>Perhaps most exciting of all is the potential to build decentralized
+communication systems. If you look at today's systems, the vast
+majority are infrastructure-based. Broadcast radio and TV provide a
+one-way channel, are tightly regulated and the content is controlled
+by a handful of organizations. Cell phones are a great convenience,
+but the features your phone supports are determined by the operator's
+interests, not yours.</para>
+
+<para>A centralized system limits the rate of innovation. We could take some
+lessons from the Internet and push the smarts out to the
+edges. Instead of cell phones being second-class citizens, usable only
+if infrastructure is in place and limited to the capabilities
+determined worthwhile by the operator, we could build smarter
+devices. These user-owned devices would generate the network. They'd
+create a mesh among themselves, negotiate for backhaul and be free to
+evolve new solutions, features and applications.</para>
+
+</sect1>
+
+<sect1 id="block-diagram"><title>The Block Diagram</title>
+
+<para><xref linkend="block-diagram-fig"/> shows a typical block
+diagram for a software radio. To understand the software part of the
+radio, we first need to understand a bit about the associated
+hardware. Examining the receive path in the figure,
+we see an antenna, a mysterious RF front end, an analog-to-digital
+converter (ADC) and a bunch of code. The analog-to-digital converter
+is the bridge between the physical world of continuous analog signals
+and the world of discrete digital samples manipulated by
+software.</para>
+
+<figure id="block-diagram-fig"><title>Typical software radio block diagram</title>
+<mediaobject>
+<imageobject><imagedata fileref="swr-block-diagram.eps" format="EPS"/></imageobject>
+<imageobject><imagedata fileref="swr-block-diagram.png" format="PNG"/></imageobject>
+<caption><para></para></caption>
+</mediaobject>
+</figure>
+
+<para>ADCs have two primary characteristics, sampling rate and dynamic
+range. Sampling rate is the number of times per second that the ADC
+measures the analog signal. Dynamic range refers to the difference
+between the smallest and largest signal that can be distinguished;
+it's a function of the number of bits in the ADC's digital output and
+the design of the converter. For example, an 8-bit converter at most
+can represent 256 (2<superscript>8</superscript>) signal levels, while
+a 16-bit converter represents up to 65,536 levels. Generally speaking,
+device physics and cost impose trade-offs between the sample rate and
+dynamic range.</para>
+
+<para>Before we dive into the software, we need to talk about a bit of
+theory. In 1927, a Swedish-born physicist and electrical engineer
+named Harry Nyquist determined that to avoid aliasing when converting
+from analog to digital, the ADC sampling frequency must be at least
+twice the bandwidth of the signal of interest. Aliasing is what makes
+the wagon wheels look like they're going backward in the old westerns:
+the sampling rate of the movie camera is not fast enough to represent
+the position of the spokes unambiguously.</para>
+
+<para>Assuming we're dealing with low pass signals - signals where the
+bandwidth of interest goes from 0 to f<subscript>MAX</subscript>, the
+Nyquist criterion states that our sampling frequency needs to be at
+least 2 * f<subscript>MAX</subscript>. But if our ADC runs at 20 MHz,
+how can we listen to broadcast FM radio at 92.1 MHz? The answer is the
+RF front end. The receive RF front end translates a range of
+frequencies appearing at its input to a lower range at its output. For
+example, we could imagine an RF front end that translated the signals
+occurring in the 90 - 100 MHz range down to the 0 - 10 MHz
+range.</para>
+
+<para>Mostly, we can treat the RF front end as a black box with a single
+control, the center of the input range that's to be translated. As a
+concrete example, a cable modem tuner module that we've employed
+successfully has the following characteristics. It translates a 6 MHz
+chunk of the spectrum centered between about 50 MHz and 800 MHz down to
+an output range centered at 5.75 MHz. The center frequency of the
+output range is called the intermediate frequency, or IF.</para>
+
+<para>In the simplest-thing-that-possibly-could-work category, the RF front
+end may be eliminated altogether. One GNU Radio experimenter has
+listened to AM and shortwave broadcasts by connecting a 100-foot piece
+of wire directly to his 20M sample/sec ADC.</para>
+
+</sect1>
+
+<sect1 id="software"><title>On to the Software</title>
+
+<para>GNU Radio provides a library of signal processing blocks and the
+glue to tie it all together. The programmer builds a radio by creating
+a graph (as in graph theory) where the vertices are signal processing
+blocks and the edges represent the data flow between them. The
+signal processing blocks are implemented in C++. Conceptually,
+blocks process infinite streams of data flowing from their input
+ports to their output ports. Blocks' attributes include the number
+of input and output ports they have as well as the type of data that
+flows through each. The most frequently used types are short, float
+and complex.</para>
+
+<para>Some blocks have only output ports or input ports. These serve as
+data sources and sinks in the graph. There are sources that read from
+a file or ADC, and sinks that write to a file, digital-to-analog
+converter (DAC) or graphical display. About 100 blocks come with
+GNU Radio. Writing new blocks is not difficult.</para>
+
+<para>Graphs are constructed and run in Python.
+<!-- <xref linkend="dial_tone_ex"/> -->
+Example 1
+is the "Hello World" of GNU Radio. It generates two sine waves and outputs
+them to the sound card, one on the left channel, one on the
+right.</para>
+
+&dial_tone_example;
+
+<para>We start by creating a flow graph to hold the blocks and
+connections between them. The two sine waves are generated by the
+gr.sig_source_f calls. The f suffix indicates that the source produces
+floats. One sine wave is at 350 Hz, and the other is at
+440 Hz. Together, they sound like the US dial tone.</para>
+
+<para>audio.sink is a sink that writes its input to the sound card. It
+takes one or more streams of floats in the range -1 to +1 as its
+input. We connect the three blocks together using the
+<methodname>connect</methodname> method of the flow graph.</para>
+
+<para><methodname>connect</methodname> takes two parameters, the
+source endpoint and the destination endpoint, and creates a connection
+from the source to the destination. An endpoint has two components: a
+signal processing block and a port number. The port number specifies
+which input or output port of the specified block is to be connected.
+In the most general form, an endpoint is represented as a python tuple
+like this: <literal>(block, port_number)</literal>. When
+<literal>port_number</literal> is zero, the block may be used alone.
+</para>
+
+<para>These two expressions are equivalent:</para>
+<programlisting>
+fg.connect ((src1, 0), (dst, 1))
+fg.connect (src1, (dst, 1))
+</programlisting>
+
+<para>Once the graph is built, we start it. Calling
+<methodname>start</methodname> forks one or more threads to run the
+computation described by the graph and returns control immediately to
+the caller. In this case, we simply wait for any keystroke.</para>
+
+</sect1>
+
+<sect1 id="fm-receiver"><title>A Complete FM Receiver</title>
+
+<para>
+<!-- <xref linkend="fm_demod_ex"/> -->
+Example 2
+shows a somewhat simplified but
+complete broadcast FM receiver. It includes control of the RF front
+end and all required signal processing. This example uses an RF front
+end built from a cable modem tuner and a 20M sample/sec
+analog-to-digital converter.</para>
+
+&fm_demod_example;
+
+<para>Like the Hello World example, we build a graph, connect the
+blocks together and start it. In this case, our source, mc4020.source,
+is an interface to the Measurement Computing PCI-DAS 4020/12
+high-speed ADC. We follow it with gr.freq_xlating_fir_filter_scf, a
+finite impulse response (FIR) filter that selects the FM station we're
+looking for and translates it to baseband (0Hz, DC). With the 20M
+sample/sec converter and cable modem tuner, we're really grabbing
+something in the neighborhood of a 6 MHz chunk of the spectrum. This
+single chunk may contain ten or more FM stations, and
+gr.freq_xlating_fir_filter_scf allows us to select the one we
+want.</para>
+
+<para>In this case, we select the one at the exact center of the IF of
+the RF front end (5.75 MHz). The output of
+gr.freq_xlating_fir_filter_scf is a stream of complex samples at
+160,000 samples/second. We feed the complex baseband signal into
+gr.quadrature_demod_cf, the block that does the actual FM
+demodulation.</para>
+
+<para>gr.quadrature_demod_cf works by subtracting the angle of
+each adjacent complex sample, effectively differentiating the
+frequency. The output of gr.quadrature_demod_cf contains the
+left-plus-right FM mono audio signal, the stereo pilot tone at 19kHz,
+the left-minus-right stereo information centered at 38kHz and any
+other sub-carriers above that. For this simplified receiver, we finish
+off by low pass filtering and decimating the stream, keeping only the
+left-plus-right audio information, and send that to the sound card at
+32,000 samples/sec.</para>
+
+<para>For a more indepth look at how the FM receiver
+works, please see "Listening to FM, Step by Step."</para>
+
+</sect1>
+
+<sect1 id="gui"><title>Graphical User Interfaces</title>
+
+<para>Graphical interfaces for GNU Radio applications are built in
+Python. Interfaces may be built using any toolkit you can access from
+Python; we recommend wxPython to maximize cross-platform
+portability. GNU Radio provides blocks that use interprocess
+communication to transfer chunks of data from the real-time C++ flow
+graph to Python-land. </para>
+
+<!-- please add more here, including example code and screen shots -->
+
+</sect1>
+
+<sect1 id="hardware-requirements"><title>Hardware Requirements</title>
+
+<para>GNU Radio is reasonably hardware-independent. Today's commodity
+multi-gigahertz, super-scalar CPUs with single-cycle floating-point
+units mean that serious digital signal processing is possible on the
+desktop. A 3 GHz Pentium or Athlon can evaluate 3 billion
+floating-point FIR taps/s. We now can build, virtually all in
+software, communication systems unthinkable only a few years ago.</para>
+
+<para>Your computational requirements depend on what you're trying to do,
+but generally speaking, a 1 or 2 GHz machine with at least 256 MB of RAM
+should suffice. You also need some way to connect the analog world to
+your computer. Low-cost options include built-in sound cards and
+audiophile quality 96 kHz, 24-bit, add-in cards. With either of these
+options, you are limited to processing relatively narrow band signals
+and need to use some kind of narrow-band RF front end.</para>
+
+<para>Another possible solution is an off-the-shelf, high-speed PCI
+analog-to-digital board. These are available in the 20M sample/sec
+range, but they are expensive, about the cost of a complete PC. For
+these high-speed boards, cable modem tuners make reasonable RF front
+ends.</para>
+
+<para>Finding none of these alternatives completely satisfactory, we
+designed the Universal Software Radio Peripheral, or USRP for short.
+</para>
+
+</sect1>
+
+<sect1 id="usrp"><title>The Universal Software Radio Peripheral</title>
+
+<para>Our preferred hardware solution is the Universal Software Radio
+Peripheral (USRP). <xref linkend="usrp-block-diagram-fig"/> shows the
+block diagram of the USRP. The brainchild of Matt Ettus, the USRP is
+an extremely flexible USB device that connects your PC to the RF
+world. The USRP consists of a small motherboard containing up to four
+12-bit 64M sample/sec ADCs, four 14-bit, 128M sample/sec DACs, a
+million gate-field programmable gate array (FPGA) and a programmable
+USB 2.0 controller. Each fully populated USRP motherboard supports
+four daughterboards, two for receive and two for transmit. RF front
+ends are implemented on the daughterboards. A variety of
+daughterboards is available to handle different frequency bands. For
+amateur radio use, low-power daughterboards are available that receive
+and transmit in the 440 MHz band and the 1.24 GHz band. A receive-only
+daughterboard based on a cable modem tuner is available that covers
+the range from 50 MHz to 800 MHz. Daughterboards are designed to be easy
+to prototype by hand in order to facilitate experimentation.</para>
+
+<figure id="usrp-block-diagram-fig"><title>Universal Software Radio Peripheral</title>
+<mediaobject>
+<imageobject><imagedata fileref="usrp-block-diagram.eps" format="EPS"/></imageobject>
+<imageobject><imagedata fileref="usrp-block-diagram.png" format="PNG"/></imageobject>
+<caption><para></para></caption>
+</mediaobject>
+</figure>
+
+<para>The flexibility of the USRP comes from the two programmable components
+on the board and their interaction with the host-side library. To get
+a feel for the USRP, let's look at its boot sequence. The USRP itself
+contains no ROM-based firmware, merely a few bytes that specify the
+vendor ID (VID), product ID (PID) and revision. When the USRP is
+plugged in to the USB for the first time, the host-side library sees
+an unconfigured USRP. It can tell it's unconfigured by reading the
+VID, PID and revision. The first thing the library code does is
+download the 8051 code that defines the behavior of the USB peripheral
+controller. When this code boots, the USRP simulates a USB disconnect
+and reconnect. When it reconnects, the host sees a different device:
+the VID, PID and revision are different. The firmware now running
+defines the USB endpoints, interfaces and command handlers. One of the
+commands the USB controller now understands is load the FPGA. The
+library code, after seeing the USRP reconnect as the new device, goes
+to the next stage of the boot process and downloads the FPGA
+configuration bitstream.</para>
+
+<para>FPGAs are generic hardware chips whose behavior is determined by the
+configuration bitstream that's loaded into them. You can think of the
+bitstream as object code. The bitstream is the output of compiling a
+high-level description of the design. In our case, the design is coded
+in the Verilog hardware description language. This is source code and,
+like the rest of the code in GNU Radio, is licensed under the GNU
+General Public License.</para>
+
+</sect1>
+
+<sect1 id="fpga"><title>What Goes in the FPGA?</title>
+
+<para>An FPGA is like a small, massively parallel computer that you design
+to do exactly what you want. Programming the FPGA takes a bit of
+skill, and mistakes can fry the board permanently. That said, we
+provide a standard configuration that is useful for a wide variety of
+applications.</para>
+
+<para>Using a good USB host controller, the USRP can sustain 32 MB/sec across
+the USB. The USB is half-duplex. Based on your needs, you partition
+the 32 MB/sec between the transmit and the receive directions. In the
+receive direction, the standard configuration allows you to select the
+part or parts of the digitized spectrum you're interested in,
+translate them to baseband and decimate as required. This is exactly
+equivalent to what's happening in the RF front end, only now we're
+doing it on digitized samples. The block of code that performs this
+function is called a digital down converter (<xref linkend="ddc-fig"/>).
+One advantage of performing this function in the digital domain is we can change the
+center frequency instantaneously, which is handy for frequency hopping
+spread spectrum systems.</para>
+
+<figure id="ddc-fig"><title>Digital Down Converter Block Diagram</title>
+<mediaobject>
+<imageobject><imagedata fileref="ddc.eps" format="EPS"/></imageobject>
+<imageobject><imagedata fileref="ddc.png" format="PNG"/></imageobject>
+<caption><para></para></caption>
+</mediaobject>
+</figure>
+
+
+<para>In the transmit direction, the exact inverse is performed. The FPGA
+contains multiple instances of the digital up and down
+converters. These instances can be connected to the same or different
+ADCs, depending on your needs. We don't have room here to cover all
+the theory behind them; see the GNU Radio Wiki for more information.</para>
+
+</sect1>
+
+<sect1 id="apps"><title>GNU Radio Applications</title>
+
+<para>In addition to the examples discussed above, GNU Radio comes with a
+complete HDTV transmitter and receiver, a spectrum analyzer, an
+oscilloscope, concurrent multichannel receiver and an ever-growing
+collection of modulators and demodulators.</para>
+
+<para>Projects under investigation or in progress include:</para>
+
+<itemizedlist>
+<listitem><para>A TiVo equivalent for radio, capable of recording multiple stations simultaneously.</para></listitem>
+<listitem><para>Time Division Multiple Access (TDMA) waveforms.</para></listitem>
+<listitem><para>A passive radar system that takes advantage of
+broadcast TV for its signal source. For those of you with old TVs
+hooked to antennas, think about the flutter you see when airplanes fly
+over.</para></listitem>
+<listitem><para>Radio astronomy.</para></listitem>
+<listitem><para>TETRA transceiver.</para></listitem>
+<listitem><para>Digital Radio Mundial (DRM).</para></listitem>
+<listitem><para>Software GPS.</para></listitem>
+<listitem><para>Distributed sensor networks.</para></listitem>
+<listitem><para>Distributed measurement of spectrum utilization.</para></listitem>
+<listitem><para>Amateur radio transceivers.</para></listitem>
+<listitem><para>Ad hoc mesh networks.</para></listitem>
+<listitem><para>RFID detector/reader.</para></listitem>
+<listitem><para>Multiple input multiple output (MIMO) processing. </para></listitem>
+</itemizedlist>
+
+</sect1>
+
+<sect1 id="politics"><title>Politics</title>
+
+<para>Every revolution has its political issues. Free software for building
+radios is troublesome to some people. In the US, we've run into
+opposition from the Motion Picture Association of America and its
+attempt with the Broadcast Flag to restrict the kinds of receivers
+that can be built for over-the-air digital TV.</para>
+
+<para>The US Federal Communications Commission has issued a Notice of
+Proposed Rule Making (NPRM) concerning Cognitive Radio
+Technologies and Software Defined Radios. Several troublesome
+issues are raised in the NPRM, including restricting the sale of
+high-speed digital-to-analog converters, requirements for digital
+signatures or similar methods to keep unauthorized software out of
+software radio hardware and new restrictions on radios built for the
+amateur radio market.</para>
+
+</sect1>
+
+<sect1 id="summary"><title>Summary</title>
+
+<para>Software radio is an exciting field, and GNU Radio provides the tools
+to start exploring. A deep understanding of software radio requires
+knowledge from many domains. We're doing our best to lower the
+barriers to entry.</para>
+</sect1>
+
+<!-- FIXME
+<sect1 id="resource"><title>Resources</title>
+<para></para>
+</sect1>
+-->
+
+</article>
projects / debian / gnuradio / blobdiff