The Pennsylvania State University

The Graduate School

SOFTWARE-DEFINED RADIO INTEROPERABILITY WITH

FREQUENCY HOPPING WAVEFORMS

A Thesis in

Electrical Engineering

by

Matthew D. Sunderland

c 2010 Matthew D. Sunderland

Submitted in Partial Fulfillment

of the Requirements

for the Degree of

Master of Science

May 2010 The thesis of Matthew D. Sunderland was reviewed and approved∗ by the following:

Sven G. Bil´en Associate Professor of Engineering Design, Electrical Engineering, and

Aerospace Engineering Thesis Advisor

Julio V. Urbina Assistant Professor of Electrical Engineering

W. Kenneth Jenkins Professor of Electrical Engineering Head of the Department of Electrical Engineering

∗Signatures are on file in the Graduate School. Abstract

The flexibility and reconfigurability offered by software-defined implementation of radio systems enables a new class of radio interoperability platforms. Such software-based “radio bridges” allow several heterogeneous communications net- works to be joined simply by loading the correct waveform specification into mem- ory. Particular demand for radio interoperability solutions exists to provide un- interrupted communication between the U.S. Armed Forces and first responders to emergencies. Moreover, due to the increased reliability provided by frequency- hopping systems, several military waveforms use such techniques. This work documents the development of a frequency-hopping radio bridge implemented using the GNU Radio/USRP2 platform. Specifically, a waveform similar to the specification for SINCGARS is used as a target modulation scheme. Software-defined implementation of frequency hopping waveforms is hindered by the additional timing requirements not present in other waveforms. To overcome this, the time-sensitive signal processing of frequency-hopping waveforms is imple- mented in a reconfigurable FPGA.

iii Table of Contents

List of Figures vii

List of Tables viii

List of Code Listings x

Acknowledgments xi

Chapter 1 Introduction 1 1.1 Motivation ...... 3 1.2 Contributions ...... 4 1.3 Thesis Organization ...... 5

Chapter 2 Background 8 2.1 Software-Defined Radio ...... 8 2.2 Radio Interoperability ...... 12 2.3 Previous work ...... 13 2.4 Military Waveforms ...... 16 2.4.1 Frequency-Hopping Spread Spectrum ...... 16 2.4.2 Single Channel Ground and Airborne Radio System . . . . . 18

Chapter 3 System Implementation 20 3.1 GNU Radio ...... 21 3.1.1 Developing for GNU Radio ...... 22 3.1.2 Operation ...... 25

iv 3.1.3 Signal Processing Blocks ...... 27 3.1.4 Circular Buffers ...... 31 3.1.5 Flow Graphs ...... 32 3.1.6 Scheduler ...... 34 3.1.7 SWIG ...... 35 3.2 The USRP2 ...... 36 3.2.1 Hardware ...... 37 3.2.2 FPGA ...... 39 3.2.3 Firmware ...... 44 3.2.4 GNU Radio Interface ...... 45 3.3 Using GNU Radio ...... 46

Chapter 4 Waveform Generation and Processing 54 4.1 Software-Defined Frequency Hopping ...... 55 4.1.1 Complications ...... 55 4.1.2 Comprehensive Solution ...... 58 4.1.3 Proximate Solution ...... 60 4.2 Frequency-Hopping GNU Radio Extensions ...... 61 4.2.1 Overview ...... 61 4.2.2 USRP2 Extensions ...... 62 4.2.2.1 Functionality ...... 62 4.2.2.2 Implementation ...... 63 4.2.3 GNU Radio Extensions ...... 74 4.3 Radio Bridging ...... 79 4.3.1 System Configuration ...... 79 4.3.2 Performance ...... 82

Chapter 5 Conclusions 89

Appendix A Selected Code Listings 92 A.1 Python Examples ...... 92 A.1.1 usrp2 example.py ...... 92 A.1.2 cb usrp bridge.py ...... 94 A.1.3 fhop latency test.py ...... 97 A.2 FHOP Module Source Code ...... 100 A.2.1 fhop bank.v ...... 100 A.2.2 indexer.v ...... 103

v A.2.3 dual reg.v ...... 105 A.2.4 dual ram.v ...... 107

Appendix B Development Environment Setup 109

Bibliography 112

vi List of Figures

2.1 A typical hardware-based analog radio implementation...... 10 2.2 Conceptual ultimate evolution software-defined radio implementation. 10 2.3 Typical software-defined radio implementation using current tech- nology...... 11 2.4 Schematic representation of a radio bridge...... 13 2.5 USRP-based radio bridging solution (Reproduced from [1])...... 14 2.6 Frequency vs. Time for frequency-hopping waveform...... 17 2.7 An example of a typical hop period...... 18

3.1 Layers of code abstraction within GNU Radio...... 26 3.2 A Signal Processing Block...... 27 3.3 Flow Graphs define the interconnection of several SPBs...... 32 3.4 A GNU Radio Top Block...... 33 3.5 The internal components of the USRP2 FPGA...... 40 3.6 The transmit path digital signal processing operations...... 42 3.7 The receive path digital signal processing operations...... 43

4.1 The FPGA frequency hopping module...... 64 4.2 The class hierarchy for the USRP2...... 77 4.3 The frequency-hopping radio bridge demonstration configuration. . 80 4.4 Block diagram of signal processing for radio bridge demonstration. . 80 4.5 A capture of the frequency-hopping waveform aligned to a GPS PPS signal...... 83 4.6 System latency measured as the phase delay between a transmitted and received signal...... 86 4.7 The minimum delay observed during the pass-through test...... 87

vii List of Tables

2.1 Frequency-Hopping Waveform Specifications ...... 19

3.1 USRP2 Hardware Specifications ...... 38

4.1 USRP2 Microprocessor Address Space ...... 69 4.2 Set Config Packet Structure ...... 71 4.3 Write Hop Set Packet Structure ...... 71 4.4 THD of three single-tone test cases...... 84 4.5 Pass-through signal latency...... 86 4.6 Frequency Hopping Latency versus CPU Frequency...... 88

viii List of Code Listings

3.1 usrp2 sink 32fc.h ...... 29 3.2 usrp2 sink 32fc.cc ...... 30 3.3 usrp2 example.py –Imports ...... 47 3.4 usrp2 example.py –Top Block ...... 48 3.5 usrp2 example.py –USRP source and sink ...... 48 3.6 usrp2 example.py –USRP Configuration ...... 49 3.7 usrp2 example.py –Audio Blocks ...... 50 3.8 usrp2 example.py –connect() statements ...... 51 3.9 usrp2 example.py –main() function ...... 52 4.1 u2 core.v –Top Level Frequency Hopping Module ...... 64 4.2 dual reg.v - Dual Port Register ...... 66 4.3 indexer.v - Control logic ...... 67 4.4 memory map.h - FHOP Address Space ...... 69 4.5 usrp2 eth packet.h - FHOP Opcodes ...... 70 4.6 usrp2 eth packet.h - Set Config Packet Structure ...... 71 4.7 usrp2 eth packet.h - Write Hop Set Packet Structure ...... 72 4.8 usrp2 eth packet.h - Set Config Packet Structure ...... 72 4.9 usrp2 eth packet.h - Write Hopset Packet Handler ...... 73 4.10 usrp2 impl.cc - FHOP Enable RX Function ...... 75 4.11 usrp2.cc - Write Hopset Function ...... 76 4.12 usrp2.i - SWIG Interface File ...... 78 4.13 cb usrp bridge.py –Frequency Hopping Transmitter Setup ...... 81 A.1 usrp2 example.py ...... 92 A.2 cb usrp bridge.py ...... 94 A.3 fhop latency test.py ...... 97 A.4 fhop bank.v ...... 100

ix A.5 indexer.v ...... 103 A.6 dual reg.v ...... 105 A.7 dual ram.v ...... 107

x Acknowledgments

My graduate education and indeed my entire career as a student at Penn State has in no small way been affected by my advisor, Sven Bil´en.From his encourage- ment in joining the Honors College to what would later become the Student Space Programs Laboratory and everything in between, Sven has provided me with out- standing opportunities that have shaped my life as an engineer, as a researcher, and as a person. For this, I am incredibly grateful. Thank you, Sven. This work is supported in part by a SBIR contract in conjunction with Star–H Corporation. I thank Brian Herrold for his contributions from this end. I also thank Julio Urbina for being my second reader and Robert Capuro and Mark Foltz for their efforts in reading this thesis and their many helpful sugges- tions. Finally, I must thank my family for their continued support of my education throughout my life.

“For the future that we wait, raise the song...”

xi Chapter 1

Introduction

As radio communication becomes more and more prevalent, it becomes a necessity rather than simply a convenience. In situations such as natural disasters or on the battlefield, the increasing reliance on radio communication is understandable.

Often the difference between life and death, the ability of rescue workers or soldiers to communicate with each other can be hindered by the many radio standards that have made radio communication invaluable and indispensable. The development of new communication protocols and modulation schemes certainly has created high- bandwidth and very reliable radio systems, but as the number of different radio options increases, the likelihood that others are using the same system decreases.

In these situations, municipalities can enact regulations and the military can set policies that dictate the level of interoperability required of radio equipment.

However, this ideology fails in the face of particularly devastating or demanding circumstances. For example, in the pandemonium of the attacks of September 11,

2001, civil rescue workers had to communicate with military personal—each with their own radio systems. Again in 2005, Hurricane Katrina, which devastated New 2

Orleans, brought emergency responders from across the country together at one time—each with their own radio systems. As criticized by Dwyer[2] and Joch[3], radio interoperability could have been improved leading to more successful rescue efforts and saved lives.

The modern battlefield comprises a similar situation. Each of the branches of the U.S. Armed Forces have developed several radio systems to suite particu- lar tactical needs of that branch resulting in a number of radio systems in use.

Moreover, as new technology is introduced at a rate that outpaces the lifetime of existing radios, new systems (not always backwards compatible) are introduced in parallel with existing systems. The need for efforts to unite and unify military communications has been documented for several years [4] [5] [6], with the Joint

Tactical Radio System (JTRS) [7] being the most ambitious program to date that addresses the need.

Realizing the importance of interoperable radio communication, the Depart- ment of Homeland Security conducted a survey of interoperability between civil rescue authorities [8]. The report found that there are several available technologies that may solve the radio interoperability problem. Cataloged in an earlier report by the National Institute of Justice, the available radio interoperability systems are often expensive, physically too large to be mobile, or offer limited functional- ity [9]. For example, Link Communications, Inc. produces radio interoperability equipment for emergency response teams [10]. Their flagship product, the TCB-1, provides two-way interoperability between any two radios. The flexibility of soft- ware systems overcomes the limitations of hardware-based radio bridges. 3 1.1 Motivation

The exponential increase in computational capacity of digital computer systems has enabled the software implementation of radio systems. These systems, termed software-defined radios, move the conversion from an analog signal to a digital signal closer to the antenna thereby implementing more of the radio with digital and software components. As more of the radio system is implemented with digital technologies, the flexibility of the system increases. Use of software-based signal processing and reconfigurable digital logic such as Field Programmable Gate Arrays

(FPGAs) allows components of the software-defined radio system to be updated based on dynamic system needs, even during operation. Consequently this is a major advantage of digital systems over their analog counterparts.

Development of interoperable communication systems is made possible by the versatility offered by software-defined communication systems. For example, emer- gency responders often use radio systems that are not standardized between the responding groups. Coordination and rescue efforts suffer because of the lack of inter-team communication. One solution is the development of a “bridging” plat- form capable of translating communication schemes used by the various parties involved. However, with the myriad of communication waveforms and frequen- cies in use, a traditional radio system implementing all of the possible combina- tions is impractical. But considering the advantages of software-defined systems, especially in terms of reconfigurable radios, the problem becomes tractable. A software-defined system, capable of reconfiguration as an entirely new radio via a change in its programming, can implement as many communication waveforms as 4 its memory capacity allows.

The problem of radio interoperability also exists on the modern battlefield. As with first responders arriving at the scene of an emergency, the modern warfare theater is filled with a multitude of essential, yet incompatible, radio systems. Now increasingly reliant on digital communications, soldiers must be capable of com- municating orders and intelligence information securely and without interruption.

Given the long history of military radio technology, many radio systems have been developed—not all of which have been designed with an emphasis on interoper- ability. Legacy systems become essential parts of normal operating procedure and coexist with the ever-advancing stream of new generation radios and communica- tion equipment. Different forces, each issued radios from different contracts, meet and need to communicate. Clearly, there is a need for a technology that would allow several communication platforms to operate seamlessly together.

1.2 Contributions

The purpose of this thesis project is to investigate the feasibility of a radio bridging system for military-type waveforms. Drawing on past research in radio bridging performed at Penn State [1], a similar approach is taken in the implementation of this research. Extensive use of existing and open-source hardware and software through the GNU Radio project is used as the basis for the bridging platform.

Together, the GNU Radio and the second generation Universal Software Radio

Peripheral (USRP2) form the foundation of a complete and extensible radio plat- form. The GNU Radio project provides an extensive set of software-implemented 5 signal processing operations and a flexible framework for developing real-time sig- nal processing applications using a general-purpose microprocessor.

This work extends the capability of the GNU Radio/USRP2 platform to sup- port frequency-hopping waveforms through the addition of a frequency-hopping module implemented in the USRP2 FPGA. The stream-based processing architec- ture of GNU Radio prevents it from efficiently handling complex waveforms such as frequency-hopping spread spectrum. By implementing some of the time-critical frequency hopping signal processing on the FPGA, limitations of the GNU Radio are alleviated.

Finally, it is hoped that this thesis will also serve as a resource for others who choose to develop with the GNU Radio and USRP2 platforms. Many tutorials have been written documenting the use of GNU Radio. However, there is little available literature on the underlying implementation and details of the project from a developer’s viewpoint. The GNU Radio project is continually evolving and, while providing an indelible in-depth review is not possible, an overview of major components and the fundamental strategies used by the GNU Radio developers should be, at least somewhat, lasting.

1.3 Thesis Organization

In order to prepare the reader for the later developments, Chapter 2 presents an overview of several essential background topics. Software-defined radio concepts are introduced and discussed in context with the ideal and practical designs of such systems. The topic of software-based radio bridging is covered along with 6 a review of previous research related to its implementation. The fundamentals of frequency hopping waveforms are reviewed and past software implementations of these waveforms are discussed. Finally, the specifics of the military waveforms of interest to this research are presented, highlighting potential challenges toward software implementation.

Chapter 3 provides an in-depth review of the GNU Radio project. Limited availability of complete documentation plagues many open-source projects, and while the best understanding is obtained by reading the source code, there is a need to provide a more abstract and informative view into the design of the project. An attempt is made to provide the nascent developer with a sufficient understanding of the major design choices and implementation strategies which shape the GNU Radio project. Particular emphasis is placed on the portions of the project that have an impact on radio-interoperability research.

The second half of Chapter 3 provides an in-depth review of the Universal

Software Radio Peripheral. The primary work of this thesis has been in extensions to the USRP2. The capabilities of the hardware, inner workings of the FPGA logic and the microprocessor are presented in this chapter.

Chapter 4 documents the design of the frequency-hopping extensions and sup- porting code. The problems of implementing frequency-hopping waveforms in soft- ware are detailed along with possible solutions. The solution developed as part of this work is then outlined and covers the FPGA additions, firmware changes, and supporting modifications to the GNU Radio code. Chapter 4 concludes by pre- senting some performance results obtained from tests of the completed frequency hopping radio bridge demonstration system. 7

Finally, Chapter 5 summarizes the major points of this work and provides a starting point for future work and recommendations on appropriate directions.

Comprising the end-matter are two appendices. Appendix A is a selection of important code sections. Appendix B records several procedures for recreating the development environment used as part of this research. Chapter 2

Background

This chapter provides a review of several key concepts and technologies explored in the remainder of this thesis. Software-defined radio is reviewed as it relates to radio interoperability. Previous work in software-defined radio interoperability is also presented. The fundamentals of frequency-hopping waveforms are covered along with a section on previous software-based implementations of frequency- hopping radios. Finally, details of the military communications waveforms used throughout this thesis are presented.

2.1 Software-Defined Radio

Software-Defined Radio (SDR) is the natural progression of radio technology from hard-wired implementation toward software implementation in the quest for greater

flexibility and increased performance. In much the same way as analog-based com- munication systems gave way to digital logic in the 1970s and 1980s, the current software-defined revolution increases the reach of the programmability and flexi- 9 bility hallmarked by software systems [11]. As the migration towards digital tech- niques provided new capabilities such as networking and forward error correction, so too does SDR provide completely new possibilities in communication systems.

As with any new paradigm, SDR is effected through the availability of sev- eral key technologies. Sufficiently powerful digital processors; high-speed, high- resolution analog-to-digital and digital-to-analog converters; and wide-band an- tennas are essential to the fruition and adoption of SDR techniques in modern radio design. As these technologies become more capable, the tendency is to move more of the radio system away from traditional hardware mixers and filters, toward software algorithms and processes [12]. As a result, each system component imple- mented in software (or at least under software control) inherits the programmable nature of software.

Consider Figure 2.1, which shows the implementation of a traditional analog radio receiver. Each portion of the signal processing chain is achieved using ded- icated and specialized hardware. Filters are precisely tuned to a fixed frequency, and mixers shift the signal by an amount determined by the local oscillator. Very little flexibility exists in the design. If new system needs dictate a change in inter- mediate frequency, new components must be designed or, at a minimum, replaced.

Signal digitization does not occur until all signal operations have been completed.

Now consider the radio receiver shown in Figure 2.2. The RF signal is sampled immediately following the antenna. With no hard-wired elements limiting the functionality of the receiver, all of the signal operations occur digitally in software.

Given sufficient processing power, it is conceivable that this radio could demodulate 10

Figure 2.1. A typical hardware-based analog radio implementation. every signal present in the spectrum captured by the antenna. While this ultimate

SDR may not be physically attainable, it does illustrate the motivation for moving analog-to-digital conversion closer to the antenna [13].

Figure 2.2. Conceptual ultimate evolution software-defined radio implementation.

Generally, as the signal processing approaches the antenna of the radio system, the bandwidth requirements and timing accuracies become increasingly difficult to meet when implemented with currently available digital devices and software solu- tions. For example, the bandwidth and dynamic range of current ADCs are unable to capture sufficient portions of the spectrum. Or, constrained by processing re- sources, sampling rates are limited and problems arise when trying to meet critical real-time timing requirements. Careful decisions need to be made concerning the 11 split between hardware and software roles within the system. Increasing the por- tion of the radio implemented in software certainly increases the flexibility of the overall system, but must be weighed against the additional costs and challenges of wide-band digital systems.

In most cases then, a feasible SDR implementation is a hybrid between the fully hardware-based (and inflexible) and completely software-based (and difficult to implement) radio design. Figure 2.3 shows a more realistic model for SDR and is similar to the implementation used in this work. In an effort to reduce the bandwidth of the digitized signal, traditional filters and mixers first translate the radio frequency (RF) signal to an intermediate frequency (IF). Capable of sampling at a more reasonable IF, the signal is further processed using software techniques that implement modulation, symbol encoding, clock recovery, etc.

Figure 2.3. Typical software-defined radio implementation using current technology.

Lastly, the overarching terms of “software-defined” or “software-based” do not necessarily refer to instructions executed on a microprocessor. Rather, these terms are used to convey the programmable and versatile nature of software algorithms.

Other digital technologies such as Field Programmable Gate Arrays (FPGAs), 12

Programmable Logic Devices (PLDs), and other programmable devices are also be categorized under the software umbrella because these technologies enable the same versatility as software.

2.2 Radio Interoperability

Radio interoperability or radio bridging enables heterogeneous radio networks to operate transparently with one another. Normally, one class of radios would be confined to communication only to those radios that share the same waveform, that is, the same frequency bands, modulation type, and data protocols. Radios, dissimilar in these aspects, would be unable to receive from or transmit to the orig- inal radios. Perhaps with the widespread adoption of SDR, future radios would simply negotiate the waveform to use, making interoperability an intrinsic capa- bility. But for the present, many radios are still of the inflexible hardware type, incapable of self adaption to changing conditions. Suppose a middleman could be used to translate between two dissimilar waveform standards.

A radio bridge acts as a translator by receiving signals encoded in one format and retransmitting the same message modulated to another specification similar to the way foreign diplomats communicate through a translator. The role of the professional translator is to interpret the diplomats’ message in one language, an- alyze the intentions and essence of the message, and finally relay the message in another language. A good translator will be able of course to repeat the message while loosing none of the subtleties.

The radio bridge performs a similar translation. It must strip the RF signal of 13 its carrier and modulation and reveal the baseband message. Once the baseband message has been uncovered, the signal is modulated onto a new carrier according to the new waveform specification. Figure 2.4 schematically illustrates this process.

Figure 2.4. Schematic representation of a radio bridge.

Later, Menendez was able to show the extensibility of his original design through the implementation of an additional radio, a 900-MHz cordless phone, using the same basic framework. A third modulation and demodulation path was added in parallel to the existing CB and FRS code, and was selected using an extension of the same mute-block technique used in the two-radio case.

2.3 Previous work

Penn State has been involved in SDR implementation research for a number of years [14], [15], [16], with the work of Menendez being most related to this research 14

[1]. Using previous generation hardware, Menendez was able to develop a radio

bridging system between Citizens’ Band (CB) Radio and Family Radio Service

(FRS) with fairly successful results.

In a straightforward implementation shown in Figure 2.5, Menendez used mul-

tiple first generation USRPs as front ends for the AM-modulated CB radio and

FM-modulated FRS radios connected to a desktop PC running the GNU Radio

code. The USRP-based front ends were responsible for down-converting the RF

signal (at approximately 25 MHz for CB and 430 MHz for FRS) to a digitized

baseband signal. Each input was then demodulated according to its waveform and

passed through a squelch detector and a software-controllable mute block. All of

the inputs, of which only one would be un-muted at a given time, are then summed

together and passed to the output paths, which then modulate the signal with the

respective schemes. Again, a software-controlled mute block selects the output to 13 receive the signal.

CB CB

Demodulation Squelch Mute Mute Modulation

FRS FRS

Demodulation Squelch Mute Mute Modulation

FigureFigure 2.5. USRP-based 3.5. Bridging radio bridging system solution block (Reproduced diagram. from [1]).

3.2.5 Bridging System Architecture

To create a radio bridge, each of the four previously described subsystems must be connected together such that, when a CB signal is received, it is broadcast over FRS, and vice versa. Towards this end, each receiver subsystem output is connected to a mute_ff/mute_cc block. The mute_ blocks output zero when muted and simply pass the input when unmuted. The ∗ outputs of the two mute blocks are then summed together with an add_ff block. The adder output is connected to two more mute_ff blocks; one for each transmit subsystem. Finally, the output of each transmit mute block is connected to its respective transmit subsystem input. When the radio bridge software is initialized, all four mute blocks are muted, so that no signals are being broadcast. A small function will run at a specified time interval, which does the following each time it executes:

Checks to see if a new signal has been detected from either receiver by calling • simple_squelch_cc.unmuted().

If a new signal is detected from one receiver and a signal is not currently being received • from the other, the receiver with the signal is enabled by calling the set_mute(False) method of its mute block. The opposite transmitter is then enabled in the same manner.

If a signal is no longer being received, all mute blocks are re-muted by calling the • set_mute(True) method for each block.

This procedure ensures that the radio bridge will never cause interference with itself, since if the CB (FRS) transmitter is active, the CB (FRS) receiver will be disabled.

3.3 Command-Line Operation

The radio bridge software provides the following command-line arguments:

-c (--cb-channel) Selects the CB channel (1–40) to operate on. The default is channel 1.

-g (--cb-gain) Sets the CB receiver gain in dB (integer, 0–20). The default is 0 dB. 15

While this approach is straightforward and simple, it contains several inefficien- cies. For example, the mute blocks do not stop the flow of data but simply zero all of the incoming data (essentially a multiply-by-zero operation on the input).

This means that all of the transmit and all of the receive modulation paths are continuously operating on data of which only one of the paths contains non-zero data. If instead of muting and summing the input paths, the unused paths were programmatically disconnected, substantial performance gains would be achieved.

In the case of the two-system bridge that Menendez considered, the required op- erations per second is halved and for an n-system bridge, the savings would be proportional.

Later, Menendez was able to show the extensibility of his original design through the implementation of an additional radio (a 900-MHz cordless phone) using the same basic framework. A third modulation and demodulation path was added in parallel to the existing CB and FRS code, and was selected using an extension of the same mute-block technique used in the two-radio case.

Regarding frequency hopping, more than a decade ago, Shah considered the software implementation of frequency-hopping waveforms [17]. Interestingly enough, the original research into what eventually became the GNU Radio project, the plat- form used in this work, was started at this same time and in the same lab where

Shah completed his research. Shah was successful in implementing a two-way frequency-hopping radio using purely software-based signal processing. His sys- tem was based on a symbol look-up table containing the “zero-bit” and “one-bit” symbol waveforms for FSK encoding at each hop frequency. To transmit, each bit of the digital message and the current position in the hop-set was used to select the 16 correct waveform from the table. A concatenated series of bit-waveforms feeding a DAC was used to produce a signal.

On the receiver side, Shah considered a frequency-hopping waveform synchro- nized by a packet header prepended to each transmission. In this case, transmitter– receiver synchronization is obtained by performing a running correlation on the decoded input stream, which greatly simplifies the implementation of a software- based synchronization scheme. Shah used a single byte of data sent on a predeter- mined start-frequency that could be continuously scanned by the receiver.

Finally, limited by the state-of-the-art in 1997, Shah was only able to frequency hop over a total bandwidth of 2.5 MHz, obtaining a data rate of approximately

31 kBps.

2.4 Military Waveforms

The goal of this thesis is to implement a bridging platform capable of linking sev- eral military waveforms commonly used by the U.S. Armed Forces. Because of the importance of the transmitted messages and the potential for intentional or unin- tentional interference, several of the considered waveforms use frequency-hopping spread spectrum techniques to improve immunity to narrowband interference.

2.4.1 Frequency-Hopping Spread Spectrum

Frequency hopping is a spread spectrum technique involving the periodic transition between frequency channels mainly providing increased immunity to interfering narrowband signals. As shown in Figure 4.1, a narrowband signal periodically 17

“hops” through a sequence of several carrier frequency channels at a predetermined rate. The sequence, or “hop-set”, is generally a pseudo-random series but must be known by both the transmitting and receiving parties before transmission begins.

Figure 2.6. Frequency vs. Time for frequency-hopping waveform.

The signal can only be recovered if the receiver knows the rate through which the hop-set is iterated (hop period), the complete hop-set, and is capable of syn- chronizing with the transmitted signal. For synchronization to occur, the receiver must correctly align with the transitions of each frequency hop and know the cur- rent index in the hop-set. The former condition is generally achieved through correlating a synchronization symbol with an impulse-like autocorrelation and low cross-correlation with a normal data sequence. With hop-sets occasionally repeat- ing after weeks, the later condition requires absolute time synchronization between radios, often to within miliseconds of accuracy. However, the precision of GPS tim- ing signals can be used to satisfy both synchronization conditions.

With the received signal properly synchronized to the transmitter, the baseband signal finally can be extracted by shifting the signal down by the current frequency of the hop-set. However, changing the frequency of the local oscillator to the next 18

Figure 2.7. An example of a typical hop period. value in the hop-set requires a finite amount of time during which data cannot be transmitted. Because of this transition period, frequency-hopping waveforms define a blackout or blank period surrounding the transition point in the hop set.

As Figure 2.7 shows, the baseband message is transmitted only during the middle portion of each hop period. Since the baseband signal is non-continuous, this means only digital modulation schemes are effectively transmitted using frequency hopping. Moreover, the blanking period will prove to be a significant challenge when attempting to implement frequency hopping modulations in software. The tight timing requirements of the blank period are not easily met using software systems.

2.4.2 Single Channel Ground and Airborne Radio System

Introduced in the early 1980s, the Single Channel Ground and Airborne Ra- dio System (SINCGARS) has become prevalent in each branch of the Armed

Forces. Based on lessons learned during the Second World War and Vietnam

War, SINCGARS reduced susceptibly to jamming and direction finding by em- ploying a frequency-hopping waveform [18]. The advantages of frequency-hopping waveforms are also evident in the fact that several other military tactical com- 19 munication systems now employ frequency hopping, such as Have Quick and the

Enhanced Position Location Reporting System (EPLRS).

The goal of this research was to investigate software-based solutions for the implementation of frequency-hopping waveforms with a focus on possible military applications. Considering this, a waveform similar to SINGARS was chosen as the basis for the target waveform. In particular, since the exact specifications of

SINCGARS are not publicly available, a surrogate waveform was developed based on available SINCGARS information. Table 2.1 summarizes the specifications for the waveform used in this research.

Parameter SINCGARS Surrogate Frequency 30–88 MHz 0–50 MHz Modulation Narrowband FM Narrowband FM Hop Set Length >thousands Variable (1 to 256) Frequency Channels 2320 Channels, 25-kHz Programmable, any fre- spacing quency within 0–50 MHz bandwidth Synchronization GPS Time and/or Synchro- GPS Pulse per second signal nization word Hop Period 10 ms Variable (10 µs to several minutes) Table 2.1. Frequency-Hopping Waveform Specifications Chapter 3

System Implementation

A review of the platforms used in this research, specifically the USRP2 (hardware) and GNU Radio (software) projects are presented herein. There are several other platforms available, including products from National Instruments [19] and Lyrtech

[20], and several open-source/research projects. See Farrell [21] for a review of recent research platforms for SDR.

Nevertheless, because of previous experience with, the large user base, and open source nature of the GNU Radio project, it was selected as the platform used in this research. Additionally, the Universal Software Radio Peripheral (USRP) 2, the second generation hardware developed for use with the GNU Radio software, was chosen as the hardware platform. Even though the first generation (USRP1) and second generation (USRP2) boards have similar support when using the GNU

Radio project, the USRP2 hardware features are more suitable for implementing frequency hopping. 21 3.1 GNU Radio

The GNU Radio project is largely the work and contributions of Eric Blossom

[22] who continued the original MIT SpectrumWare work of Vanu Bose [23]. Bose

first considered the strategy of using general purpose microprocessors (such as those found in personal computers) to implement signal operations performed in hardware radios. Using general purpose microprocessors for signal processing (as opposed to specialized digital signal processors) leverages the advantages of large market demand, which drives continuous performance improvements, and the flex- ibility of using conventional programming languages and software libraries [24].

Developing for the personal computer removes the need to acquire specialized knowledge for developing with specific embedded digital signal processors, thereby lowering the barrier of entry and enabling more contributors to improve the project.

As a testament to this philosophy, ten years later an entire community of devel- opers, lead by Eric Blossom and others, are still improving and extending Bose’s original work in the form of the GNU Radio project.

From its roots in the MIT SpectrumWare project, GNU Radio has evolved into a library of signal processing operations that the user can programmatically link together to form a complete radio system. By selecting from a large pool of existing signal processing blocks, a user creates an SDR system by simply specifying the connections of the constituent blocks through a dynamic scripting language.

To interface with RF signals, however, a hardware platform implementing an

ADC and DAC must be used in conjunction with GNU Radio. Though several platforms have been developed, by far the most popular and most tightly inte- 22 grated are the Universal Software Radio Peripherals (USRPs) developed by Ettus

Research [25].

3.1.1 Developing for GNU Radio

As an open-source software implementation for radio systems, GNU Radio draws heavily on the resources and community surrounding open software development.

Familiar to those experienced with the GNU/Linux operating system, the orga- nization of the GNU Radio project uses the same software management tools, compilers, and work flow that of many open-source projects use.

Therefore, a potential GNU Radio developer should, at minimum, be familiar with GNU/Linux. Although several contributors work to make the GNU Radio project available to the Windows and Mac operating systems, GNU/Linux is the primary target and receives the most support and active development. Further- more, the USRP2 hardware is only supported on the GNU/Linux platform. On the Windows and Mac platforms, the development environment is a port of the original Linux software that has been modified to run on those environments. Un- expected complications are bound to be found. For these reasons, it is advisable for a new developer be comfortable with the use of the GNU/Linux operating system, a command-line shell, using the GNU Buildtools (make, configure, autoconf, and automake) to compile software from sources, and the Git or Subversion version control software.

GNU Radio is a complex software project comprising over 1,5001 source code

1For the interested Linux user, run the command $ ls -R | grep .[cc,h] $ | nl at a shell prompt in the root directory of the GNU Radio sources to get the current total\ of source files. 23

files with additional files included in the somewhat separate USRP projects. At the source code level, knowledge of C++ and Python are required for development of GNU Radio while experience with C, Verilog, and the Xilinx tools, are necessary for developing with the USRP2.

From a developer’s standpoint, the GNU Radio project has two peculiar cus- toms, the motivation for which, may not be immediately obvious to the nascent de- veloper. However, after working with the software and build process these choices begin to make sense.

First, the core of GNU Radio is implemented in C++ and its signal process- ing functionality is interfaced using the Python programming language. It is not possible to write applications entirely in C++; Python is required, at a top level, to link all of the components together.2 The advantage is that Python, which is an extensible, interpreted language, does not need to be compiled before being executed [26]. Rather, the Python interpreter translates the Python code as it is being executed and translates the commands into native instructions that can be executed by the processor. As a consequence of the translation, the performance of such interpreted languages suffer at the expense of delaying compilation until nec- essary. However, Python provides an interface that allows standard C libraries to be called directly within the Python code and executed as native compiled C func- tions, which incur none of the performance penalties associated with interpreted code. 2There are a number of developers who do not like the Python dependence mostly due to the increased complexity introduced by the Python–C++ interface. As discussed later, the overhead of the Python interpreter is not a major factor. Nevertheless, there is an effort underway in the GNU Radio community to remove the Python runtime and replace this with an optional C++-based runtime. 24

GNU Radio makes extensive use of this interface using the Simple Wrapper and Interface Generator (SWIG) tools, which extends support to include C++ libraries [27]. Though SWIG adds another layer of complexity in the design of

GNU Radio, it allows signal processing blocks to be connected and controlled using the interpreted Python language with none of the performance penalties normally inherited by interpreted languages. The major advantage of this strategy is that a lengthy compile process is not needed after modifying a radio implementation.

This allows for rapid prototyping and experimentation using the pre-built signal processing blocks. Almost no overhead is incurred by the Python runtime as the code executes. The Python code is simply used to describe the configuration of the signal processing. All of the actual processing is done in compiled C++ functions.

The second design choice in GNU Radio that may seem overly complicated at first is the two-part class implementation. While most C++ developers are familiar with the interface/implementation convention, which splits a class into a header (.h) file and body (.cc) file, GNU Radio takes this a step further using two separate classes to implement some data structures. Partly motivated by the additional Python–SWIG interface layer, some classes have a Python-facing class, which defines pass-through functions that, in turn, call the real functions defined in an implementation class. This two-step approach disconnects the implementa- tion from the interface reducing the higher-level compilation dependancies when changes are made to the underlying implementation. If this interface barrier class were not present, updating the implementation of a block would require the recom- pilation of all inheriting classes. In a project as large as GNU Radio, this becomes a substantial savings. 25

Because of the SWIG interface to Python and the separate interface and imple- mentation classes for each logical class, there are a number of extra code files that accompany a given code construct. For all classes there are the customary foo.h and foo.cc files that define and implement the class respectively. If the particular class benefits from having a separate interface, an additional pair of files named foo_impl.h and foo_impl.cc, or foo_detail.h and foo_detail.cc exist that actually implement the functionality of the class. The original foo.h and foo.cc

files only define the interface and make pass-through calls to the implementation or detail class. Finally, for all classes that are accessible from Python, a SWIG definition file, foo.i exists that dictates how SWIG translates the C++ classes and methods into Python-callable objects and functions.

Figure 3.1 depicts the several layers of code that provide varying levels of abstraction. Details are hidden at the lower levels which allow the higher levels to focus on only the interface between code segments. The abstraction layers also benefit the developer by reducing compilation time when making small changes.

At the highest layer, all programmability is defined by Python script files that do not require a compilation step.

3.1.2 Operation

GNU Radio implements signal operations on streams of data by partitioning the data streams into segments of data that are operated on by Signal Processing

Blocks (SPBs). Each SPB implements a particular operation on zero or more input streams and produces zero or more output streams. SPBs that only con- 26

Figure 3.1. Layers of code abstraction within GNU Radio. sume streams are called “sinks” while those that only generate streams are called

“sources”. In general, a SPB—such as one implementing a filter—will accept an input stream, perform an operation on the data (perhaps a running average IIR

filter operation), and produce an output stream. At a high level of abstraction, this process appears to happen simultaneously and continuously providing the effect similar to a hardware-based implementation. However, given the multiprocessing limitations of a microprocessor (even of multi-core processors), the actual imple- mentation is more complex and worth understanding

At a lower level, the workings of GNU Radio are analogous to the way in which modern operating systems (OS) give the illusion of executing multiple applications concurrently [28]. In an OS, each application is executed within a virtual process, meaning a programming construct provides access to physical memory and pro- cessing resources independent of other executing processes. To achieve apparent parallelism, the OS allows each process to execute for a short period of time be- fore pausing the currently executing process and resuming a waiting one. If the 27 demand for the processor is low, the OS can keep the queue size of of waiting pro- cesses small, giving the appearance that multiple applications are run concurrently

In this analogy, SPBs are akin to applications that all demand some portion of the processor’s time. To provide the illusion of continuous operation, GNU Radio allows each SPB to operate on a small chunk of data before moving on to another block.

3.1.3 Signal Processing Blocks

The signal processing block (SPB) is the basic element through which the radio data stream is modified. Each SPB is implemented in C++, which allows for efficient implementation of complex mathematical operations. The base class for

SPBs can be found in gr_block.cc, which, in turn, inherits the abstract class found in gr_basic_block.cc. This base class defines a virtual function called work(), which implements the actual signal operation. The work() function is the actual code called every time the SPB is scheduled to run and operates on one packet of data. The work function is redefined in the specific subclass implementing a particular signal operation. Illustrated in Figure 3.2, the core work() function operates on a set of input buffers to produce data in output buffers.

Figure 3.2. A Signal Processing Block. 28

As a case study, consider the USRP2 sink SPB included in Listing 3.1. The declarations begin on line 28 with a forward declaration of the SPB class, usrp2_ sink_32fc. This forward declaration enables the definition of a pointer type to that class as appears in the following line. Note that GNU Radio uses shared pointers provided by the Boost C++ libraries [29] to simplify memory manage- ment. Dynamic memory created with regular pointers (native C++ pointers) must be explicitly freed by the programmer to reclaim the resources. However, the Boost shared pointers provide a resource counter that, when it reaches zero, will automatically deallocate the structure pointed to by the pointer. With the added complexity the Python interface, relying on the Boost pointers for memory management reduces the possibility of memory leaks within the code. Yet, for most purposes, the Boost pointer template can be thought of as a regular pointer to instances of the SPB class.

Continuing in Listing 3.1, the next declaration (on line 31) makes use of the newly defined pointer type as the return value for the SPB’s make() function. The make() function does the work of creating, or making, an instance of the SPB within the underlying C++ framework. It is this function that is called when the block is created within a Python script. Accordingly, when identifying the proper arguments to pass to the Python function, one should look for the corresponding make function defined in the SPB’s source files.

On line 36, the actual class definition for the SPB begins by inheriting the public members of the usrp2_sink_base class. It is common for SPB classes to inherit a chain of classes, all of which are eventually rooted in the gr_basic_block class containing the minimal subset common to all SPBs. The first statement within 29

the class (lines 39–42) declares the usrp2_make_sink_32fc() function as a friend

of the current class. This statement is necessary to provide the make function with

access to all of the private members of the SBP class since the make function itself

does not belong to the class.

Lines 44–49 are simply standard function prototypes for the class’s constructor

and destructor. Lastly, the work() function prototype is declared on lines 51–53.

Listing 3.1. usrp2 sink 32fc.h

28 class u s r p 2 s i n k 3 2 f c ; 29 typedef boost :: shared ptr u s r p 2 s i n k 3 2 f c s p t r ;

30

31 u s r p 2 s i n k 3 2 f c s p t r 32 usrp2 make sink 32fc ( const std:: string &ifc=”eth0”, 33 const std :: string &mac=””) 34 throw (std:: runtime e r r o r ) ;

35

36 class u s r p 2 s i n k 3 2 f c : public u s r p 2 s i n k b a s e

37 { 38 private : 39 friend u s r p 2 s i n k 3 2 f c s p t r 40 usrp2 make sink 32fc ( const std::string &ifc , 41 const std:: string &mac) 42 throw (std:: runtime e r r o r ) ;

43

44 protected : 45 u s r p 2 s i n k 3 2 f c ( const std::string &ifc , const std:: string &mac) 46 throw (std:: runtime e r r o r ) ;

47

48 public : 49 ˜ u s r p 2 s i n k 3 2 f c ( ) ;

50

51 int work ( int noutput items , 52 g r v e c t o r c o n s t v o i d s t a r &input items , 53 g r v e c t o r v o i d star &output items ) ; 54 ; }

The implementation of the USRP2 class is found in usrp2_sink_32fc.cc and

is included as Listing 3.2. Several of the class functions are trivial. For example, the 30

make function simply creates a new instance of the class using the new operator

and returns a pointer to the newly created SPB. The constructor does nothing

except initialize the parent super class.

The real functionality of the SPB, as in all SPBs, is implemented in the work()

function. Though, even here much of the details of the implementation are hidden

by the underlying implementation class. On lines 65–66, the work function makes

a call to the detail class’s (d_u2) tx_32fc() function, which takes care of writing

the input_items to the USRP2 hardware.

Listing 3.2. usrp2 sink 32fc.cc

32 u s r p 2 s i n k 3 2 f c s p t r 33 usrp2 make sink 32fc ( const std::string &ifc , const std:: string &mac addr ) 34 throw (std:: runtime e r r o r )

35 { 36 return gnuradio:: get i n i t i a l s p t r (new u s r p 2 s i n k 3 2 f c ( i f c , mac addr ) ) ;

37 } 38

39 u s r p 2 s i n k 32fc :: usrp2 s i n k 3 2 f c ( const std::string &ifc , const std:: string &mac addr ) 40 throw (std:: runtime e r r o r ) 41 : u s r p 2 s i n k base(”usrp2 s i n k 3 2 f c ” , 42 g r m a k e i o signature(1, 1, sizeof ( gr complex ) ) , 43 i f c , mac addr )

44 { 45 // NOP

46 } 47

48 u s r p 2 s i n k 32fc::˜usrp2 s i n k 3 2 f c ( )

49 { 50 // NOP

51 } 52

53 int 54 u s r p 2 s i n k 32fc ::work( int noutput items , 31

55 g r v e c t o r c o n s t v o i d s t a r &input items , 56 g r v e c t o r v o i d star &output items )

57 { 58 gr complex in = ( gr complex ) i n p u t i t e m s [ 0 ] ; ∗ ∗ 59

60 usrp2 : : tx metadata metadata; 61 metadata.timestamp = 1; − 62 metadata.send now = 1 ; 63 metadata. start o f b u r s t = 1 ;

64

65 bool ok = d u2 >t x 3 2 f c (0 , // FIXME: someday, streams will have channel− numbers 66 in , noutput items , &metadata); 67 i f ( ! ok ) { 68 std : : c e r r << ” u s r p 2 s i n k 3 2 f c : t x 3 2 f c f a i l e d ” << std : : endl ; 69 return 1; // say we’re done − 70 } 71

72 return noutput items ;

73 }

3.1.4 Circular Buffers

Circular buffers are used to store the intermediate results from each SPB. Fulfill-

ing the role of interconnecting lines in a block diagram, the buffers provide the

temporary storage needed as the results of each SPB are sequentially evaluated.

When a SPB executes, it consumes a portion (or all) of the data available in each

of its input buffers and uses that data, possibly with stored state data—such as

the previous input samples required to make a FIR filter continuous—to generate

output data in the output buffer or buffers. In general, a SPB can consume and

produce data in an arbitrary, or time varying, ratio. The logic of the circular

buffers enables the scheduler to correctly track the available and required data

for each block. However, as is quite often the case in signal processing, a con- 32 stant ratio is maintained between the number of consumed input samples and the number of generated output samples. These blocks belong to the special subclass of synchronous blocks which generate a predicable number of samples based on the number consumed. Such information is used by the scheduler to optimize the execution of SPBs to cause the largest number of SPBs to have sufficient data to allow execution.

3.1.5 Flow Graphs

It is common practice to use block diagrams to express the flow of a signal through a system. Each block represents a signal operation or decision point in the execution of the system functions. This same approach is used to describe the functionality of a software-implemented signal processing scheme. In GNU Radio, a non-cyclic uni- directional graph, called a flow graph, is used to describe the interconnection of the instantiated SPBs. In computer science, this data structure can be implemented as a linked list of pointers to the SPBs. In particular, GNU Radio uses a depth-first searching algorithm to establish the end-to-end paths in the graph and to verify that it is indeed non-cyclic.

Figure 3.3. Flow Graphs define the interconnection of several SPBs. 33

A flow graph, such as the one shown in Figure 3.3, does not need to be connected

(i.e., all elements can be reached from a common root element). It is possible for a single flow graph to have multiple sources and sinks, creating completely inde- pendent graphs. Such is the case when several independent signal paths operate independently. For example, a receive and transmit path may be implemented under the same flow graph but compose two separate graphs, each with its own source and sink terminators.

GNU Radio implements the flow graph through a “top block.” Perhaps more accurately viewed as a top-level container and not as a block in the sense of the

SPBs, it represents the instantiation of a single flow graph that, in turn, embodies the connection of several SPBs. Each GNU Radio program must contain a top block. In analogy to C-programming the top block is the main() function or the entry point of the program. It ties the several components of GNU Radio together by linking the flow graph and the SPBs with the scheduler.

Figure 3.4. A GNU Radio Top Block. 34

Similar to the top block, hierarchical blocks can also be defined that abstract a

flow graph segment into a modular component. Each hierarchical block has input and output port definitions similar to a regular SPB, but allows its functionality to be specified in terms of a flow graph composed of other SPBs. In this way, a hierarchical block is a sort of subroutine implementing a common sequence of signal operations. For example, GNU Radio has several predefined hierarchical blocks that implement the steps needed to perform FM Radio (de)modulation.

3.1.6 Scheduler

The ability of the GNU Radio to simulate simultaneously executing signal process- ing operations is provided by the SPB scheduler. The scheduler is both a critical and irrelevant portion of the GNU Radio project depending on perspective. For the average user, its operation should remain transparent to the signal processing providing only the simulated parallel execution. However, its role within the GNU

Radio system is important to understand and comprises one of the more complex aspects of the project.

Basically, the scheduler is a prioritized list of all of the SPBs and their states, that is, information about how much unprocessed data is in their input buffers and how much space is free in the output buffer. The goal, of course, is to ensure that blocks are run in the correct order so that when each is given a chance to run it has a sufficient amount of input data to process while at the same time minimizing the time when no suitable blocks can be run. In general, this task has no simple solution and has been at the center of operating system research for 35 some time. Accordingly, in lieu of implementing its own solution, the GNU Radio instead provides a thin layer above the host operating system’s multiprocessing functionality.

The default scheduler in GNU Radio is called the Thread Per Block (TPB) scheduler and its function is hinted by its title. In the TPB scheduler, each SPB is provided its own operating system thread in which to run. On symmetric mul- tiprocessing (SMP) systems, the complicated task of scheduling and associating a particular processor core to a SPB is shifted to the responsibility of the underlying operating system.

3.1.7 SWIG

Python, although providing comprehensive extensibility support for the C lan- guage, does not effectively support the object-oriented features of C++. Also, since the GNU Radio project draws heavily on the use of object-oriented pro- gramming concepts, a suitable system was needed to ease the merger between the optimized and efficient C++ code and the dynamic and rapidly developed Python code. This merger is accomplished by the Simple Wrapper and Interface Generator

(SWIG).

SWIG provides library interfaces between lower-level languages such as C and

C++ to higher level languages such as Python and Ruby. It does so by parsing the function and class declarations of the ‘.h’ files and generating intermediate code used by the higher level language to seamlessly access the functions and objects defined in the lower level language. In the context of GNU Radio, this means the 36

SPBs and supporting software (scheduler, flow graphs, etc.) can be accessible via

Python.

3.2 The USRP2

While the GNU Radio project provides the software implementation of the radio processing needs, some hardware is still required to digitize the incoming RF signal and transmit the RF version of the data stream generated by the computer. For this purpose, the Universal Software Radio Peripheral 2 (USRP2) is used. The

USRP2 provides a Gigabit Ethernet interface to a standard PC and a high speed

ADC and DAC as well as an SRAM FPGA.

The USRP2 (as well as the USRP1) are compatible with several RF daughter boards that provide front-end interfaces to antennas including the appropriate analog filters, mixers, and amplifiers for a wide selection of frequency ranges. The

RF daughter boards translate the RF to an IF or even to baseband while some are designed only for baseband operation and do not provide any RF processing. For this project, only the baseband BasicRX and BasicTX daughterboards were used.

After passing through the daughter board, the signal is sampled by a high-speed analog-to-digital converter and presented to the FPGA. The FPGA implements several decimating filters and a CORDIC-based digital mixer. The FPGA also im- plements a soft microprocessor and Gigabit Ethernet MAC interface that manages the link to the host PC. Similarly for the transmit path, the FPGA provides IF mixing and interpolation before converting the signal in a high-speed digital-to- analog converter. 37 3.2.1 Hardware

The capabilities of the USRP2 exceed those of the USRP1 in several key areas:

(1) the Gigabit Ethernet interface simplifies the implementation of “in-band” data

(the inclusion of commands within the data stream), (2) it supports a wider signal bandwidth through a higher-rate ADC and use of Gigabit Ethernet opposed to

USB, and (3) it supports a more capable FPGA. In a more pragmatic sense, the increased accessibility of the FPGA also allows for easier development.

The USRP2 uses the LTC2284 from Linear Technology [30] to sample the in- coming RF signal. This chip provides two independent ADCs that can be used, for instance, to sample in-phase and quadrature IF signals. There are no components between the daughter board interface connector and the ADC.

On the transmit side, an Analog Devices AD9777 [31] provides dual 160 Msps

DACs. The DAC also supports 2 , 4 , and 8 interpolation rates up to 400 Msps × × × at 8 interpolation. The integrated Fs/2, Fs/4, Fs/8 complex mixer allows the × input to be projected to one of the higher Nyquist zones while not requiring a higher data rate.

Central to the board, the FPGA—a Xilinx Spartan 3-2000 [32]—implements the logic connecting the ADC and DAC to the Gigabit Ethernet interface. The

FPGA contains a soft microprocessor, Ethernet MAC, RX and TX DSP logic, and an internal buffer used in moving the data through the FPGA. A RAM chip is also accessible through the FPGA, but is not currently used in the design. The

FPGA is configured (including the soft microprocessor firmware) via a micro SD

Card. A Xilinx XC9572 CPLD is used as the boot supervisor by accessing the SD 38 card and configuring the FPGA on power up. The details of the ADC, DAC, and

FPGA are summarized in Table 3.1.

The system is clocked at 100 MHz (50-MHz microprocessor clock) by a voltage- stabilized controlled oscillator (VOCX) but also supports the input of a 50-Ω- terminated differential clock through an SMA connector. Additionally, a Pulse-

Per Second (PPS) input (50-Ω single-ended) input provides timing synchronization with an external reference.

Finally the USRP2 offers several connectivity resources including the Gigabit

Ethernet interface and a set of LVDS (Low-Voltage Differential Pair) lines directly interfaced to the FPGA. The LVDS connection enables direct communication be- tween multiple USRP2s.

Analog-to-Digital Converter LTC2284 Max. Sampling Rate 105 MHz Sampling Bits 14 bits Input Range 1–2 Vpp Channels 2 (independent) Digital-to-Analog Converter AD9777 Max. Sampling Rate 160 MHz Sampling Bits 16 bits Interpolation 1 , 2 , 4 , 8 (Max 400 Msps at 8 ) Channels 2× (I and× Q)× × × FPGA Spartan 3 2000 System Gates 2,000,000 Block Ram 40 18-kbit blocks Multipliers 40 18 18 multipliers × Table 3.1. USRP2 Hardware Specifications 39 3.2.2 FPGA

The primary role of the FPGA is in interfacing the ADC and DAC to the Gigabit

Ethernet interface. To do this, the FPGA logic implements receive and transmit digital signal processing paths, an Ethernet Media Access Controller (MAC), a microprocessor to control the Ethernet MAC, as well as a large buffer used to transfer the data between the system components. Figure 3.5 shows schematically the interconnection between the elements of the FPGA. In the following sections each of the major FPGA components are described.

The soft microprocessor, responsible for managing the Gigabit Ethernet in- terface and configuring the USRP2, is a aeMB processor core [33]. In keeping with the open source tradition, aeMB is an independent open source project that mimics the proprietary Xilinx MicroBlaze processor. While not cycle accurate, the aeMB does uses the same instruction set as the MicroBlaze making the open source MicroBlaze GCC Compiler compatible with the aeMB as well. A major dif- ference between the two implementations is the supported peripheral bus. While the MicroBlaze uses Xilinx’s own OPB bus, the aeMB uses the Wishbone bus [34].

The Wishbone bus is an open bus architecture supported by many open source

IP core projects. By having a common and open bus specification, several inde- pendent IP cores are able to work together with minimal effort by the developer.

Ettus has used several Wishbone-compliant cores in the USRP2 that interface to the aeMB processor. It will be to this bus that the extensions to the USRP2 functionality will be interfaced and is described in more detail in Section 4.2.

The DSP portion of the code can be cleanly split between the transmit and 40

Figure 3.5. The internal components of the USRP2 FPGA. 41 receive paths. First, the transmit path accomplishes three tasks: (1) provides for proper scaling of the outgoing data, (2) mixes the signal to an IF or final RF, and (3) provides the necessary interpolation to run the DAC at the system clock frequency of 100 MHz. As Figure 3.6 shows, the incoming data to the TX DSP logic is a 32-bit register where the lower 16-bit word forms the in-phase (I) data and the upper 16-bit word represents the quadrature (Q) data. The I and Q designations, however, are just convention and do not necessarily mean the signal is complex.

It could equally as well represent two completely independent signals. However, as is mentioned later, the signals are treated differently in the IF mixer: one is multiplied by a cosine term and the other by a sine term. The split input is fed into two symmetric channels (an I and Q) composed of a series of interpolation filters.

The first of three filters is a half-band interpolation filter that doubles the sampling rate. A second smaller filter doubles the sampling rate again through another half- band interpolator. Finally, a programmable interpolation rate Cascaded Integrator

Comb (CIC) filter increases the data rate to the desired value. The register width of all of the USRP2 filters are 18 bit, so the 16-bit inputs are sign extended to 18 bits in length. A quadrature mixer multiplies the I and Q channels by a cosine and sine waveform, respectively, generated by a CORDIC numerically controlled oscillator

(NCO). The frequency of the NCO is determined by a register that sets the phase increment advanced each clock cycle. This register is later used to interface the frequency hopping-extensions to the existing DSP paths. The receive path follows a similar sequence and is depicted in Figure 3.7.

A set of eight FIFO-like buffers are used as a staging area connecting the high- throughput components of the FPGA, namely the Ethernet MAC, RX and TX 42

Figure 3.6. The transmit path digital signal processing operations. 43

Figure 3.7. The receive path digital signal processing operations. 44

DSP paths, and the SERDES off-board connection. The buffers are implemented as a dual port 2-Kb (32 512) block ram within the FPGA. Each of the buffers are × interfaced to the microprocessor (a quarter of the address space is consumed by the

8 buffers) with the other port dedicated to one of the aforementioned components.

Four of the buffers have a read-only external interface (the transmit side of the

Ethernet MAC, TX DSP path, and SERDES) while the other four buffers are write- only (the receiving side of the Ethernet MAC, RX DSP path, and SERDES). The microprocessor is responsible for copying data between the buffers. For example, to connect the receiving end of the Ethernet interface to the TX DSP path, the microprocessor must copy the data from the Ethernet write buffer to the read buffer of the transmit path.

3.2.3 Firmware

Since the microprocessor is required to copy data between the DSP paths and the

Ethernet interface, it must run a program that handles the data accordingly. The actual program is slightly more complicated than simply copying data between the buffers in the buffer pool. The processor must also decode the received Ethernet packets, and properly format outgoing packets coming from the receive DSP path.

Part of the task of decoding incoming Ethernet packets is also responding to control packets by executing the correct action and forwarding the data packets to the transmit DSP path.

A simple state machine handles the passing data packets between the buffers.

Defined in dbsm.h, the state machine monitors the status of the buffers through 45 registers mapped to the address space from the Wishbone-connected buffer sta- tus module. When the status register indicates that the buffer is not empty the state machine calls a packet inspection function to determine what to do with the received packet. If the packet corresponds to a control sequence, the packet is handled immediately by the correct routine and a response packet is generated.

Otherwise, if the packet is intended for transmission, the state machine strips the packet headers and copies the data to the transmit buffer.

A second state machine handles the opposite data path where data is received by the RX DSP path and is sent to the Ethernet interface in a similar manner.

When the state machine detects that a sufficient amount of data has been written to the buffer from the RX DSP path, it copies the data to the Ethernet transmit buffer applying packet headers in the process.

3.2.4 GNU Radio Interface

To interface with the USRP2, support must also be implemented on the host computer running GNU Radio. Since the interface is based on plain Ethernet packets, much of the low level work of receiving the data is accomplished by the network layer of the underlying OS. The GNU Radio USRP2 code is left to decode the packets and pass the data into the GNU Radio flow graphs.

This task is carried out by a separate thread (separate from the other threads created by the scheduler for each SPB) responsible for maintaining a raw socket connection to the host Ethernet interface connected to the USRP2. In a similar fashion to the packet filtering on the USRP2, the socket-monitoring thread applies 46 a packet filter to the incoming ethernet packets and forwards the data to the appropriate handlers. In the case of data packets, the data is written to the data buffer connected to the USRP source SPB. Transmitting data to the USRP happens similarly. Data is read from the USRP sink SPB buffer and after being formatted and framed with the correct headers, the new packet is sent over a socket connection to the OS network layer where it is sent to the USRP2.

3.3 Using GNU Radio

When using GNU Radio to implement an SDR system, knowledge of the preceding sections, that is, of the underlying implementation of the GNU Radio system, is generally not needed. Indeed, that is a major motivation for extending the extra effort required to separate the Python runtime from the C++ implementation.

The idea is that a user of GNU Radio should not need to be intimately familiar with the details of its inner workings in order to develop a software radio system.

The intended use case for GNU Radio is one in which the user builds a radio by pulling together signal processing blocks from an existing library. In this manner, the user need only to know which blocks are required, and how they are to be organized to successfully implement a working radio system. The details of the underlying system are hidden, allowing the user to focus on the task of developing the appropriate algorithms instead of needlessly worrying about the details of its implementation.

In this section, a review of the basic structure of a GNU Radio program is pre- sented with references made to the underlying framework covered in the previous 47

sections where appropriate. Unlike the inner workings of the GNU Radio system,

several good tutorials have been written to get the novice up to speed on the use

of GNU Radio. The reader is referred to [22], [35], [36], [37], and [38].

The following example shows how to use the USRP2 within the GNU Radio

system. The code configures a 500-Hz tone to be output through the USRP2 at a

center frequency of 1 MHz while simultaneously playing through the PC speakers

a signal received at 1 MHz.3

Listing 3.3. usrp2 example.py –Imports

1 #!/usr/bin/env python

2

3 from gnuradio import gr , gru , eng notation , optfir 4 from gnuradio import usrp2 5 import sys 6 import math

The first line of the file, shown in Listing 3.3 and common to all unix scripts, is

called the “shebang”, which instructs the operating system on how to execute the

file. In this case the program /usr/bin/env~python selects the python interpreter to execute the following text in the file. For this to work, the user must have

execute permissions for this file. The remaining lines then import the GNU Radio

libraries (gr and gru), the USRP2 library, as well as some standard python libraries

(sys and math). The “from gnuradio import X” form adds all of the objects in the

module ‘X’ to the current namespace. In other words, the module name does not

need to be prefixed when referencing one of the objects defined in the module. On

the other hand, the “import sys” declaration does not add the sys module to the

current namespace. To access its members, references must be prefixed with the

3The example file usrp2_example.py is included in its entirety as part of Appendix B. 48

module name, sys.

Listing 3.4. usrp2 example.py –Top Block

8 class usrp2example(gr. top block ) : 9 def i n i t (self ,argv): 10 gr . top block . i n i t ( s e l f )

The next three lines of code (Listing 3.4) declare and set up the top block,

or the overall container for the GNU Radio code used in this program. The first

line declares a new class, usrp2example(), which inherits the gr.top_block()

class. Then, as the first member of the new class, an initializer function is defined.

The name __init__(self,argv) is important: in Python, whenever an object

is created, its __init__() function is executed. Therefore, this function will be

called when the top block class is finally created. The first task of this initialization

function is, in turn, to call the initialization function of the inherited top block

class. Internally, this function call is going to cause GNU Radio to prepare the

runtime environment by allocating a scheduler and setting up an empty flow graph.

All that is left is to define the SPBs and their connectivity.

Listing 3.5. usrp2 example.py –USRP source and sink

12 # Select netwok interface: /dev/eth1 13 u s r p 2 interface = ”eth1” 14 mac addr = ”” # By default the first USRP2 found is used

15

16 s e l f . u tx = usrp2.sink 3 2 f c ( u s r p 2 interface , mac addr ) 17 s e l f . u rx = usrp2.source 3 2 f c ( u s r p 2 interface , mac addr )

At first, the USRP2 sink and source blocks are instantiated from the USRP2

library. Line 16 of Listing 3.5 creates the USRP2 sink SPB and saves the reference 49

to self.u_tx. In Python, variables that begin with ‘self,’ (or more correctly are

members of the self object) are accessible to all of the class methods. Although it

is not required in this example (since the SPBs defined are not accessed by another

function), it is common practice to make SPBs accessible to the entire class. Line

17 declares the USRP2 source SPB. The arguments to each function specify the

network interface (a string defined by the usrp_interface variable) and the MAC

address of the USRP (an empty string will select the first USRP2 found on the

network).

Listing 3.6. usrp2 example.py –USRP Configuration

18

19 # Setup the Transmitter 20 d a c rate = self.u tx . d a c r a t e ( ) # 100 MS/ s 21 u s r p i n t e r p = 100 22 s e l f . u tx . s e t interp(usrp i n t e r p ) 23 (i,q) = self.u tx . d e f a u l t s c a l e i q ( u s r p i n t e r p ) 24 s e l f . u tx . s e t s c a l e i q ( i , q ) 25 u s r p t x r a t e = d a c r a t e / u s r p i n t e r p # 1 MS/ s 26 s i g n a l r a t e = u s r p t x r a t e / 10 27 s e l f . u tx . s e t l o offset(1000000) # IF at 1 MHz 28 print ”Transmitter Configured ...”

Once the USRP SPBs have been created, several member functions are called

to properly configure the USRP. Lines 19 to 27 of Listing 3.6 begin by configuring

the transmit side of the USRP2. The sampling rate of the DAC is obtained through

the self.u_tx.dac_rate() function call, a member function of the USRP2 class

that has been exposed to Python through the SWIG interface. For the USRP2,

this call returns the value of 100 MHz, which is the rate of the on-board oscillator.

However, having a function call to retrieve this value increases the flexibility of

the code. If the USRP hardware were to change or if the code were ported to a 50

new USRP platform, no change would be required in the software. The next few

lines (21–22) configure the interpolation factor of the FPGA transmit DSP path.

A factor of 100 is used here to reduce the data rate to 1 MHz. In general, the

interpolation factor must be a multiple of 4 since the two half-band filters each

interpolate by 2 and cannot be bypassed. Furthermore, the bandwidth limitation

of the Gigabit Ethernet link places an upper limit of about 25 MHz complex

bandwidth or a minimum interpolation factor of 4.

Line 23 first retrieves default values for the scaling gain to be applied to the I

and Q data samples in the TX DSP path. Line 24 then writes the default values to

the USRP2 internal registers. The scaling gains should be set to provide full scale

gains for both the I and Q channels. The gains may also be used to correct any

mismatch between the I and Q amplitudes. Finally, the frequency of the USRP

local oscillator is set to 1 MHz and a Python print statement informs the user

that everything has proceeded normally. A similar set of statements configure the

receive portion of the USRP2 in lines 30 to 38 (Listing 3.7).

Listing 3.7. usrp2 example.py –Audio Blocks

30 # Setup the Receiver 31 a d c rate = self.u rx . a d c r a t e ( ) # 100 MS/ s 32 usrp decim = 200 33 s e l f . u rx . set decim ( usrp decim ) 34 u s r p r x r a t e = a d c r a t e / usrp decim # 0.5 MS/ s 35 audio decimation = 10 36 a u d i o r a t e = u s r p r x r a t e / audio decimation # ˜50 KHz 37 s e l f . u rx . s e t l o offset(1000000) # IF at 1 MHz 38 print ” Receiver Configured ...”

It is worth noting that all Python statements and Python libraries can be

used within GNU Radio code. There is nothing special about the GNU Radio 51 system. Several other Python libraries do in fact play common roles within GNU

Radio applications. For example, the sys and optionparser libraries are used to introduce command line argument parsing abilities to GNU Radio scripts. The

PyQt libraries can also be used to create full Graphical User Interfaces (GUIs) for

GNU Radio programs. Several examples in the GNU Radio source provide study cases for using these libraries.

The code continues in Listing 3.8 by creating two more SPBs: the audio sink and signal source. The audio sink is found in the audio library and provides a way for GNU Radio data streams to be played through the PC speakers. The audio sink is provided the signal rate of the stream to which it will be connected. Depending on the available sound hardware, only a few signal rates may be acceptable. On limited sound cards, only 44.1 kHz and 48 kHz may be acceptable. In these cases, the user must be careful to achieve these rates through the use of decimating and interpolating SPBs.

A gr.sig_source_c() is created to artificially produce a signal at 500 Hz.

Commonly, this SPB is used to create a local oscillator for downconversion of another signal. In particular, the “_c” extension to the function name provides an indication of the data type expected by this block, in this case, a complex stream.

Most SPBs follow this suffix data-type naming convention. For blocks that accept both an input and output, two letters are used. For example, the suffix _fc specifies a block that expects float inputs and produces complex outputs. FIR filter SPBs specify three characters, with the third used to denote the type of the impulse response. 52

Listing 3.8. usrp2 example.py –connect() statements

40 # Create the audio sink and tone generator 41 self.audio = audio.sink(audio rate , ”” ) 42 self.tone = gr.sig s o u r c e f ( s i g n a l r a t e , gr .GR COS WAVE , 500 , 1)

43

44 self.connect(self.tone, self.u tx ) 45 self.connect(self.u rx, self.audio) 46 print ”Configured ...”

Finally, with all of the blocks created and assigned to a Python variable, the

connectivity of the flowgraph through one or more connect() statements is spec-

ified. The connect() function is a method of the top block class that has been

inherited by the class used to contain all of the code. Accordingly, the function

is accessed through the self reference to the current class. Two lines are used in

this example to link the SPBs. Line 44 connects the output of the signal generator

(saved to the self.tone variable) to the input of the USRP transmitter. Line 45

connects the incoming signal from the USRP to the audio card. Although only two

blocks are provided as arguments to the connect function in this example, several

blocks can be connected via a single connect statement with outputs connecting

to inputs from left to right.

Listing 3.9. usrp2 example.py –main() function

48 i f name == ’ m a i n ’: 49 tb = usrp2example(sys.argv) 50 tb . run ( ) 51 print ”Running ... ”

The final portion of the code, shown in Listing 3.9, lies outside of the class

defined earlier and instead defines the equivalent of the ‘C’ main() function. The

“if” statement detects if the “name” of the current process is “__main__”, which 53 would be the case when the script is executed directly. Since all python files can also be included as libraries to other Python files, this conditional ensures that the top block is not started prematurely as would be the case if this file were included as a part of a larger application. Nevertheless, if executed directly, the conditional passes and an instance of the usrp2example class is created as tb. Up to this point in the code, none of the GNU Radio code as been execueted. The class declaration only defined what should be executed when an instance of the class is created as happens in this statement. As Line 48 executes, the __init__() function defined above executes, making the corresponding function calls to the underlying C++ libraries to create the SPBs and flowgraph. However, even after this has completed, GNU Radio is not running. The final tb.run() statement starts the execution of the flow graph and begins the signal processing.

After the run() function is executed, the execution of the code happens almost entirely within the pre-compiled C++ libraries. This shows that the use of Python has little impact on the performance of the execution of the signal processing code.

The fact that the end of the Python code has been reached only as the actual signal processing begins shows how the Python code is only used as a flexible method of configuring GNU Radio applications. Chapter 4

Waveform Generation and

Processing

This chapter provides documentation on the extensions to the GNU Radio and

USRP2 platforms that were developed to introduce frequency hopping support.

Support for frequency-hopping waveforms is critical for any platform that seeks to implement any of the many military waveforms that use frequency-hopping spread spectrum techniques for jamming and interference immunity. However, the precise timing requirements of frequency-hopping waveforms pose special problems for

SDR systems. 55 4.1 Software-Defined Frequency Hopping

4.1.1 Complications

To achieve communication over a frequency-hopping modulation, the transmitter and receiver must be synchronized at three levels. First, for any digital communi- cation system, frequency-hopping systems included, the receiver must be able to recover the data clock through the use of a clock recovery technique traditionally requiring a phase-locked loop. Although this first level of synchronization requires the most precision in terms of the timescales involved (typically on the order of pico- or nano-seconds), relatively few samples are required to analyze and correct for any phase error. That is, obtaining the correct synchronization relies on only a few of the immediately neighboring samples and the receiver can quickly adjust its phase to correct for the error. In a software implementation, the phase correc- tion can be calculated using a small number of the previous samples and does not require costly correlation techniques.

Second, frequency-hopping waveforms must be aligned such that frequency transitions occur simultaneously for the receiver and transmitter. In the case of a point-to-point network, this alignment can be obtained by a short correlation be- tween the received signal and a known synchronization word occurring on a known beacon frequency. Indeed, Shah proved that it was possible to receive a frequency- hopping waveform using a software radio by this method [17]. However, when several transceivers belong to a common network, such as found in a SINCGARS network, it becomes necessary to define a single absolute time when all member- radios should hop frequencies. Reception of a frequency-hopping packet can still 56 be obtained using the correlation procedure outlined above. However, difficulty arrises when transmitting over the frequency-hopping network. To correctly align the transmitter to the expectations of the receivers, the transmitting radio must have a means of controlling when the frequency transitions occur and when the data is transmitted within the frequency hop period to a precision in terms of a few microseconds.

Finally, at the coarsest level, both the transmitter and receiver must know their current position within the hopset to transmit or receive at the correct frequency.

Determining the correct position within the hopset requires an absolute time in hours, minutes, and seconds to within the accuracy of a few frequency hops (on the order of milliseconds). Being the most forgiving in terms of precision, a time-of-day reference is easily provided by GPS disciplined clock.

In a traditional (or hardware-based system), correlation techniques provide the necessary precision to reliably synchronize the internal oscillators of those systems.

Furthermore, even when obtaining a strong correlation is not always possible, the stability of the internal oscillators provide accuracy to correctly manage the radio’s synchronization. As has been well known in communication system design, the stability of the local oscillator largely determines the capability of the radio.

In software-based approaches, the dependency on a stable and accurate oscilla- tor is just as important if not more critical. Implicit in all of the signal processing operations that occur in software is the assumption of a precise, known, and per- fectly stable clock from which digital sampling is performed. The introduction of time-domain jitter (frequency-domain phase errors) is detrimental to the overall dynamic range just as increased noise temperature is within the context of an 57 analog system. Therefore, commonly, digital systems—especially signal sampling systems—are clocked by extremely precise and stable oscillators.

However, precise oscillator stability is only required of the analog-to-digital converter during the sampling process. Subsequent processing can occur slightly faster, slightly slower, or at any rate. Once the signal has been sampled, physical time has no bearing on the digital samples. Digital signal processing is simply the mathematical transformation of a series of discrete values to which a physical meaning can be applied. During the mathematical manipulation, time is merely encoded as an assumed parameter derived from the sampling rate of the ADC.

The divorce of time from signal processing has been an advantage for digital systems. In a digital system, the engineer need not be concerned about the intricate details of phase delays, propagation speeds, and cable lengths. Rather time is abstracted by the sampling process, and all that need be established is a processing rate that equals or exceeds the input rate (assuming a real-time system; in a non- realtime system even this restriction is waved). In fact, without the disassociation of time from the signal processing algorithms, GNU Radio could not function in its current form. The illusion of simultaneity created by the scheduler (see Section

3.1.6) inherently relies on this time-independent property.

A significant problem, however, is posed by signals that require knowledge of the absolute time, such as when considering frequency-hopping waveforms. In this case, the software system must have information about the state of the signal represented by the current samples in the context of the frequency hop period. In other words, the radio must determine if the current samples represent the signal immediately after or before a frequency transition (the blank period) or if the 58 current samples correspond to the middle of the waveform (where data should be encoded).

The problem can be rephrased in another way analogous to stochastic processes.

The current GNU Radio implementation operates on continuous streams of data with an assumed independence of absolute time. In statistical parlance, the signal is said to be “stationary” or time-invariant, meaning it is described by a function of time differences, or lags. For stationary systems, the full statistics can be obtained by looking only at the properties of the system in terms of its properties between time intervals and independent of any particular time. For non-stationary systems, of course, this is not valid and one must consider the current, absolute time in calculating the statistical properties of that system. In other words, the statistical properties for a non-stationary system can change as a function of the absolute time. Following this analogy, a frequency-hopping waveform could be considered non-stationary as information on the position in the hop-set is required.

4.1.2 Comprehensive Solution

The analogy to stationary and non-stationary stochastic processes hints at a pos- sible solution for time-dependent signals. In the notation for stationary systems, the statistics can be expressed in terms of lags, i.e., time differences. On the other hand, when non-stationary systems are analyzed, it becomes necessary to carry around a reference to the absolute time in the arguments to the statistical properties.

If all that is needed to express a non-stationary system is an additional ref- 59 erence to the absolute time, perhaps encoding the absolute time within the data stream is sufficient. Indeed, this is an active area of research for both the SDR community and GNU Radio projects. Significant effort by the GNU Radio de- velopers is currently aimed at implementing the VITA Radio Transport (VRT) standard [39] as the underlying signal representation framework throughout GNU

Radio.

VRT specifies a packet-based data stream where signal metadata is encoded within the packet header. The metadata includes information about the state of the receiver when the data was sampled such as IF frequency, sampling rate, and locked status of a PLL loop. Most importantly for frequency-hopping, the metadata also includes timestamp information providing a means of tracking in software exactly when the data was sampled. With this additional sideband data,—which, among other things, specifies the absolute time that data have been sampled—the signal processing operations may be redesigned to take advantage of this new information to correctly handle time-sensitive signals.

However, this comprehensive solution requires substantial changes to GNU Ra- dio. Although a number of developers are actively working towards its implemen- tation, there are many challenges that have yet to be worked out. Among the biggest challenges is the implementation of an efficient message-based processing system integrated into the current framework. Substantial work has been com- pleted on a message based system called mblocks. However, the message-based blocks and stream-based blocks have yet to be satisfactorily integrated into a single framework.

Perhaps equitable to the incongruities between quantum mechanics and general 60 relativity, the message-based and stream-based techniques are fundamentally dif- ferent approaches that solve different problems. The packetized messaging system provides contextual data about the signal through metadata that arrives with the data itself. This allows the signal operations to respond immediately to changing signal parameters but introduces complications to operations such as filters that rely on a continuous stream of data for their operation. Conversely, stream-based processing can easily implement filters but cannot quickly adapt to changes in the state of the signal. Regardless of the final solution, there is significant work and research yet to be completed.

4.1.3 Proximate Solution

In the long run, the additional information provided by the VTR-based GNU Radio system will provide significant new capabilities in handling more complex wave- forms. However, as these solutions are in their infancy, perhaps an approximate and more immediate solution to implementing frequency hopping, in particular, is obtainable. At the core of the problem of implementing frequency-hopping wave- forms, and therefore military waveforms, is obtaining synchronization between the receiver and transmitter. Moreover, this must be done at the data clock level, the hop period level, and the hop set position level.

As outlined before, there are a number of methods for obtaining the data clock from a received signal and several of these techniques are implemented as GNU

Radio SPBs. Also, knowing the position within the current hop set, that is to what frequency the radio should be currently tuned, is also easily determined 61 by a standard time source. The challenge in implementing frequency-hopping waveforms in SDR is achieving synchronization at the frequency hop level.

Without a way to synchronize the software processing to the sampled data, the time-sensitive operations must be performed in the same clock domain as the sampling operation. Because of the lack of a means to synchronize processing within GNU Radio to the signal received by the USRP2, the time critical operations must be implemented in the FPGA on the USRP2. The remainder of this chapter documents the exact modifications and additions to the USRP2 to implement frequency hopping capabilities.

4.2 Frequency-Hopping GNU Radio Extensions

4.2.1 Overview

To add the capability of receiving and transmitting frequency-hopping waveforms, an FPGA module was added that modified the frequency of the local oscillator according to a programmable sequence of values at a predefined rate. Frequency transitions were implemented in the FPGA to achieve precision timing and to minimize latency. Therefore, the frequency hopping (FHOP) FPGA module im- plements the following capabilities:

1. Timer to measure length of hop period,

2. Register to hold hop period length,

3. Ability to control NCO frequency,

4. Register bank to hold NCO frequency list (hop set), 62

5. Counter to determine position within hop set, and

6. Register to enable or disable frequency hop module.

Moreover, the FPGA additions would be of little value if not accessible from the high-level Python code. At the FPGA level, this means the new frequency hopping extension must interface to the microprocessor. Within the microprocessor, capa- bilities must be developed to initialize the FHOP module and parse commands sent over the Ethernet link to configure the module. The new Ethernet FHOP command packets required the development of additional packet structures and their corresponding handling functions. On the other end of the Ethernet link, extensions to the base USRP2 classes provide functionality and control the FHOP module by generating the appropriate Ethernet control packets. At yet higher levels of abstraction, these control functions must be included in each layer up to the SWIG layer enabling control within Python scripts.

4.2.2 USRP2 Extensions

4.2.2.1 Functionality

The local oscillator in both the transmit and receive DSP paths in the FPGA (see

Section 3.2.3) are controlled by a pair of registers that set the phase increment of the numerically controlled oscillator. By adjusting the angle of phase advanced each clock cycle, the phase increment register controls the frequency of the LO and therefore the center frequency of the final mixed RF signal.

The frequency-hopping extension (FHOP) module overrides control of the phase increment registers and updates the value in a pattern consistent with frequency- 63 hopping waveforms. That is, the FHOP module periodically (every hop-period interval) updates the phase increment register with the next frequency in the hop set (increases an index pointer to the hop set list). In this way, if the signal from the host computer is assumed to be baseband, the correct hop set frequency is determined by the offset introduced by the IF mixer.

This approach, however, places two limitations on the overall design. First, it requires an analog front-end do the final conversion to the appropriate RF center frequency. The front end must implement an additional mixer and Volt- age Controlled Oscillator (VCO)—the frequency of which is ideally controlled by software—to shift the frequency-hopping band to the appropriate part of the RF spectrum. Second, the bandwidth of the frequency-hopping band is limited to the

Nyquist frequency of the DAC unless a sufficiently capable front end is provided that can integrate with the FHOP module.

4.2.2.2 Implementation

Shown in Figure 4.1, the FHOP module, designed as a slave device on the Wishbone on-chip bus, provides several control registers, a block RAM to store the hop set, and an interface to the RX and TX DSP paths. The Wishbone bus interface enables microprocessor access to the three registers and block RAM through a memory- mapped region in the microprocessor’s address space. On the DSP side, precise

Local Oscillator (LO) control enables the automatic generation of a frequency- hopping waveform.

At the top level of the FPGA design, the FHOP module is connected to slave

15 of the Wishbone bus. The Wishbone bus [34] defines several control signals 64

Figure 4.1. The FPGA frequency hopping module.

for bus operation. Here, the bus clock (wb_clk), a reset signal (wb_rst), slave 15

strobe (s15_stb), the write enable (s15_we), acknowledgement (s15_ack), bus ad-

dress vector (s15_adr), and data output (s15_dat_o) are connected to the FHOP

Wishbone interface ports. Since all of the FHOP registers are implemented as

write only, the data input (bus direction is expressed with respect to the bus mas-

ter), s15_dat_i, is assigned a constant value of zero. The bus error (s15_err)

and retry (s15_rty) signals are not implemented and are shorted to ground as

well. On the DSP side, the module is provided with the DSP clock (dsp_clock),

pulse-per-second timing input (PPS), and outputs the phase increment register

(fhop_phase), module enable status (hop_en), and a vector that may be used for

debugging of the module (fhop_debug).

Listing 4.1. u2 core.v –Top Level Frequency Hopping Module

691 // Frequency Hop Register , Slave 15

692

693 fhop bank #(.AWIDTH(16) , .DWIDTH(32) ) fhop bank 65

694 ( . wb clk ( wb clk ) , 695 . wb rst ( wb rst ) , 696 . w b s t b i ( s 1 5 s t b ) , 697 . wb we i ( s15 we ) , 698 . wb ack o ( s15 ack ) , 699 . wb adr i ( s15 adr ) , 700 . wb dat i ( s 1 5 d a t o ) , 701 . s y s c l k ( d s p c l k ) , 702 . f r e q ( fhop phase ) , 703 . master time(master time ) , 704 .debug ( fhop debug ) , 705 . hop en ( hop en ) ) ;

706

707 assign s 1 5 e r r = 0 ; 708 assign s 1 5 r t y = 0 ; 709 assign s 1 5 d a t i = 0 ;

In the top-level file (u2_core.v), part of which is shown in Listing 4.1, the

Wishbone bus signals originate in the Wishbone master, which is, in turn, con-

nected to the microprocessor. To fit the FHOP module within the address space,

several slight modifications were made to the Wishbone master core. First, the

address decoder was expanded to decode 6 bits instead of 5 bits. This provided

finer-grained control of the memory regions assigned to each slave device. A neces-

sary adjustment, the increased address decode width allowed the reorganization of

the memory space to provide more memory to the last slave device (slave 15, the

FHOP module). This allowed the the hop set memory to be significantly larger.

The FHOP module is composed of three dual port registers, a dual port ram,

an indexing block, and a top level block. The top-level block implements the

Wishbone interface, decodes the address input to select the appropriate register,

and instantiates all of the component blocks.

Since the microprocessor clock (wb_clk) and DSP clocks run at different rates, 66

it is necessary to re-clock each register to the DSP clock. This is done through a

dual-port RAM block for the hop set bank and through a dual-port register for each

of the registers. On the write side of the register, a write enable controls if the flip-

flop is updated. On the reading DSP side, the first register is continuously clocked

into a secondary register by the DSP clock. Although this may seem redundant, it

is important to ensure register reads are always synchronized with the read clock.

Otherwise, there is a low probability that the register could be read as it is being

written to leading to a race condition where the outcome is undefined. Use of a

dual-port register or block ram eliminates the possibility of race conditions.

Listing 4.2. dual reg.v - Dual Port Register

30 reg [WIDTH 1:0] data ; − 31 reg [WIDTH 1:0] dob r ; − 32

33 assign doa = data ; 34 assign dob = dob r ;

35

36 always @( posedge c l k a ) 37 begin 38 i f ( we ) 39 data = di ; 40 end

41

42 always @( posedge clkb ) 43 begin 44 i f ( ˜we ) 45 dob r = data ; 46 else 47 dob r = dob r ; 48 end

The core of the FHOP module is implemented in the hop set indexer found

in indexer.v. Here, two counters (cntr_interval and cntr_index) increment

through the hop period and hop set respectively. The interval counter increments 67

every clock cycle—which for the USRP2 is equivalent to every 100 ns—to keep track

of the elapsed time for the current hop period. The 32-bit register allows hop period

durations of up to 7.15 minutes at a resolution of 100 ns. When cntr_interval

matches the value set in the hop_interval register, the timer is reset and the

hop set index (cntr_index) is incremented. The hop set index counter is also

the read address of the hop set block RAM, and by changing its value, the value

read from the block RAM is also changed. The purpose of this logic is to step

through each valid location in the hop set memory bank by incrementing the read

pointer, cntr_index. To prevent reading invalid, or uninitialized, memory, the

set_length register is compared to the current index and triggers a reset to zero

if there is a match. Listing 4.3 shows this logic.

Listing 4.3. indexer.v - Control logic

29 assign max interval = (cntr interval==hop i n t e r v a l ) ; 30 assign max index = (cntr i n d e x==s e t l e n g t h ) ;

31

32 always @( posedge c l k ) 33 begin 34 i f ( r s t ) begin 35 c n t r i n t e r v a l <= 0 ; 36 c n t r i n d e x <= 0 ; 37 end 38 else begin 39 i f ( max interval ) begin 40 c n t r i n t e r v a l <= 0 ; 41 c n t r i n d e x <= c n t r i n d e x + 1 ; 42 i f ( max index & max interval ) 43 c n t r i n d e x <= 0 ; 44 end 45 else 46 c n t r i n t e r v a l <= c n t r interval + 1;

47

48 end 49 end 68

Finally, the FHOP module is integrated to the RX and TX DSP paths through the enable register. The 2-bit enable register controls whether the LO of the RX or

TX paths is controlled by the FHOP module or by the appropriate static Settings register. Bit zero controls the TX path; bit one controls the RX path.

As mentioned, the introduction of the FHOP module to the FPGA fabric also required the modification of the USRP2 microprocessor firmware. Specifically, some initialization code, command packet handlers, and register access code were added to the existing firmware to fully support the FHOP module.

First, the FHOP module was added as Slave 15 on the Wishbone bus. Fortu- nately, the existing USRP2 design only used 15 of the 16 available slave addresses on the bus (addresses start at 0, as Slave 15 the FHOP module is the 16th). How- ever, through some changes in the address space allocated to each slave address, a full 2 kB could be reserved for the FHOP module from address 0xF800 to 0xFFFF.

As a reference, Table 4.1 records the address space assigned to each peripheral including the newly added FHOP module.

Within the microprocessor on the USRP2, the FHOP module is accessed via writes to memory-mapped registers. Located at the base address of 0xF800, a C structure is used to provide shorthand access to the FHOP registers (included as

Listing 4.4). Beginning at the base address and extending 1 kB (0x000–0x3FF), the hop set bank is a contiguous block of 256 32-bit integers. Writes to this memory—and to any of the FHOP registers—must be performed on a 4-byte (1- word) boundary. To dissuade unaligned accesses, each register is defined as a 32-bit integer regardless of its physical size.

Following the hop set region, the three control registers are accessible in the 69

Slave Bus Device Start Address Size 0 System Ram 0x0000 32 kB 1 Buffer Pool 0x8000 16 kB 2 SPI 0xC000 1 kB 3 I2C 0xC400 1 kB 4 GPIO 0xC800 1 kB 5 Buffer Status 0xCC00 1 kB 6 Ethernet MAC 0xD000 1 kB 7 Settings Bus 0xD400 1 kB 8 Interrupt Controller 0xD800 1 kB 9 Master Timer 0xDC00 1 kB 10 UART 0xE000 1 kB 11 ATR 0xE400 1 kB 12 Time Sync 0xE800 1 kB 13 SD Card 0xEC00 1 kB 14 ZBT Ram Bridge 0xF000 2 kB 15 Frequency Hop Module 0xF800 2 kB Table 4.1. USRP2 Microprocessor Address Space

three subsequent fields. The hop period interval is mapped to address BASE+0x400,

the length of the hop set at BASE+0x404, and the enable register at BASE+0x408.

The remaining 1012 bytes of the address space are unused.

Listing 4.4. memory map.h - FHOP Address Space

716 /////////////////////////////////////////////////// 717 // Frequency Hop Registers , Slave 15 718 // 719 #define FREQ HOP BASE 0xF800

720

721 typedef struct { 722 volatile u i n t 3 2 t hop set [ 2 5 6 ] ; // 0x000 to 0x3FF 723 volatile u i n t 3 2 t i n t e r v a l ; // 0x400 724 volatile u i n t 3 2 t s e t l e n g t h ; // 0x404 725 volatile u i n t 3 2 t enable ; // 0x408 726 f r e q h o p r e g s t ; } 727

728 #define f r e q h o p r e g s ( ( f r e q h o p r e g s t ) FREQ HOP BASE) ∗

Part of the responsibility of the microprocessor on the FPGA is to put the 70

USRP2 into a known state on power up or after a reset. This requires several

lines of initialization code for each USRP peripheral and the FHOP module is

no exception. On power up, the FHOP module should be disabled to prevent

unexpected operation. In this state, it is not necessary to specify the value of

the other FHOP registers. These registers must be programmed before the FHOP

module is enabled. This is accomplished in a single additional line in the setup

routine: freq hop regs >enable = 0;. − After initialization is complete, the USRP2 is configured to start accepting

packets from the Ethernet interface. An opcode in the packet header determines

how the packet is to be handled. Data packets are forwarded to the TX data path,

while command packets are handled by the appropriate handler function.

The addition of the FHOP module required the introduction of two new control

packets: one to modify the FHOP control registers, the other to write the hop set to

the memory bank. The control channel packets are defined in usrp2_eth_packet.

h (Listing 4.5). In total, four new packets are defined as each packet requires a

corresponding acknowledgement packet.

Listing 4.5. usrp2 eth packet.h - FHOP Opcodes

211 #define OP FHOP SET CONFIG 22 212 #define OP FHOP SET CONFIG REPLY (OP FHOP SET CONFIG | OP REPLY BIT) 213 #define OP FHOP WRITE HOPSET 23 214 #define OP FHOP WRITE HOPSET REPLY (OP FHOP WRITE HOPSET | OP REPLY BIT)

The SET_CONFIG (Listing 4.6) packet controls writing to the hop period interval

and FHOP enable registers. The packet is a total of 12 bytes in length with the

second 32-bit word (bytes 5–8) specifying the enabled register value and the last 71

word (bytes 9–12) representing the hop period. In each packet, the opcode is the

first byte and all bytes follow network endianness. The packet length field, the

second byte, specifies the number of remaining bytes in the packet not including

the opcode and itself. For example, the SET_CONFIG packet is 12 bytes in total

and the length field should be 10.

opcode length rid zero enabled interval Table 4.2. Set Config Packet Structure

Listing 4.6. usrp2 eth packet.h - Set Config Packet Structure

471 typedef struct { 472 u i n t 8 t opcode ; // OP FHOP SET CONFIG 473 u i n t 8 t l e n ; 474 u i n t 8 t r i d ; 475 u i n t 8 t mbz ; 476 u i n t 3 2 t enabled ; 477 u i n t 3 2 t i n t e r v a l ; 478 AL4 o p f h o p s e t c o n f i g t ; }

opcode length rid zero hopset[0] hopset[1] . . hopset[N] Table 4.3. Write Hop Set Packet Structure

The WRITE_HOPSET (Listing 4.7) packet is variable in length depending on the

length of the hop set. Following the first four bytes of the packet header, each

subsequent 4-byte word is a value in the hop set. The length of the hop set is

calculated from the length of the WRITE_HOPSET packet. In this packet, the length 72

should be given by, L = 4N + 2, where N is the number of values in the hop set

and L is the value of the length field.

Listing 4.7. usrp2 eth packet.h - Write Hop Set Packet Structure

480 typedef struct { 481 u i n t 8 t opcode ; // OP FHOP WRITE HOPSET 482 u i n t 8 t l e n ; 483 u i n t 8 t r i d ; 484 u i n t 8 t mbz ; 485 // Hop set follows here 486 AL4 o p f h o p w r i t e h o p s e t t ; }

Defined in app_common_v2.h/c, the function handle_control_channel_frame()

(Listing 4.8) decodes the packet header and dispatches the correct packet handling

function. Handler functions for both FHOP control packets were added to the

dispatch function to complete the implementation of the FHOP FPGA module.

In the case of the SET_CONFIG packet, handling of the received control packet

is performed inline within the handle_control_channel_frame() case statement.

The handler simply extracts the interval and enable register values from the packet

structure and writes the new values to the FPGA module. The write cannot fail

and immediately sends the reply packet to signal acknowledgment of a successful

command execution.

Listing 4.8. usrp2 eth packet.h - Set Config Packet Structure

580 case OP FHOP SET CONFIG : 581 printf(”fhop s e t c o n f i g : interval:%d, enable :%d n” , \ 582 ( ( o p f h o p s e t c o n f i g t ) payload ) >i n t e r v a l , ∗ − 583 ( ( o p f h o p s e t c o n f i g t ) payload ) >enabled ) ; ∗ − 584 ok = true ; 585 f r e q h o p r e g s >interval = ((op f h o p s e t c o n f i g t ) − ∗ payload ) >i n t e r v a l ; − 586 f r e q h o p r e g s >enable = ((op f h o p s e t c o n f i g t ) − ∗ payload ) >enabled ; − 73

587 goto g e n e r i c r e p l y ;

The WRITE_HOPSET (Listing 4.9) handler is more complex and is implemented in

a separate function, fhop_write_hopset(). This function determines the length

of the hop set from the packet length and uses the value to iterate through the

rest of the packet. The hop set length minus one is written to the FPGA to

properly account for the zero-indexed counter in the FHOP module. After some

pointer manipulations, the hop set phase increment value is written to the hop set

memory bank in line 422 in Listing 4.9. The function also includes a printf()

statement for debugging purposes.1

Listing 4.9. usrp2 eth packet.h - Write Hopset Packet Handler

407 static void 408 f h o p w r i t e h o p s e t ( const o p f h o p w r i t e h o p s e t t p) ∗ 409 { 410 unsigned char h o p s e t l e n ; 411 unsigned char i = 0 ; 412 o p f h o p w r i t e h o p s e t t pp = p ; ∗ 413

414 h o p s e t l e n = ( ( p >len 2) >> 2) ; //subtract 2, and divide by 4 to get num of− words− 415 f r e q h o p r e g s >s e t length = hopset len 1; − − 416 pp += 1 ; // Advance pointer to start of payload

417

418 printf(”fhop w r i t e h o p s e t : %u , l=%u n” , ( ( u i n t 3 2 t ) pp ) , \ ∗ ∗ h o p s e t l e n ) ;

419

420 while ( i < h o p s e t l e n ) { 421 //printf(” %d: %u,@%p n” , i , (( u i n t 3 2 t ) (( u i n t 3 2 t ) pp +i)), (uint32 \ ∗ ∗ ∗ 422 f r e q h o p r e g s >hop set [ i ++] = ( ( u i n t 3 2 t ) ( ( u i n t 3 2 t ) pp − ∗ ∗ ∗ +i ) ) ;

423 } 424 }

1Debug messages are printed to the UART and several exist to provide more information on the operation of the USRP2. 74 4.2.3 GNU Radio Extensions

At the other end of the Ethernet interface, the host computer running the GNU

Radio software needs also to be able to control the new frequency-hopping func- tionality in the USRP2. This is achieved by implementing several functions to send the appropriate Ethernet packets to the USRP2 and several others to abstract the functionality through higher levels of the GNU Radio framework.

At the lowest level, four functions (plus one convenience function) are used to build the proper packet and send it to the USRP2. Each of these functions is defined in usrp2_impl.cc/h.

enable_fhop_rx() - Accepts a boolean argument either enabling or disabling • the FHOP module on the receive path.

enable_fhop_tx() - Accepts a boolean argument either enabling or disabling • the FHOP module on the transmit path.

set_dwell_time() - A convenience function that sets the hop period in terms • of microseconds.

set_dwell_cycles() - The underlying function to set hop period. Argument • in terms of FPGA clock cycles.

write_hopset() - Writes a vector of unsigned integers to the FHOP module • as the hop set phase increment values for the FPGA LO.

Each function follows a similar pattern to transmit the command packet to the

USRP2. Following Listing 4.10, the command and expected reply packets are first defined and memory is allocated for the command packet structure. The header 75

of the packet is filled in with the MAC address of the USRP2 and the control

channel is specified. Next, the corresponding opcode is entered and the length of

the packet is calculated. Although not checked by the USRP2 for these packets,

a packet counter is entered in the RID field. Finally, the payload of the packet is

appended to the packet header.

In the case of the enable functions, the corresponding bit is either set or cleared

for the transmit and receive path enable signals. For the dwell time functions, the

hop period is updated. Since the defined packet structure includes both fields

for the enable and hop period registers, both values are sent to the USRP2 when

either an enable command or set-dwell-time command is issued. The host side

software keeps a state variable holding the previous value of each parameter and

includes this value when sending a configuration packet. Note that all values are

first converted to network endianness before being added to the packet structure.

Finally, the reply packet is initialized and the command packet is transmitted

to the USRP2. The function blocks until a reply packet is received or a timeout

occurs indicating an error in the transaction. If the correct reply packet is received

the handler function reports its success, otherwise it returns the error.

Listing 4.10. usrp2 impl.cc - FHOP Enable RX Function

1096 bool 1097 usrp2::impl:: enable f h o p rx(bool enable)

1098 { 1099 o p f h o p s e t c o n f i g c m d cmd ; 1100 o p g e n e r i c t r e p l y ;

1101

1102 memset(&cmd, 0, sizeof (cmd) ) ; 1103 i n i t e t f hdrs(&cmd.h, d addr , 0 , CONTROL CHAN, 1) ; − 1104 cmd.op.opcode = OP FHOP SET CONFIG ; 1105 cmd.op.len = sizeof (cmd . op ) ; 76

1106 cmd.op.rid = d n e x t r i d ++;

1107

1108 d f h o p e n a b l e d r x = enable ; 1109 cmd.op.enabled = htonl( 1110 ( u i n t 3 2 t ) d f h o p e n a b l e d t x | 1111 ( ( u i n t 3 2 t ) d f h o p e n a b l e d r x << 1) 1112 ); 1113 cmd.op.interval = htonl(d d w e l l t i m e ) ;

1114

1115 pending reply p(cmd.op.rid , &reply , sizeof ( r e p l y ) ) ; 1116 i f ( ! transmit cmd(&cmd , sizeof (cmd) , &p , 4 DEF CMD TIMEOUT) ) ∗ 1117 return f a l s e ;

1118

1119 bool success = (ntohx(reply.ok) == 1); 1120 return s u c c e s s ;

1121 }

Because of the variable length of the write-hopset packet, the building of the

packet is slightly more involved. Since the packet length is not constant, after filling

in the header and opcode to the packet structure, a loop handles appending each

hop set value to the packet. Also, the end-of-packet structure must be manually

added to the end of the hop set packet and the extra memory freed.

As Figure 4.2 shows, the class hierarchy for the USRP2 is several levels deep.

Through each level, functions must be added to expose the root functions described

above. Immediately above the implementation class, the base USRP2 class includes

direct calls to the underlying implementation class. The only exception being the

call to write_hopset(), which is included as Listing 4.11. Here, for convenience

to the higher level functions, the conversion between hop set frequency (in MHz)

and phase angle increment is performed.

Listing 4.11. usrp2.cc - Write Hopset Function

1096 bool 1097 usrp2:: write h o p s e t ( const std :: vector &hopset ) 77

1098 { 1099 // WARNING I ASSUME A DSP CLOCK OF 100MHZ HERE! 1100 std :: vector hopset phase ; 1101 for ( unsigned int i =0; i

1104 return d impl >w r i t e hopset(hopset phase ) ; − 1105 }

The USRP2 is ultimately incorporated into the GNU Radio system through

SPB sinks and sources. The gr-usrp2 series of classes encapsulates the base

USRP2 software into the SPB framework providing compatibility with the rest of

Figure 4.2. The class hierarchy for the USRP2. 78

the GNU Radio system. USRP2 configuration functions such as setting the inter-

polation rate are implemented as method functions of the USRP2 SPB base class,

usrp2_base.cc/h. Incorporating the FHOP configuration functions requires the

addition of several more wrapper functions at this level as well. From the base

class, the sink (transmit) and source (receive) USRP2 SPBs provide the appropri-

ate extensions for transmitting and receiving data to and from the USRP2 while

inheriting all of the functionality of the base class. Finally, included in Listing

4.12, the FHOP functions are exposed to the Python interface through additions

to the SWIG interface file, usrp2.i.

Listing 4.12. usrp2.i - SWIG Interface File

45 p u b l i c : 46 ˜ usrp2 base ( ) ;

47

48 std::string mac addr ( ) const ; 49 std:: string interface n a m e ( ) const ; 50 %rename ( r e a l f p g a m a s t e r c l o c k f r e q ) f p g a m a s t e r c l o c k f r e q ; 51 bool f p g a m a s t e r c l o c k f r e q ( long f r e q ) ; ∗ 52 bool config mimo ( int f l a g s ) ; 53 bool s y n c t o p p s ( ) ; 54 bool sync every pps(bool enable); 55 bool e n a b l e f h o p tx(bool enable); 56 bool e n a b l e f h o p rx(bool enable); 57 bool s e t d w e l l t i m e ( double dwell time ) ; 58 bool w r i t e h o p s e t ( const std :: vector &hopset ) ; 59 std :: vector peek32(uint32 t addr, uint32 t words ) ; 60 bool poke32(uint32 t addr , const std :: vector &data ) ; 61 ; }

The additions made to the USRP2 FPGA, microprocessor firmware, host soft-

ware, and GNU Radio code ultimately provide four additional configuration func-

tions to all of the USRP2 SPBs. 79

enable_fhop_tx() - A true argument enables the FHOP module for the • transmit path NCO. False disables.

enable_fhop_tx() - A true argument enables the FHOP module for the • transmit path NCO. False disables.

set_dwell_time() - Sets the hop period in terms of microseconds. • write_hopset() - Load the hopset to the USRP2. SWIG translates a Python • list to a C++ std::vector().

4.3 Radio Bridging

Notwithstanding the complications introduced by frequency-hopping waveforms, the motivation for this research is based on radio interoperability. As a means of testing the extensions to the USRP2 and establishing a frequency hopping radio bridge, a GNU Radio application was developed to evaluate the performance of the system.

4.3.1 System Configuration

In this demonstration system, an AM-modulated waveform provided by an external radio is received by the USRP2, demodulated, and re-encoded as a narrowband

FM (NBFM) signal that is transmitted using the frequency-hopping extensions.

However, since a suitable receiving frequency-hopping radio is not commercially available, a second, independent, USRP2 receives the frequency-hopping signal that is demodulated and converted to an audio signal. Two GPS receivers are used 80 to provide independent pulse-per-second signals to synchronize the two USRP2s.

Figure 4.3 shows this configuration.

Figure 4.3. The frequency-hopping radio bridge demonstration configuration.

The demonstration application is contained within one Python script, which describes a block diagram similar to Figure 4.4. Moreover, the structure of the overall program is similar to the example covered in Section 3.3 and only the code related to the frequency-hopping additions is covered here. The full source is provided in Appendix A.

Figure 4.4. Block diagram of signal processing for radio bridge demonstration.

Three USRP2 SPBs are defined on two USRP2 boards. On the first, a source

(self.u_cb) to receive the AM Citizens Band Radio signal and a sink (self.u_tx) 81

to transmit the re-encoded frequency-hopping waveform. On the second USRP2,

a source (self.u_rx) receives the frequency-hopping signal.

The CB Receive is configured as in Section 3.3; however, the frequency-hopping

interfaces require additional setup. Included in Listing 4.13, additional USRP2

configuration using the newly developed FHOP functions is necessary to configure

the FHOP module according to the specified waveform. Beginning on Line 61,

set_dwell_time() is called to set the hop period; write_hopset() is used to copy

the list of frequency values (defined on Line 36) to the FHOP module; sync_every_

pps(), although not new with the introduction of the FHOP module, synchronizes

the master USRP2 timer to an external PPS signal; and finally enable_fhop_tx()

is called with a value of ‘1’ to enable the FHOP module. This same configuration is

performed on the receiving USRP2 endpoint as well with the obvious replacement

of enable_fhop_tx() with enable_fhop_rx().

Listing 4.13. cb usrp bridge.py –Frequency Hopping Transmitter Setup

32 class f r e q h o p block(gr.top block ) : 33 def i n i t (self ,argv): 34 gr . top block . i n i t ( s e l f ) 35 s e l f . dwell time = 10 36 self .hopset = range(1000000,11000000,100000) 37 #self.dwell t i m e = 100 38 #self.hopset = [1000000,2000000,3000000,4000000,5000000,600000... 39 #self.dwell t i m e = 500 40 #self .hopset = [1000000,2000000]

41

42 t x interface = ”eth1” #CB Radio rx to fhop tx 43 r x interface = ”eth2” # Fhop rx to audio 44 mac addr = ””

45

46 parser = OptionParser(option c l a s s=eng option )

47

48 s e l f . u tx = usrp2.sink 3 2 f c ( t x interface , mac addr ) 82

49 s e l f . u cb = usrp2.source 3 2 f c ( t x interface , mac addr ) 50 s e l f . u rx = usrp2.source 3 2 f c ( r x interface , mac addr )

51

52 # Setup the Transmitter in F hop mode − 53 d a c rate = self.u tx . d a c r a t e ( ) # 100 MS/ s 54 u s r p i n t e r p = 400 55 s e l f . u tx . s e t interp(usrp i n t e r p ) 56 (i,q) = self.u tx . d e f a u l t s c a l e i q ( u s r p i n t e r p ) 57 s e l f . u tx . s e t s c a l e i q ( i , q ) 58 u s r p t x r a t e = d a c r a t e / u s r p i n t e r p # 0.25 MS/ s 59 s i g n a l r a t e = u s r p t x r a t e / 10 60 s e l f . u tx . s e t l o o f f s e t ( 0 ) 61 s e l f . u tx . s e t d w e l l time( self.dwell time ) 62 s e l f . u tx . w r i t e hopset( self.hopset ) 63 s e l f . u tx . sync every pps ( 1 ) 64 s e l f . u tx . e n a b l e f h o p t x ( 1 ) 65 print ” Frequency Hopping Transmitter Configured ...”

4.3.2 Performance

The critical metrics that define performance for software radios are processor uti-

lization and signal latency. The former provides a measure of the difficulty or

complexity of the signal processing which can be used to determine the computing

requirements for any system that implements the frequency-hopping processing.

When considering a target platform, such as for an embedded implementation,

the processing requirements may be the dominate driving factor in system design.

Secondly, overall latency between the reception of a signal in one format and the

transmission of the same message encoded in another format is important for the

usability of a radio bridging solution. In the example of a two-way voice bridge,

it is preferable to keep the delay as small as possible. Certainly, this delay should

be measured in terms of milliseconds to keep it below the perceptible limits.

Using the demonstration configuration outlined in the previous section, a screen 83 capture of the transmitted frequency-hopping waveform is shown in Figure 4.5.

To exaggerate the visibility of the frequency hopping, a minimum hop set of two frequencies was used: in this case, 100 kHz and 2 MHz with a hop period of 500 ms.

A GPS-provided pulse-per-second signal was used to align the start of each hop set

(the 500-ms period during which the frequency was 100 kHz). In the figure, the modulated frequency hopping signal is shown together with the GPS timing signal clearly showing precise alignment between the PPS signal and the hop transitions.

Figure 4.5. A capture of the frequency-hopping waveform aligned to a GPS PPS signal.

As a measure of the quality of the signal processing and of the negative ef- fects introduced by the FHOP module, the Total Harmonic Distortion (THD) of a single-tone signal was analyzed. Frequency-hopping systems are not truly capa- ble of implementing analog modulation schemes because of the dead-times during 84 which the LO changes frequency. Nevertheless, since analog schemes were used here, thereby avoiding the additional complexities of digital modulation, THD is a suitable measurement to perform.

A monochromatic input signal (read from a .wav file) was passed through the frequency-hopping transmitter and receiver pair where it was recorded to an output

P∞ 2 n=2 Vn .wav file. Calculation of the THD was performed using THD = 2 . Here, V1 th Vn is the voltage of the n harmonic of the received signal, where n = 1 is the fundamental. In practice, the bandwidth (48 kHz in this case) limits the number of harmonics needed to compute the summation.

THD was computed over three test cases, each at a different input tone fre- quency. Table 4.4 summarizes the results. Each of the input tones had a THD of zero within the limits of the test while the corresponding output signal had a

THD of several thousandths of a percent. At 100 Hz and 200 Hz, the THD was slightly over 0.004% while the 500-Hz tone was almost half that, 0.00287%. The reduction in THD for higher tones can be attributed to low-pass filters, which attenuate the harmonics. As a reference, high-fidelity audio signals typically have a THD of < 1%, which demonstrates that this system reproduces the signal very accurately despite the periodic IF carrier frequency transitions of the frequency- hopping waveform.

Tone Frequency THD References 0.00000% 100 Hz 0.00473% 200 Hz 0.00401% 500 Hz 0.00287% Table 4.4. THD of three single-tone test cases. 85

Measuring the system latency was accomplished by passing a 1-Hz pulse through the system and measuring the phase change with an oscilloscope. A signal gener- ator was used to generate the 1-Hz pulse and input to a baseband receiver on the

first USRP2. The signal was received and then transmitted as a frequency-hopping signal by the transmit portion of the first USRP2. A second USRP2 connected to the same computer receives the frequency hopping signal and feeds the data back to the host computer where it is processed to baseband. The received baseband signal is then transmitted again using a baseband transmitter on the transmit side of the second USRP2. This signal is fed to the second channel of an oscilloscope to compare with the reference from the signal generator.

It must be noted that this setup in fact measures twice the actual delay that would be experienced by a radio bridge. The bridge would need only to perform half of the operations implemented in the test setup—either receiving the frequency hopping signal and transmitting another signal or performing the opposite, but not both as is required for the test. Therefore, as an attempt to account for the double path, a reference test was conducted in which the baseband signal received by the

first USRP2 was immediately transmitted by the second USRP2. No processing was performed by the GNU Radio system other than to provide a bridge between the two USRP2s.

The best case (minimum) delay, 2.76 ms, of the pass-through test is shown in Figure 4.7. However, when several tests are run it is apparent that there is significant variance to the achieved delay. A series of five pass-through tests (sum- marized in Table 4.5) reveal a minimum delay of 2.76 ms and a maximum delay of

54.4 ms. The large latency variance suggests that there is considerable dependency 86

Freq. Load Latency [ms] Mean Std. Dev. 800 MHz 10% 54.4 16.9 16.9 2.76 23.2 22.86 19.18 Table 4.5. Pass-through signal latency.

Figure 4.6. System latency measured as the phase delay between a transmitted and received signal. on the underlying operating system in scheduling SPBs and writing to and from the USRP2.

When performing the same latency measurement with the full frequency-hopping test, the load on the CPU and the mean latency increased as would be expected with the additional signal processing now being performed. However, with such large standard deviations, it is difficult to draw any substantiative conclusions. As

Table 4.6 also shows, there is to some extent a reduction in latency as the speed of 87

Figure 4.7. The minimum delay observed during the pass-through test. the CPU was increased.2 Even at the highest clock rate of 2.8 GHz, the mean la- tency of the frequency hopping test is longer than the baseline pass-through value of 22.86 ms.

Several additional similar tests were performed while the CPU load was raised artificially to 80–90% by running a stress testing script that performed a number of math operations in a endless loop. Interestingly, even with the increased demands on the system, the average latency was not increased above the quiescent test case.

A possible explanation for this may lie in the intelligent algorithm by which the

Linux kernel chooses processes to schedule. Normally, processes that are waiting for access to the disk or memory and are not CPU intensive (such as the GNU

2The host machine used for development supported CPU frequency scaling which allowed the CPU clock frequency to be set to one of four values, 800 MHz, 1.6 GHz, 2.1 GHz, and 2.8 GHz. 88

Radio program) are favored over processes that are CPU intensive and do not interact with the disk (such as the stress test application). With this bias, even with additional CPU demand, the memory intensive GNU Radio process is given priority and no substantial increase in latency occurs.

Freq. Load Latency (ms) Mean Std. Dev. 800 MHz 51% 42.6 59.3 58.8 46.0 43.9 42.9 48.9 7.94 1.6 GHz 31% 23.9 24.8 33.6 61.1 39.8 23.7 34.5 14.56 2.1 GHz 30% 53.5 47.9 48.8 55.3 34.6 33.2 45.5 9.45 2.8 GHz 25% 32.3 27.5 18.6 39.3 25.0 25.0 27.1 7.11 Table 4.6. Frequency Hopping Latency versus CPU Frequency.

Finally, it is also worth noting that to obtain the plots in this test, the BasixRX and BasicTX RF daughterboards were modified to reduce the DC distortion of the low-frequency baseband signals. The daughterboards have, by default, an RF transformer to couple the input signal to the ADC or DAC. With the transformer in place, too much distortion of the reference signal occurred to accurately measure the latency. Also, the distortion still present in the waveforms (Figures 4.6 and

4.7) is caused by additional filtering elements on the daughterboards that were not removed. Chapter 5

Conclusions

Frequency-hopping waveforms pose special challenges to software-defined imple- mentations because synchronization in aligning the frequency hopping waveform cannot be achieved with a purely software approach. The challenges are overcome by partitioning the processing between an FPGA and the general purpose com- puter. The FPGA, with its parallel logic, provides the precise synchronization required for hop set alignment.

This thesis has shown that it is possible to use a hybrid reconfigurable-hardware and software approach in implementing a frequency-hopping waveform. Although the specific waveform considered is not formally part of any specification, it does follow the specifications of SINCGARS hop period and nearly matches the band- width of the frequency-hopping spectrum.

Additionally, this thesis should serve as a guide for first-time developers for the

GNU Radio system. Special effort was taken to document an expanded technical description of the GNU Radio system beyond the scope of the several tutorials that simply document its use. GNU Radio and the USRP2 are complex projects 90 that can require several months of investigation in order to become familiar with the design. However, both are very well designed and are important tools for software-defined radio research.

Nevertheless, significant new capabilities will exist within the GNU Radio framework once signal metadata (such as timing) is included in the signal process- ing blocks. The full integration of the message passing infrastructure and adoption of the VRT protocol will be important milestones in the development of the GNU

Radio system. It is only with a robust framework that a reliable and truly flexible software-defined radio system can be obtained. To this end, future effort in imple- mentation of frequency-hopping waveforms should be grounded within the greater context of a complete solution.

For radio bridges, complete flexibility is especially important. To provide drop-in software modules for a given radio modulation scheme, the underlying framework—including both the software architecture as well as the interface to, and actual design of, the signal interface hardware—should provide uniform and comprehensive capabilities supporting all foreseeable waveforms. Only then can the expectation of full flexibility provided by software radio be realized.

While special case implementations, such as the FHOP module considered in this work, only solve particular problems and are not immediately extendable to other situations, several important insights into the problems that will be faced by more encompassing solutions are illustrated. In the case of frequency-hopping waveforms, synchronization at a sub-millisecond precision becomes a major obsta- cle.

This work has shown that such precision can be achieved when the appro- 91 priate logic is implemented within an FPGA rather than solely within software signal processing. The latency measured of even of the simplest pass-through sys- tem is still on the order of 20 milliseconds, far too long for waveforms that hop every 10 ms. When adding additional processing, such as waveform modulation and demodulation, the system delay is marginally increased. However, with the frequency-hopping portion of the waveform implemented via the FHOP FPGA module, the time-critical portion of the waveform processing is performed on the

FPGA, thereby providing a time-insensitive but more complex signal to the host

PC where such complex signal transformations are efficiently performed.

With a view toward future implementations, it seems necessary to partition aspects of communications protocols based on the computational complexity and sensitivity to time delay. The addition of extra metadata in the signal processing algorithms will alleviate some of the current difficulties of software-based schemes.

However, the delay imposed by sequential software evaluation is, in some cases such as the hop set alignments considered here and in TDMA and CSMA waveforms, unacceptable for real-time implementation. In these circumstances, the FPGA- based algorithms are better equipped to meet the stringent timing requirements.

Future work should evaluate the appropriate boundary between programmable logic and microprocessor code. Appendix A

Selected Code Listings

A.1 Python Examples

A.1.1 usrp2 example.py

Listing A.1. usrp2 example.py

1 #!/usr/bin/env python

2

3 from gnuradio import gr , gru , eng notation , optfir 4 from gnuradio import usrp2 5 import sys 6 import math

7

8 class usrp2example(gr. top block ) : 9 def i n i t (self ,argv): 10 gr . top block . i n i t ( s e l f )

11

12 # Select netwok interface: /dev/eth1 13 u s r p 2 interface = ”eth1” 14 mac addr = ”” # By default the first USRP2 found is used

15

16 s e l f . u tx = usrp2.sink 3 2 f c ( u s r p 2 interface , mac addr ) 17 s e l f . u rx = usrp2.source 3 2 f c ( u s r p 2 interface , mac addr ) 93

18

19 # Setup the Transmitter 20 d a c rate = self.u tx . d a c r a t e ( ) # 100 MS/ s 21 u s r p i n t e r p = 100 22 s e l f . u tx . s e t interp(usrp i n t e r p ) 23 (i,q) = self.u tx . d e f a u l t s c a l e i q ( u s r p i n t e r p ) 24 s e l f . u tx . s e t s c a l e i q ( i , q ) 25 u s r p t x r a t e = d a c r a t e / u s r p i n t e r p # 1 MS/ s 26 s i g n a l r a t e = u s r p t x r a t e / 10 27 s e l f . u tx . s e t l o offset(1000000) # IF at 1 MHz 28 print ”Transmitter Configured ...”

29

30 # Setup the Receiver 31 a d c rate = self.u rx . a d c r a t e ( ) # 100 MS/ s 32 usrp decim = 200 33 s e l f . u rx . set decim ( usrp decim ) 34 u s r p r x r a t e = a d c r a t e / usrp decim # 0.5 MS/ s 35 audio decimation = 10 36 a u d i o r a t e = u s r p r x r a t e / audio decimation # ˜50 KHz 37 s e l f . u rx . s e t l o offset(1000000) # IF at 1 MHz 38 print ” Receiver Configured ...”

39

40 # Create the audio sink and tone generator 41 self.audio = audio.sink(audio rate , ”” ) 42 self.tone = gr.sig s o u r c e f ( s i g n a l r a t e , gr .GR COS WAVE , 500 , 1)

43

44 self.connect(self.tone, self.u tx ) 45 self.connect(self.u rx, self.audio) 46 print ”Configured ...”

47

48 i f name == ’ m a i n ’: 49 tb = usrp2example(sys.argv) 50 tb . run ( ) 51 print ”Running ... ” 94 A.1.2 cb usrp bridge.py

Listing A.2. cb usrp bridge.py

1 #!/usr/bin/env python 2 #

3

4 from gnuradio import gr , gru , eng notation , optfir 5 from gnuradio import audio 6 from gnuradio import blks2 7 from gnuradio import usrp2 8 from gnuradio.eng option import eng option 9 from optparse import OptionParser 10 import sys 11 import math

12

13 class f r e q h o p block(gr.top block ) : 14 def i n i t (self ,argv): 15 gr . top block . i n i t ( s e l f ) 16 s e l f . dwell time = 10 17 self .hopset = range(1000000,11000000,100000) 18 #self.dwell t i m e = 100 19 #self.hopset = [1000000,2000000,3000000,4000000,5000000,600000... 20 #self.dwell t i m e = 500 21 #self .hopset = [1000000,2000000]

22

23 t x interface = ”eth1” #CB Radio rx to fhop tx 24 r x interface = ”eth2” # Fhop rx to audio 25 mac addr = ””

26

27 parser = OptionParser(option c l a s s=eng option )

28

29 s e l f . u tx = usrp2.sink 3 2 f c ( t x interface , mac addr ) 30 s e l f . u cb = usrp2.source 3 2 f c ( t x interface , mac addr ) 31 s e l f . u rx = usrp2.source 3 2 f c ( r x interface , mac addr )

32

33 # Setup the Transmitter in F hop mode − 34 d a c rate = self.u tx . d a c r a t e ( ) # 100 MS/ s 35 u s r p i n t e r p = 400 36 s e l f . u tx . s e t interp(usrp i n t e r p ) 37 (i,q) = self.u tx . d e f a u l t s c a l e i q ( u s r p i n t e r p ) 38 s e l f . u tx . s e t s c a l e i q ( i , q ) 39 u s r p t x r a t e = d a c r a t e / u s r p i n t e r p # 0.25 MS/ s 95

40 s i g n a l r a t e = u s r p t x r a t e / 10 41 s e l f . u tx . s e t l o o f f s e t ( 0 ) 42 s e l f . u tx . s e t d w e l l time( self.dwell time ) 43 s e l f . u tx . w r i t e hopset( self.hopset ) 44 s e l f . u tx . sync every pps ( 1 ) 45 s e l f . u tx . e n a b l e f h o p t x ( 1 ) 46 print ” Frequency Hopping Transmitter Configured ...”

47

48 # Setup the Receiver in CB Mode (AM) 49 a d c rate = self.u cb . a d c r a t e ( ) # 100 MS/ s 50 usrp decim = 200 51 s e l f . u cb . set decim ( usrp decim ) 52 u s r p c b r a t e = a d c r a t e / usrp decim # 0.5 MS/ s 53 cb decimation = 20 54 c b r a t e = u s r p c b r a t e / cb decimation # 25 KHz 55 s e l f . u cb . s e t c e n t e r freq( 26.9651e6 ) #CB CH1 56 print ” C i t i z e n s ’ Band Radio Receiver Configured. (CH 1) ”

57

58 # Setup the Receiver in Fhop mode 59 a d c rate = self.u rx . a d c r a t e ( ) # 100 MS/ s 60 usrp decim = 250 61 s e l f . u rx . set decim ( usrp decim ) 62 u s r p r x r a t e = a d c r a t e / usrp decim # 0.4 MS/ s 63 print u s r p r x r a t e 64 f i r decimation = 25 65 f i r interpolation = 3 66 p o s t f i r rate = int(usrp r x rate / (float( f i r decimation)/float(fir interpolation))) 67 print p o s t f i r r a t e 68 audio decimation = 1 69 a u d i o interpolation = 1 70 a u d i o rate = int(post f i r rate / (float( audio decimation)/float(audio interpolation))) # 48 KHz 71 print a u d i o r a t e 72 s e l f . u rx . s e t l o o f f s e t ( 0 ) 73 s e l f . u rx . s e t d w e l l time( self.dwell time ) 74 s e l f . u rx . w r i t e hopset( self.hopset ) 75 s e l f . u rx . sync every pps ( 1 ) 76 s e l f . u rx . e n a b l e f h o p r x ( 1 ) 77 print ” Frequency Hopping Receiver Configured ...”

78

79 # Setup the CB Receive path (based on E. Menendez code) 80 c b r x coeffs = optfir.low pass ( 1 , 96

81 u s r p c b r a t e , 82 3e3 , 83 6e3 , 84 0 . 1 , 85 50 86 ) 87 print ”CBRX FIR CCF : ” , l e n ( c b r x c o e f f s )

88

89 s e l f . c b r x pregain = gr.multiply c o n s t c c ( 1 0 0 . 0 ) 90 s e l f . c b r x filt = gr.fir f i l t e r c c f ( cb decimation , c b r x c o e f f s ) 91 s e l f . c b r x squelch = gr.simple s q u e l c h c c (0 , 0 . 0 1 ) 92 s e l f . cbrx amdemod = gr.complex to mag ( ) 93 s e l f . cbrx dcnotch = gr.iir f i l t e r f f d ((1 , 1), (1,0.98)) − 94 self.connect(self.u cb, self.cbrx pregain, self. c b r x f i l t , 95 s e l f . cbrx squelch , self.cbrx amdemod, self. cbrx dcnotch )

96

97 self.fmtx = blks2.nbfm tx ( s i g n a l r a t e , u s r p t x r a t e ) 98 self .connect(self .cbrx dcnotch, self.fmtx, self.u tx )

99

100 f m r x coeffs = optfir.low pass ( 1 , 101 u s r p r x r a t e , 102 100 e3 , 103 150 e3 , 104 0 . 1 , 105 60 106 ) 107 print ”FMRX FIR CCF : ” , l e n ( f m r x c o e f f s )

108

109 s e l f . a u d i o filt = gr.rational r e s a m p l e r b a s e c c f ( f i r interpolation , fir decimation , fmrx c o e f f s ) 110 self.fmrx = blks2.nbfm rx ( audio rate , a u d i o r a t e ) 111 self.audiogain = gr.multiply c o n s t f f ( 2 . 0 ) 112 self.audio = audio.sink(audio rate , ”” ) 113 self.connect(self.u rx, self.audio filt , self.fmrx, self.audiogain , self.audio) 114 print ”RUNNING . . . ”

115

116 i f name == ’ m a i n ’: 117 tb = f r e q h o p block(sys.argv) 118 tb . run ( ) 97 A.1.3 fhop latency test.py

Listing A.3. fhop latency test.py

1 #!/usr/bin/env python 2 #

3

4 from gnuradio import gr , gru , eng notation , optfir 5 from gnuradio import audio 6 from gnuradio import blks2 7 from gnuradio import usrp2 8 from gnuradio.eng option import eng option 9 from optparse import OptionParser 10 import sys 11 import math

12

13 class l a t e n c y block(gr.top block ) : 14 def i n i t (self ,argv): 15 gr . top block . i n i t ( s e l f ) 16 s e l f . dwell time = 100 17 self.hopset = [1000000,2000000,3000000,4000000,5000000,600000... 18 #self.dwell t i m e = 500 19 #self .hopset = [1000000,2000000]

20

21 t x interface = ”eth1” # sig gen rx to fhop tx 22 r x interface = ”eth2” # Fhop rx to audio/scope 23 mac addr = ””

24

25 parser = OptionParser(option c l a s s=eng option )

26

27 s e l f . u tx = usrp2.sink 3 2 f c ( t x interface , mac addr ) 28 s e l f . u s i g in = usrp2.source 3 2 f c ( t x i n t e r f a c e , mac addr ) 29 s e l f . u rx = usrp2.source 3 2 f c ( r x interface , mac addr ) 30 s e l f . u s i g out = usrp2.sink 3 2 f c ( r x interface , mac addr )

31

32 # Setup the Transmitter in F hop mode − 33 d a c rate = self.u tx . d a c r a t e ( ) # 100 MS/ s 34 u s r p i n t e r p = 400 35 s e l f . u tx . s e t interp(usrp i n t e r p ) 36 (i,q) = self.u tx . d e f a u l t s c a l e i q ( u s r p i n t e r p ) 37 s e l f . u tx . s e t s c a l e i q ( i , q ) 98

38 u s r p t x r a t e = d a c r a t e / u s r p i n t e r p # 0.25 MS/ s 39 s i g n a l r a t e = u s r p t x r a t e / 10 # 25 Khz 40 s e l f . u tx . s e t l o o f f s e t ( 0 ) 41 s e l f . u tx . s e t d w e l l time( self.dwell time ) 42 s e l f . u tx . w r i t e hopset( self.hopset ) 43 s e l f . u tx . sync every pps ( 1 ) 44 s e l f . u tx . e n a b l e f h o p t x ( 1 ) 45 print ” Frequency Hopping Transmitter Configured ...”

46

47 # Setup the Receiver 48 a d c rate = self.u s i g i n . a d c r a t e ( ) # 100 MS/ s 49 usrp decim = 400 50 s e l f . u s i g i n . set decim ( usrp decim ) # 25 KHz 51 s e l f . u s i g i n . s e t c e n t e r f r e q ( 0 ) # Receive baseband 52 print ”RX: ” , a d c r a t e / usrp decim 53 print ”Baseband Receiver Configured ...”

54

55 # Setup the Receiver in Fhop mode 56 a d c rate = self.u rx . a d c r a t e ( ) # 100 MS/ s 57 usrp decim = 400 58 s e l f . u rx . set decim ( usrp decim ) 59 u s r p r x r a t e = a d c r a t e / usrp decim # 0.25 MS/ s 60 rx demod rate = u s r p r x r a t e / 10 # 250 KHz 61 s e l f . u rx . s e t l o o f f s e t ( 0 ) 62 s e l f . u rx . s e t d w e l l time( self.dwell time ) 63 s e l f . u rx . w r i t e hopset( self.hopset ) 64 s e l f . u rx . sync every pps ( 1 ) 65 s e l f . u rx . e n a b l e f h o p r x ( 1 ) 66 print ” Frequency Hopping Receiver Configured ...”

67

68 # Setup the signal generator 69 d a c rate = self.u s i g o u t . d a c r a t e ( ) # 100 MS/ s 70 u s r p i n t e r p = 400 71 s e l f . u s i g o u t . s e t interp(usrp i n t e r p ) 72 (i,q) = self.u s i g out.default s c a l e i q ( u s r p i n t e r p ) 73 s e l f . u s i g o u t . s e t s c a l e i q ( i , q ) 74 u s r p s i g r a t e = d a c r a t e / u s r p i n t e r p # 0.025 MS/ s 75 s e l f . u s i g o u t . s e t c e n t e r f r e q ( 0 ) # Transmit baseband 76 print ”TX: ” , d a c r a t e / u s r p i n t e r p 77 print ”Baseband Transmitter Configured ...”

78

79

80

81 self.ctof = gr.complex t o r e a l ( ) 99

82 self.gain = gr.multiply c o n s t f f ( 1 0 0 . 0 ) 83 self.fmtx = blks2.nbfm tx ( u s r p t x r a t e , u s r p t x r a t e ) 84 self.connect(self.u s i g in, self.ctof, self.gain, self. fmtx, self.u tx )

85

86

87 self.fmrx = blks2.nbfm rx ( u s r p r x r a t e , u s r p r x r a t e ) 88 self.ftoc = gr.float t o c o m p l e x ( ) 89 self.connect(self.u rx, self.fmrx, self.ftoc, self. u s i g o u t ) 90 print ”RUNNING . . . ”

91

92 i f name == ’ m a i n ’: 93 tb = l a t e n c y block(sys.argv) 94 tb . run ( ) 100 A.2 FHOP Module Source Code

A.2.1 fhop bank.v

Listing A.4. fhop bank.v

1 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 2 // fhop bank . v bank of frequency hopping values − 3 // 4 // Matthew Sunderland 5 // Copyright 2009 6 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 7 // 8 // Revision History: 9 // R0 I n i t i a l − 10 // R1 Split hop enable to rx and tx separately − 11 //

12

13 module fhop bank 14 #(parameter AWIDTH=16, parameter DWIDTH=32) 15 // Wishbone Bus Signals 16 ( input wb clk , 17 input wb rst , 18 input [AWIDTH 1:0] wb adr i , − 19 input [DWIDTH 1:0] wb dat i , − 20 input wb stb i , 21 input wb we i , 22 output reg wb ack o ,

23

24 // Output registers (clocked to system clock) 25 input s y s c l k , 26 output wire [DWIDTH 1:0] freq , − 27 output wire tx hop en , 28 output wire rx hop en ,

29

30 // Master Clock Input 31 // input [31:0] master time , 32 input pps in ,

33

34 output debug 35 );

36

37 wire r s t ; 101

38 wire mem we ; 39 wire i n t e r v a l w e ; 40 wire length we ; 41 wire enable we ;

42

43 assign r s t = wb rst ; 44 assign mem we = wb we i & w b s t b i & ! wb adr i [ 1 0 ] ; //ADDR : 0x0000 to 0x03FC (256 words on 4 byte boundary) − 45 assign i n t e r v a l w e = wb we i & w b s t b i & wb adr i [ 1 0 ] & ! wb adr i [ 3 ] & ! wb adr i [ 2 ] ; //ADDR: 0x0400 46 assign length we = wb we i & w b s t b i & wb adr i [ 1 0 ] & ! wb adr i [ 3 ] & wb adr i [ 2 ] ; //ADDR: 0x0404 47 assign enable we = wb we i & w b s t b i & wb adr i [ 1 0 ] & wb adr i [ 3 ] & ! wb adr i [ 2 ] ; //ADDR: 0x0408

48

49 always @( posedge wb clk ) 50 i f ( wb rst ) 51 wb ack o <= 0 ; 52 else 53 wb ack o <= w b s t b i & ˜ wb ack o ;

54

55

56 wire [ 7 : 0 ] bank index ; 57 dual ram #( 8, 32 ) FREQ BANK 58 ( 59 . en ( ! r s t ) , 60 . we ( mem we ) , 61 . di ( wb dat i ) , 62 . c l k a ( wb clk ) , 63 . addra ( wb adr i [ 9 : 2 ] ) , 64 // . doa ( ) , 65 . clkb ( s y s c l k ) , 66 .addrb ( bank index ) , 67 . dob ( f r e q ) 68 );

69

70 wire [31:0] interval r e g ; 71 d u a l r e g #( 32 ) INTERVAL REG 72 ( 73 .we ( interval w e ) , 74 . di ( wb dat i ) , 75 . c l k a ( wb clk ) , 76 // . doa ( ) , 77 . clkb ( s y s c l k ) , 78 .dob ( interval r e g ) 102

79 );

80

81 wire [ 7 : 0 ] s e t l e n g t h r e g ; 82 d u a l r e g #( 8 ) SET LENGTH REG 83 ( 84 . we ( length we ) , 85 . di ( wb dat i [ 7 : 0 ] ) , 86 . c l k a ( wb clk ) , 87 // . doa ( ) , 88 . clkb ( s y s c l k ) , 89 . dob ( s e t l e n g t h r e g ) 90 );

91

92 wire [1:0] enabled r e g ; 93 wire enabled ; 94 assign tx hop en = e n a b l e d r e g [ 0 ] ; 95 assign rx hop en = e n a b l e d r e g [ 1 ] ; 96 assign enabled = tx hop en rx hop en ; | 97 d u a l r e g #( 2 ) ENABLED REG 98 ( 99 . we ( enable we ) , 100 . di ( wb dat i [ 1 : 0 ] ) , 101 . c l k a ( wb clk ) , 102 // . doa ( ) , 103 . clkb ( s y s c l k ) , 104 .dob ( enabled r e g ) 105 );

106

107 indexer #( 32 ) INDEXER 108 ( 109 . c l k ( s y s c l k ) , 110 .rst (˜enabled pps in ) , | 111 . s e t l e n g t h ( s e t l e n g t h r e g ) , 112 . h o p interval ( interval r e g ) , 113 .index (bank index ) 114 );

115

116 //DEBUG OUTPUT 117 assign debug = enabled & bank index [ 0 ] ; 118 endmodule 103 A.2.2 indexer.v

Listing A.5. indexer.v

1 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 2 // indexer.v Steps through the hop set sequence − 3 // 4 // The Pennsylvania State University 5 // Copyright (c) 2009 6 // 7 // AUTHOR: Matthew Sunderland 8 // 9 // REVISION HISTORY: 10 // 09/09/2009 I n i t i a l − 11 // 12 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 13

14 module indexer#( parameter DWIDTH=32, parameter LWIDTH=8 ) 15 ( 16 input clk , 17 input rst , 18 input [LWIDTH 1:0] s e t l e n g t h , − 19 input [DWIDTH 1:0] h o p i n t e r v a l , − 20 output [LWIDTH 1:0] index − 21 );

22

23 reg [DWIDTH 1:0] c n t r i n t e r v a l ; − 24 reg [LWIDTH 1:0] c n t r i n d e x ; − 25

26 wire max interval ; 27 wire max index ;

28

29 assign max interval = (cntr interval==hop i n t e r v a l ) ; 30 assign max index = (cntr i n d e x==s e t l e n g t h ) ;

31

32 always @( posedge c l k ) 33 begin 34 i f ( r s t ) begin 35 c n t r i n t e r v a l <= 0 ; 36 c n t r i n d e x <= 0 ; 37 end 38 else begin 39 i f ( max interval ) begin 40 c n t r i n t e r v a l <= 0 ; 104

41 c n t r i n d e x <= c n t r i n d e x + 1 ; 42 i f ( max index & max interval ) 43 c n t r i n d e x <= 0 ; 44 end 45 else 46 c n t r i n t e r v a l <= c n t r interval + 1;

47

48 end 49 end

50

51 assign index = c n t r i n d e x ;

52

53 endmodule 105 A.2.3 dual reg.v

Listing A.6. dual reg.v

1 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 2 // 3 // The Pennsylvania State University 4 // Copyright (c) 2009 5 // 6 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 7 // TITLE: Dual Port Register 8 // 9 // FILENAME: d u a l r e g . v 10 // 11 // Allows register to cross clock boundary 12 // 13 // AUTHOR: Matt Sunderland 14 // 15 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 16 // REVISION HISTORY (MANUAL) : 17 // 09/09/2009 I n i t i a l − 18 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 19

20 module d u a l r e g #( parameter WIDTH = 32 ) 21 ( 22 input clka , 23 input clkb , 24 input we , 25 input [WIDTH 1:0] di , − 26 output [WIDTH 1:0] doa , − 27 output [WIDTH 1:0] dob − 28 );

29

30 reg [WIDTH 1:0] data ; − 31 reg [WIDTH 1:0] dob r ; − 32

33 assign doa = data ; 34 assign dob = dob r ;

35

36 always @( posedge c l k a ) 37 begin 38 i f ( we ) 39 data = di ; 40 end 106

41

42 always @( posedge clkb ) 43 begin 44 i f ( ˜we ) 45 dob r = data ; 46 else 47 dob r = dob r ; 48 end

49

50 endmodule 107 A.2.4 dual ram.v

Listing A.7. dual ram.v

1 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 2 // 3 // National Astronomy and Ionosphere Center 4 // Arecibo Observatory/Cornell University 5 // Copyright (c) 2007 6 // 7 // The Pennsylvania State University 8 // Copyright (c) 2009 9 // 10 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 11 // TITLE: Dual Port Block Ram 12 // 13 // FILENAME: dual ram . v 14 // 15 // AUTHOR: Matt Sunderland 16 // 17 // Adapted from the XILINX XST User Guide. Implements a dual port b l o c k 18 // rom that is initialized from file. 19 // 20 // NOTE: Must keep the write ports to force XST to instanciate a Dual Port 21 // RAMinstead of twoROMS. 22 // 23 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 24 // REVISION HISTORY (MANUAL) : 25 // 06/13/2007 Initial (Matt Sunderland) − 26 // 06/19/2007 Added Generics to allow easy changes of bit l e n g t h (MDS)− − 27 // 11/02/2007 Converted to Verilog − 28 // 09/09/2009 Updated for SDR use − 29 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 30

31 module dual ram #( parameter AWIDTH = 8 , parameter DWIDTH = 32 ) 32 ( 33 input clka , 34 input clkb , 35 input en , 36 input we , 108

37 input [DWIDTH 1:0] di , − 38 input [AWIDTH 1:0] addra , − 39 input [AWIDTH 1:0] addrb , − 40 output [DWIDTH 1:0] doa , − 41 output [DWIDTH 1:0] dob − 42 );

43

44 reg [DWIDTH 1:0] memory [0:256 1 ] ; − − 45

46 reg [AWIDTH 1:0] read addra ; − 47 reg [AWIDTH 1:0] read addrb ; − 48

49 assign doa = memory[read addra ] ; 50 assign dob = memory[read addrb ] ;

51

52 always @( posedge c l k a ) 53 begin 54 i f ( en ) begin 55 i f ( we ) begin 56 memory[addra] = di; 57 end 58 read addra = addra; 59 end 60 end

61

62 always @( posedge clkb ) 63 begin 64 i f ( en ) begin 65 read addrb = addrb; 66 end 67 end

68

69 endmodule Appendix B

Development Environment Setup

This appendix records the steps necessary to properly set up a computer to be used to develop for the GNU Radio/USRP2 platform. The procedure is a record of how the development system was set up for this work and is not necessarily the only configuration that is suitable.

1. Install Ubuntu 8.10 for x86 platform

2. Remove network-manager and network-manager-gnome packages. These

packages interfere with Static IP addresses used by Penn State.

3. Set up Networking. Eth0 is LAN connection, Eth1 is USRP2 A, Eth2 is

USRP2 B.

4. Install GNU Radio Dependancies. These are documented at http://gnuradio.

org/redmine/wiki/gnuradio/UbuntuInstall.

5. At this point, I upgraded to Ubuntu 9.04 in an attempt to upgrade the sub-

version package version.

6. The distribution upgraded did not include the needed version so subversion 110

1.6.5 was installed from a 3rd-party repository. (I set up a subversion 1.6.x

server in the SSPL lab that required at least subversion 1.6.x as a client.)

7. Install Xilinx ISE 10.1i. The version is important; Slight variations between

Xilinx releases in general do not provide backwards compatibility with previ-

ous build scripts.

8. Install Microblaze Compiler Binaries. These can be obtained from Ettus

Research or built from source from the Microblaze GCC project. Here, the

binaries from Ettus were used and extracted to /opt/microblaze/, which

was also added to the PATH variable.

9. Checkout a copy of my GNU Radio development branch. (This is stored on

the SSPL SVN server.)

$ svn co https://spirit2.ee.psu.edu/svn/research/gnuradio-dev.

You will need a user account on the SSPL network with privileges to access

the Research Repository.

10. Build the GNU Radio Source

$ ./bootstrap

$ ./configure

$ make -j3

$ sudo make install

11. Install the SD-Card Utilities

$ sudo apt-get install sg3-utils

Be VERY CAREFUL when flashing new images to the SD-Cards. The tools

write at a low level with root privileges and if the incorrect device is speci- 111

fied, the operating system or user data can be immediately and irrecoverably erased. Bibliography

[1] Menendez, E. (2007) Implementing a Radio Bridge Using Software-Defined Radio Techniques, Bachelor’s thesis, The Pennsylvania State University. [2] Dwyer, J., K. Flynn, and F. Fessenden (2002) “Fatal Confusion: A Troubled Emergency Response,” The New York Times. [3] Joch, A. (2005) “Communications Breakdown,” Federal Computer Week, 19(41), pp. 28–31. [4] Brendler, J. A. (1992) “Tactical Military Communications,” IEEE Comu- nications Magazine, 30(1), pp. 62–72. [5] Lackey, R. I. and D. W. Upmal (1995) “Speakeasy: the Military Software Radio,” IEEE Comunications Magazine, 33(5), pp. 56–61. [6] Feickert, A. (2005) The Army’s Future Combat System (FCS): Background and Issues for Congress, CRS report for Congress. [7] ——— (2005) The Joint Tactical Radio System (JTRS) and the Army’s Fu- ture Combat System (FCS): Issues for Congress, CRS report for Congress. [8] Department of Homeland Security. (2006), “2006 National Interoperability Baseline Survey.” [9] National Institute of Justice. (2003) Guide to Radio Communications Inter- operability: Strategies and Products, Tech. Rep. TE-02-02. [10] “Tactical Communications Bridge 1,” URL http://www.link-comm.com/ [11] Mitola, J. (1995) “The Software Radio Architecture,” Communications Magazine, IEEE, 33(5), pp. 26–38. [12] Mitola, J. I. (1993) “Software radios: Survey, critical evaluation and future directions,” Aerospace and Electronic Systems Magazine, IEEE, 8(4), pp. 25– 36. [13] Tuttlebee, W. (ed.) (2002) Software Defined Radio: Enabling Technologies, John Wiley & Sons, New York, NY. 113

[14] Oconnor, N. F. (2004) Application of a Software-Defined Radio to Nano- Satellite Communications, Bachelor’s thesis, The Pennsylvania State Univer- sity. [15] Jimenez,´ R. (2006) Coherent Detection of AM and FM Signals Using Software-Defined Radio Techniques, Master’s thesis, The Pennsylvania State University. [16] Fakhari, Y. D. (2006) Line and Source Coder Implementations for Software- Defined Radios, Master’s thesis, The Pennsylvania State University. [17] Shah, A. B. (1997) Software-Based Implementation of a Frequency Hopping Two-Way Radio, Master’s thesis, Massachusetts Institute of Technology. [18] Clarke, B. (2003), “Sincgars Squad Radios,” URL http://www.prc68.com/I/sincgars.shtml [19] “NI PCI-5640R Software Defined Radio IF Transceiver,” URL http://zone.ni.com/devzone/cda/tut/p/id/6433 [20] “Small Form Factor SDR Evaluation Module,” URL http://www.lyrtech.com/index.php?act=view&pv=SFF%20SDR% 20evaluation%20module [21] Farrell, R., M. Sanchez, and G. Corley (2009) “Software Defined Radio Demonstrators: An Example and Future Trends,” International Journal of Digital Multimedia Broadcasting, 2009. [22] Blossom, E. (2004) “GNU Radio: Tools for Exploring the Radio Frequency Spectrum,” Linux Journal, 2004(122), p. 4. [23] Bose, V., M. Ismert, M. Welborn, and J. Guttag (1998) “Virtual Radios,” JSAC Special Issue on Software Radios. [24] Bose, V. (1999) Design and Implementation of Software Radios Using Gen- eral Purpose Processors, Ph.D. thesis, Massachusetts Institute of Technology. [25] “Ettus Research,” URL http://www.ettus.com/ [26] “The Python Programming Language,” URL http://www.python.org [27] “Simple Wrapper and Interface Generator,” URL http://www.swig.org [28] Love, R. (2005) Linux Kernel Development, Novell Press, Indianapolis, IN. [29] “Boost C++ Libraries,” URL http://www.boost.org/ [30] “LTC2284 Datasheet,” Linear Technology, Inc. [31] “AD9777 Datasheet,” Advanced Devices, Inc. 114

[32] “Spartan 3 Datasheet,” Xilinx, Inc. [33] “aeMB Overview,” URL http://opencores.com/project,aemb [34] “Wishbone Bus Specification,” URL http://www.wishbone.org/ [35] Tucker, D. C. (2009) “Prototyping with GNU Radio and the USRP - Where to Begin,” Southestcon ’09, pp. 50–54. [36] (2010), “Ubuntu Installation,” URL http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall [37] “Getting Started,” URL http://gnuradio.org/redmine/wiki/gnuradio/GettingStarted [38] “How to Write GNU Radio Python Applications,” URL http://gnuradio.org/redmine/wiki/gnuradio/ TutorialsWritePythonApplications [39] Normoyle, R. and P. Mesibov (2008) “The VITA Radio Transport as a Framework for Software Definable Radio Architectures,” in Proceedings of the SDR 08 Technical Conference and Product Exposition. Vita Matthew D. Sunderland

Address 166 Birch Drive Lewistown, PA 17044 e-mail: [email protected]

Education M.S. Electrical Engineering The Pennsylvania State University, 2010 Thesis: Software-Defined Radio Interoperability with Frequency Hopping Waveforms Advisor: Dr. Sven G. Bil´en

B.S. Electrical Engineering, with Honors in Electrical Engineering The Pennsylvania State University, 2008 Thesis: Software Defined Radar Receiver Implementation for Pulsed Radar Applications Advisor: Dr. Julio V. Urbina

Teaching Experience Teaching Assistant, EE 497E – Software Defined Radio, Fall 2009 Teaching Assistant, EE 210 – Circuits and Devices, Spring 2009 Teaching Assistant, EE 212 – Introduction to Electronic Measuring Systems, Fall 2008 & Spring 2010

Work Experience Avionics Intern, Space Exploration Technologies, Inc. Summer 2008, Summer 2009 REU Student, Arecibo Observatory, Summer 2007 Intern, General Electric–Inspection Technologies, Summer 2005