USRP Project Final Report

EECS 399 Project
Understanding a Basic OFDM Transceiver with
GNU Radio and USRPs
Arjan Gupta
(Under the guidance of Dr. Aveek Dutta)

Understanding a Basic OFDM Transceiver with GNU Radio and USRPs Page 1
Contents
Section 1 – Project Objective
Background and Introduction ………………………………………………………. Page 3
Learning Potential and Takeaways of this Project ……………….…………....…… Page 3
Why this Knowledge is Important ……….……….………………..…….….……… Page 3
Real System Implementation ……………………………………..……...……….… Page 4
Section 2 – Technical Concepts/Details Understood Through this Project
Basic Digital Signal Processing (DSP) ………………….………………………….. Page 4
Nyquist-Shannon Sampling Theorem
Analog-to-Digital Convertor
Signal Reconstruction
Other DSP operations
IEEE 802.11 PPDU Frame Formats …………………………………..…….……… Page 7
PLCP Preamble Construction Using MATLAB
Signal-to-Noise Ratio ……………………………………..………..…….……….... Page 9
Friis Transmission Equation
Path Loss (in Media and at High Frequencies)
Interference and Diffraction of EMW
Noise Temperature
Software Defined Radio ………………………………………….…...………...… Page 11
Section 3 – The Experimental Setup
Universal Software Defined Radio Peripheral (USRP) …………….…….…..…… Page 11
GNU Radio ……………………………………………………...……….………... Page 12
Bastian Bloessl’s OFDM Transceiver ………………………………….…………. Page 14
Overall Setup Block Diagram …….…..…..……………………..…….………….. Page 14
Pictures of the Actual Setup ………………………………………….…...………. Page 15
Section 4 – Performing the Experiment and Results
Performing the Experiment ………………………………………………..……… Page 17

Initial Simulation
Getting at the Actual Transceiver to Work
Transmitter and Receiver Signal Plots
Results Obtained ……………………………………………………………………. Page 22
Observed SNR Variation in the Line of Sight with Distance
Observed SNR Variation for Path Loss
More Analysis of Results ……………….……………………………….………..... Page 23
Section 5 – Possible Future Work
Programming the FPGA of the USRP………………………………..…………....... Page 24
EECS Senior Thesis
Section 6 – Code Appendix
Signal Reconstruction Code ……………………………………………………….. Page 24
PLCP Preamble Construction Code ………………………………………….……. Page 25
TX Captured Signal Plot Code …………………………………………………….. Page 26
RX Captured Signal Plot Code …………………………………………………….. Page 26
FER vs. Distance Plot Code ………………………………………………………... Page 27
Section 7 – Bibliography
Works Referenced …...……………………………...…………………………….... Page 28

Project Objective
Background and Introduction
Our interest in this area of research has its background in an introductory level course taught within the
Electrical Engineering and Computer Science (EECS) Department at the University of Kansas, called
Introduction to Communication Networks (EECS 563). This course covers a discussion of the uses of
communication networks, network protocols, standards, and traffic (all discussed in a layered reference
model). The key take-away from EECS 563 that inspired this independent study is how packet information
communication takes place in the wireless domain. We became interested with how transceivers work
with the 802.11 standard and decided to dive into a full-fledged study of a simple OFDM (Orthogonal
Frequency Division Multiplexing) transceiver using GNU Radio Software and Universal Software
Defined Radio Peripherals (USRPs).
Learning Potential and Takeaways of this Project
This field of study focused on a vast area of electrical engineering and computer science, which has an
infinite learning potential. Therefore, lot can be learned (and was so learned) from this project. The way
we have set up this project also affects what we take away from the project. We would do this project on
a Raspberry Pi computer with relatively simple computing, where a software such as GNU Radio would
not be able to run in its optimal potential. Such a project would give us a good learning experience not
just about OFDM transceiver in IEEE standard 802.11, but also an embedded systems approach toward
it.
However, we implemented our project on a standard computing running the Linux Ubuntu 14.04 operating
system, on top of which we ran the GNU Radio software, which lets us design and implement simple
receiver/transmitter blocks using a GUI or by manually writing code in Python. We also used a Universal
Hardware Device (UHD) called the Universal Software Defined Radio Peripheral (USRP), which has its
own source code written in C++, but GNU Radio can easily interact with a USRP because of the way this
software system is developed.
Hence, this project teaches us the following: a great deal about IEEE 802.11 OFDM standards for packet-
based data communication, a practical understanding of digital signal processing, an introduction to
software defined radio, a great deal of experience with using the Linux environment and shell scripting,
and application based experience with programming in Python, C++, and MATLAB.
Why this Knowledge is Important
The student researcher of this project, Arjan Gupta, is a junior pursuing a Computer Engineering major.
The takeaways of this independent study cover a good amount of both hardware and software, which not
only touches upon the essence of computer engineering in general with the field of, but are also in the
personal academic interest of the student researcher. This independent study will help the student
researcher achieve his endeavor of developing this study into thesis-oriented research project in his senior
year.
The learnings of this project are quite generally useful as well. A good understanding of an OFDM
transceiver will give the researcher learning outcomes that are applicable in industry-based jobs or

graduate school level research endeavors. This is because nowadays, basic academic coursework is not
enough to learn a concept. Practical experience is a necessity, which is exactly what this project gives us.
Also, transceivers and communication systems (software based or not) are present everywhere around us.
Many electronics applications today can inter-mingle with communication systems. Therefore, any
knowledge in this division of electrical engineering and computer science world is undoubtedly important
and useful.
Real-System Implementation
It is important to note throughout this project that we are creating quite a simple and uncomplicated model
of a transceiver, which does not have a direct application in the real world. We are going to perform
experiments, and simulations, which, although practical, are to just give us a simplified understanding of
how data transmission and reception works in actual application based scenarios.
Even in the simplified transceiver we are going to create in this project, we will first simulate the model
and then actually carry out data transmission and reception. However, we will find that simulations are
ideal and in reality the experiment will have a number of aberrations. Most of the aberrations occur on the
receiver side because of signal distortion due to noise and other factors. Before understanding these factors
we must understand some key concepts, which are outlined in the following section.
Technical Concepts/Details Understood Through this Project
Basic Digital Signal Processing (DSP)
Our background from Signal and System Analysis class (EECS 360) will come in use here.
Nyquist-Shannon Sampling Theorem
For any band-limited signal, the Nyquist-Shannon Sampling Theorem (a.k.a. Sampling Theorem) tells us
that the signal must be sampled at the rate (fS) of at least two times the value of the band frequency (fB).
In other words,
𝑓𝑆 ≥ 2𝑓𝐵
This is how we will avoid something called ‘aliasing’ in our transceiver model, which happens when the
ends of two samples of the signal overlap each other. When aliasing happens, the sections of the samples
that overlapped appear to be missing from the signal when the signal is completely reconstructed. The
least frequency at which we can sample the incoming analog signal is called the Nyquist frequency. It is
important for us to operate our receiver at the Nyquist rate because we do not want aliasing in our signal.
Analog-to-Digital Convertor
An analog-to-digital convertor (ADC) is a device that converts a continuous physical quantity to a
discrete physical quantity (or digital quantity). We consider an amplitude versus time waveform that is

input to an ADC in the figure below.
In Figure 1, the working of an ADC is shown. The first part (Stage 1) is where a Sampling and Holding
circuit (S/H) samples the signal at a value that is at least the Nyquist rate for the input signal. Once the
signal is sampled, it is passed into the Quantizer, which is Stage 2 of the ADC. Here, each sample of the
signal is given an encoded binary number label according to its amplitude. This encoded binary numbers
are chosen from a limited number of possible values. In Figure 1, the numbers corresponding to the signal
samples are numbers in modulo 10, but these can easily be assigned their corresponding binary number
equivalents.
Signal Reconstruction
Once our signal is received after being transmitted through the air or a transmission channel (e.g. co-axial
cable), we might want to use the chunks of signal (the samples) to reconstruct the original signal. Without
this we cannot properly gain the information being transmitted in the signal.
Figure 1: ADC diagram [1]
Figure 2: Reconstruction block diagram [2]

Consider the block diagram in Figure 2 above. In this diagram, a reconstruction of signal is taking place
from a given analog signal. For example, if the signal in A is a continuous cosine function, then the signal
is first sampled so that it can be transmitted easily. After that, the sampled signal can be digitally
transmitted. Then the signal is reconstructed and plotted. The output signal looks closer and closer to the
input signal with higher values of the sampling interval. In fact, using MATLAB code, we generated the
plots in Figure 3, so that we can actually confirm this.
In Figure 3, we have sampled a cosine function given as cos(20πt) (which has a Nyquist frequency of 20
Hz) at four different sampling interval (T), which are 0.001 seconds (for first sub-plot), 0.01 seconds (for
second sub-plot), 0.05 seconds (for third sub-plot), and 0.1 seconds (for fourth sub-plot). This means that
the sampling frequencies in the three cases (f = 1/T), are 1000 Hz, 100 Hz, 20 Hz, and 10 Hz. This is why
in the third sub-plot we can see just a straight line, because aliasing of the rectangular pulses occurred
while sampling. This is because 10 Hz is lower than the Nyquist rate. Otherwise, at and above the Nyquist
rate, the signal is reconstructed better and better. The code for this reconstruction is given in the Code
Appendix.
Other DSP operations
There are other Digital Signal Processing operations that for which brief understanding was developed.
A multiply-accumulate operation (performed by a multiply-accumulator a.k.a. MAC), is involved in
reconstruction of the signal. A moving average filter operation smoothens out the waveform to correct
Figure 3: Reconstructing a cosine signal with rectangular pulses.

aberrations. Also, automatic gain control (AGC) is a closed-loop feedback regulating circuit, which
regulates the amplitude of the signal at its output, regardless of the amplitude of the signal at its input.
AGC is useful in adjusting the power of the signal at the receiver.
IEEE 802.11 PPDU Frame Format
The Physical Layer Convergence Procedure (PLCP) provides a procedure to form PPDUs (PLCP Protocol
Data Units) from PSDUs (Physical Service Data Units). These are the standards that today’s WLAN
(Wireless Local Area Network) are based on.
We are particularly interested in the anatomy of the PLCP Frame, and more importantly in its preamble.
In Figure 4, we see how a PLCP Preamble is added to PLCP Header, PSDU, Tail, and Pad Bits to form a
PPDU. When the transmitter in our transceiver spits out a signal, we must know that it has a PLCP
preamble that we can easily recognize. For this, we use the Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications manual (Source 3) to actually construct a PLCP Preamble in
MATLAB.
PLCP Preamble Construction Using MATLAB
Following the specifications guide, we find that the PLCP Preamble itself has an important standard
structure.
Figure 4: PPDU Frame Format [3]
Figure 5: PLCP Preamble Structure (only the first 16 µs) [3]

In Figure 5 shown above, we see that the 16 µs PLCP Header is itself made up of two 8 µs sections. These
are the short and long parts of the preamble. The short part of the preamble is made up of ten short training
symbols (t1, t2, t3 … and so on up till t10). Each short training symbol is made up of 12 subcarriers, which
are given as the set S-26, 26 below:
Where the √13 6⁄ factor normalizes the power of the OFDM symbol. Then, an inverse Fast Fourier
Transform (IFFT) must be performed on the set, the set must be extended one and a half times, and the
set must go through a window function. The output of these steps construct the short part of the PLCP
preamble, as we need.
Now, the long part of the preamble has three parts, two of which are the long training symbols which are
quite long, so is not shown here, but can be found in the Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications manual. After constructing a set, first we cut the long training
symbol in half, and put the second half behind the first. After that, similar to how we constructed the short
part of the preamble, we perform an IFFT, the set is extended and inputted to a window function. Once
we have the short and long parts of the PLCP preamble, we simple concatenate them to produce a full
PLCP preamble and then we plot its magnitude (the preamble will have complex values) it to get the
following figure:
Figure 6: Constructed PLCP Preamble

In Figure 5, we can we that there are two parts of the preamble, the first part being the short part of the
preamble and the second part being the long part of the preamble. Just as we would expect, both the
short and long parts of the preamble have a repetitive pattern, which is what helps us identify the
beginning of a PPDU packet.
The actual MATLAB code we wrote to construct this preamble is given in the Code Appendix of this
report.
Signal-to-Noise Ratio (SNR)
Up till now we have illustrated concepts that were necessary in order to understand the basic working of
our transceiver. Now we come to a concept that will help us understand the aberrations that may be caused
in our data transmission, hence giving us non-ideal data at the receiver.
Signal-to-Noise Ratio (SNR), as the name suggests, is the ratio of the signal to the noise. It is given as:
𝑆𝑁𝑅 =
𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝑝𝑜𝑤𝑒𝑟 𝑜𝑓 𝑠𝑖𝑔𝑛𝑎𝑙
𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝑝𝑜𝑤𝑒𝑟 𝑜𝑓 𝑛𝑜𝑖𝑠𝑒
We desire lower noise, so in a general way, the higher the SNR it is, the more ideal it is for us.
There are many things that affect SNR, let us take a look at them.
Friis Transmission Equation
The Friis transmission equation establishes a relationship between the power of the signal at the receiving
antenna and the power of the signal at the transmitting antenna. The basic form of the equation is given
as:
Where, Pr and Pt are the power of the signal at the receiving and transmitting antennae respectively, the
Gt and Gt are the gain of the transmitter and receiver respectively, λ denotes the wavelength of the
electromagnetic wave signal transmitted, and R is the line of sight distance between the two antennae.
It is apparent by just looking at the equation that,
𝑃𝑟 ∝
1
𝑅2
So, the power of the signal is related to the distance between the antennae by the inverse square law. So
as the distance increasing, the power at the receiver exponentially decreases, which in turn exponentially
decreases the SNR at the receiver, because,
𝑃𝑟 ∝ 𝑆𝑁𝑅

So, more distance between the antennae decreases the average power at the receiver, which in turn
decreases the SNR. So this means increasing the distance between the antennae decreases the signal-to-
noise ratio at the receiver.
Path-Loss (in Media and at High Frequency)
In general, when an electromagnetic wave (EMW) propagates through a medium, its power is attenuated.
If the medium is transparent, most of the power attenuated happens because of propagation. However, if
the medium is non-transparent, most of the attenuation occurs through absorption. So, if an analog signal
(which is an EMW) hits a non-transparent object, e.g. a wall, a lot of the power of the signal is lost due to
absorption.
Since we already established that,
𝑃𝑟 ∝ 𝑆𝑁𝑅
We know that when the signal hits a non-transparent object, the SNR at the receiver signal decreases.
Also, generally, at high frequency signals, the path loss is higher, hence higher frequency signals give
lower SNR as well.
Interference and Diffraction of the EMW
Depending on reflecting surfaces around the transmitting antenna, the signal transmitted can interfere with
itself. This depends on the orientation of both the receiver and transmitter antenna. At a certain orientations
of the transmitter antenna with respect to the receiver antenna in unchanged surroundings, the receiver
signal could be placed in a spot where destructive interference is taking place. If this is the case, the power
at the receiver would be quite low and therefore SNR would also be low.
Similarly, depending on the wavelength of the EMW, when the signal passes through a significantly small
spacing, the EMW could spread in all directions (diffract), and cause an interference pattern as well. This
could also decrease the SNR.
Noise Temperature
Another interesting factor that could decrease SNR is noise temperature. This kind of noise is related to
what we commonly commonly called thermal noise. It is the all the noise from the charge carrier agitations
inside electrical components inside a circuit. There is a relation given as,
Where T is the noise temperature in Kelvin, P/B is the power spectral density of the noise, and kB is the
Boltzmann constant. This noise temperature is Additive White Gaussian Noise (AGWN), and effects
every information system.
The higher the noise temperature is, the lower the SNR will be. So this intrinsic noise of our hardware
will also cause the SNR to decrease.

Software Defined Radio
Software Defined Radio (SDR) is something the researcher also worked with for the first time through
this research project. SDR is a system where communication components that are typically implemented
in hardware are implemented in software on a computer or an embedded system.
Software Defined Radio (SDR) is something the student researcher also worked with for the first time
through this research project. SDR is a system where communication components that are typically
implemented in hardware are implemented in software on a computer or an embedded system. Even
though SDR is relatively new in the engineering community, these days capability of digital electronics
make many communication processes faster and efficient. However, it is important to note that some
processes will always be done faster by hardware. Either ways, the option to implement systems on
software and hardware these days lets us divide the labor efficiently to create good communication system
models.
There are many open-source code bases for SDR these days, one of the most notable being GNU Radio,
which we will use in our project to create our transceiver. We will describe this further in the next section.
The Experimental Setup
Universal Software Define Radio Peripheral (USRP)
A USRP is a specialized hardware device developed by the Ettus Research group to run Software Define
Radio systems. In our project, we will be using the USRP N210. This USRP, like others, connects to a
computer through a Gigabit Ethernet cable, and is compatible with software like GNU Radio, LabVIEW
and Simulink. It has antenna ports to connect a VERT900 antenna, but we can also connect co-axial cables
for a reduced noise channel. The following figures will help us understand USRPs better.
Figure 7: USRP N210 Block Diagram [4]

In Figure 7, we see the block diagram for our USRP N210. This shows us how the FPGA acts as the
central processor, to which are connected a daughter card (we use an SBX daughter card, and the daughter
card is connected through an ADC and DAC), Ethernet PHY interface, MIMO expansion, and a Reference
Clock. The fact that there is an FPGA here is what makes this board so desirable and flexible to use.
In Figure 8, a USRP N210 is seen (exactly like ours) with the top cover off, showing a SBX daughter card
inside. The cables connecting the two antenna ports can also be seen. Both of these antenna ports can also
connect to co-axial cables.
GNU Radio
Now we come to one of the most notable open source toolkit for developing Software Define Radio, GNU
Radio. GNU Radio calls itself “The Free and Open Software Radio Ecosystem”. It is an easy to use
development kit written mostly in Python and some C++. One of the most efficient tools of GNU Radio
is its GNU Radio Companion, which lets a user create and simulate flow graphs that models an actual
radio system completely in software. The flow graphs contain GUI (Graphical User Interface) radio
blocks, which are written in Python code, and can easily be tweaked. If a successful flow graph is
generated, a Python script is generated for the flow-graph which executable. So in other words, GNU
Radio Companion allows GUI to generate Python scripts. If a Python code is generated for a flow-graph
and the simulation is successful, it is quite easy to extend the software on to a compatible hardware device
Figure 8: USRP N210 with top off and SBX daughterboard showing. [5]

like the Ettus Research USRP N210. In fact, this is what we will do to create our transceiver, except we
will use flow graphs created and customized by a (quite renowned in the GNU Radio community)
researcher, Bastian Bloessl, from University of Innsbruck, Austria (See Source 6).
The latest version of GNU Radio can be installed from source (installing by source allows us to access the
source code of the GNU Radio and play around with) by going to the link and following the instructions
under “Using the build-gnuradio script”:
http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource
This will not only install the latest version of GNU Radio for us, but will also install the USRP UHD
(Universal Hardware Device) installation from source. However, before starting the build-gnuradio script,
it is very important to make sure we have all the Linux packages installed (using the sudo apt-get
command) as required by GNU Radio and the UHD, since we are using Ubuntu 14.04. Installing GNU
Radio and the UHD can take up to several hours and a small mistake may leave us with a faulty installation,
so it is very important to carefully follow every step of the process.
Figure 9: A Wi-Fi Loopback Flow Graph from Bastian’s Code Library. [6]

In Figure 9, we see an example of a GNU Radio flow graph. This also just happens to be the Wi-Fi
Loopback model for our transceiver, since we are using the open-source code from Bastian Bloessl’s
GitHub library. In other words, this flow graph is the simulation of our transceiver.
Bastian Bloessl’s OFDM Transceiver
Bastian’s paper, “An IEEE 802.11a/g/p OFDM Receiver for GNU Radio [6]”, gives us the details for the
transceiver we will use in this project. On Bastian’s GitHub page (github.com/bastibl), under his
repository “gr-ieee802-11”, we follow the steps to install the packages and downloads in order to set up
his code on our two Ubuntu machines. One of our machines will monitor the receiver USRP and the other
will monitor the transmitter USRP.
After the code is downloaded and installed, we must make sure that our USRPs are properly connected
and live. To test this, we must physically connected Ethernet cables from our computers to the USRPs.
The Ethernet Interface port at each of the computers must be configured to read the USRP we wish to
connect. In our actual set up, one of the USRPs had the IP address 192.168.10.2 and to communicate with
it, we had to set the computer’s Ethernet Interface port’s IP address to 192.168.10.1. Once this was done,
we could use the command uhd_find_devices in the Ubuntu terminal to detect the USRP. If it is properly
connected, the USRP’s address should show up in the terminal. Otherwise, the terminal will tell us that
no devices were found. Similarly, another one of our USRP devices was addressed 192.168.40.2 and to
detect it, the computer’s Ethernet Interface port must be addressed as 192.168.40.1.
If we only have one single Ethernet Interface port to connect the USRP and the Internet, we must switch
between the two and run the following commands. If we wish to configure the IP address of our Linux
computer’s Ethernet interface to detect the USRP, we can execute a shell script with the following code:
#!/bin/bash
sudo stop network-manager
sudo ifconfig eth0 192.168.40.1 netmask 255.255.255.0
If we wish to reset the Ethernet Interface so as to access the Internet, we can execute this shell script:
#!/bin/bash
sudo ifconfig eth0 0.0.0.0
sudo start network-manager
Once we are sure that the USRPs are properly connected, we must calibrate our daughterboards using the
command uhd_cal_rx_iq_balance for the receiver USRP and the commands uhd_cal_tx_dc_offset
and uhd_cal_tx_iq_balance for the transmitter USRP.
We must also adjust the maximum shared memory so Bastian’s code executes without memory
consumption problem. Further, Bastian’s custom Wi-Fi flow graphs must be generated to produce some
source code which will be used in our transceiver. Also, the volk_profile command must be run to
ensure proper functioning of the transceiver. Now we are ready to start testing and using the transceiver.
Overall Setup Block Diagram
Let us represent our entire experimental setup in the form of a block diagram before we begin testing.

Figure 10 here shows a graphical representation of how our whole transceiver is set up to run. We have
two machines which connect to a USRP each, one playing the role of transmitting and the other playing
the role of receiving. Hence, a transceiver is formed.
Pictures of the Actual Setup
Below are photos of how our setup really looked.
Figure 10: TX-RX Setup Block Diagram
Figure 11: TX-RX Actual Setup with Co-Axial Cable

In Figure 11, we can see that both the receiver and transmitter USRPs are connected with a co-ax cable.
This setup reduces the noise in the transmission channel.
In Figure 12 here, we can see that there are antennae connected to the antenna ports, which is a situation
where we can perform our experiment with some meaning.
Performing the Experiment and Results
Initial Simulation
Once everything was set up as shown in the pictures above, we proceeded to run the first test, which is the
simulation of our transceiver through a Wi-Fi Loopback flow graph. This only requires one computer
(since it is only a model). We used the terminal to run Bastian’s GNU Radio Companion flow-graph called
“wifi_loopback.grc”. Then we execute the “wifi_loopback.py” which was generated by the flow-graph.
The loopback simulation shows us what our transceiver should behave like during ideal conditions. We
can play around with the SNR, transmitter gain, and receiver gain.
In this ideal simulation, we also find something quite interesting. If we set high values of SNR, we observe
that the Frame Error Rate (FER) stays near 0.0%. But as we begin lowering it, particularly starting around
SNR value of 10, we find that the FER steadily increases.
Figure 12: TX-RX Actual Setup without Co-Axial Cable

Hence, in these ideal simulation conditions, we find a fair relationship between SNR and FER, i.e.
1
𝑆𝑁𝑅
∝ 𝐹𝑟𝑎𝑚𝑒 𝐸𝑟𝑟𝑜𝑟 𝑅𝑎𝑡𝑒 (𝐹𝐸𝑅)
This empirical relationship makes sense because the higher the SNR is, the lower the over-all distortion
of the signal is, hence the Frame Error Rate for the signal is also low. However, when the SNR is low, it
means there is more noise power relative to the signal power, so the signal is distorted more. This would
mean that the FER is lower. Using this expected relationship, we will track the working of our actual
transceiver.
Figure 13: This GUI shows that for high SNR, FER is 0.00%.

Getting the Actual Transceiver to Work
On the left-hand side Linux machine, we executed the receiver, called “wifi_rx.py”, which was generated
using the flow graphs of “wifi_rx.grc”. This brought up a GUI display with a blank scope plot, which was
not detecting any signals because none were being transmitted in the channel it was listening for. On the
right-hand side Linux machine, we executed the transmitter, call “wifi_tx.py”, and similarly generated by
“wifi_tx.grc”. As soon as we executed the python program, we saw dynamic data show up on the scope
plot of the wifi_rx.py program. This was one sign that the transceiver was working. We also trying to hold
and move around the receiver antenna. This caused a spike in the Frame Error Rate (FER) on the receiver
GUI and the dynamic data also fluctuated immediately. This was a second sign that our transceiver is
functional.
After these simple measures, we were sure that our receiver was working. However, these quick-fix aren’t
enough to confirm that the whole transceiver is functional.
Transmitter and Receiver Signal Plots
We decided to test the functionality of our receiver by plotting the signal that is spit out of the transmitter
and the signal spit out by the receiver. It is important to note that we do not expect both these signals to
be the same, because this is not a simulation. We will analyze the differences in the plots. To plot these,
we need to use MATLAB code which we have included in the Code Appendix.
Let us zoom in on the plot in Figure 14 to analyze the packets slightly better.
Figure 14: First ~1 second of transmitted signal.

Once we zoom in on the plots in Figure 14, we get the plots in Figure 15. For the real values, we can see
a clear repetition pattern at the beginning of the PPDU, denoting the short part of a preamble. If we look
carefully at the following part of the PPDU, we can find a repeating pattern for a long port of the PLCP
preamble. Hence, we have confirmed that the signal coming out of the transmitter is in fact a PLCP
Protocol data unit. This was in fact expected, because given that Bastian Bloessl wrote the flow-graphs in
GNU Radio appropriately, the transmitter should spit out a clear OFDM signal without any signs of
distortion. There is no noticeable distortion from thermal noise, most probably because the signal has
constructed using SDR for the most part. Let us now take a look at the plot of the signal at the receiver.
In Figure 16 on the next page, we see the sheer difference from the plots in Figure 14. The real values do
not look so rich and well distributed, whereas the imaginary values look far too thick. Let us zoon into the
plot to get a better picture.
In Figure 17 we get a better picture of Figure 16 by zooming into those plots. It is hard to find any
resemblance to the plots in Figure 15. This is expected to some extent, but let us try to analyze why the
received signal looks so distorted. For this, let us consider the fact that this received signal, which itself
was captured over a time of roughly 1 second, was captured in the first few seconds of the receiver picking
up the transmitted signal. In these first few seconds, the automated gain control operation is still adjusting
to the power with which the signal hits the receiving antenna. As a result, the FER in the first few seconds
Figure 15: Zoomed first ~1 second of transmitted signal.

Figure 16: First ~1 second of received signal
Figure 17: Zoomed first ~1 second of received signal

of the receiver picking up the transmitted signal is very high (starting at about 90%, and then settling down
over the 5-6 seconds to a low FER). A high FER means that the signal is highly distorted. So in the first
few seconds of the receiver picking up a signal, the distortion is very high. Coincidentally, and quite
unfortunately, it is only within these few starting seconds we captured the signal. The high FER in the
first few seconds is shown in the screenshot in the figure below.
As we can see in Figure 18, the FER is nearly 79%, which is very high. It is no doubt we capture a much
distorted signal during this time. Hence, this begs the question – why not try to capture the received signal
Figure 18: The RX signal in the first few seconds shows a very high FER.

in a time when the Automated Gain Control has adjusted and the FER has settled down? This is possible,
but it would require us to manually tweak the python code of the wifi_rx.py script. Unfortunately we did
not have enough time to try to do this. By default, the GNU Radio Companion GUI simply creates a File
Sink for us, which begins capturing a signal the moment we run the flow graph, and writes it to binary
.dat file, which we can use to plot once we stop executing the flow-graph. The GUI does not give us the
option of capturing a signal after some time has passed. Also, since we only want to handle a small amount
of data (MATLAB takes far too long to process the signal data from longer than one second), we only
capture roughly 1 second of the signal at the beginning of when the flow graph is executed. If we had
more time to work on this project, we would find a way to write and change some of the Python code in
order to begin capturing the signal after a set number of seconds, and only for a single second.
Results Obtained
Now, we try to confirm some SNR relationships through the behavior of the FER as we change distance
between antennae, placing objects in between, and other physical quantities.
Observed SNR Variation in the Line of Sight with Distance
We moved our receiver and transmitter USRP apart by different distances to see how the FER changes.
We made sure that there was a clear direct path between the antennae (line of sight), i.e. there were no
objects blocking the direct path between the receiving and transmitting antennae. The data recorded is
shown in the table below.
Distance
between
antennae (m)
Frame Error
Rate (%)
0.5 1.00
2.5 5.16
5 19.40
7 30.53
Using MATLAB code, we performed a
quadratic fit on this observed data in the
table. The plot is shown to the right.
This code is documented in the Code
Appendix.
Figure 19: A plot that shows a quadratic curve fit
on FER vs. distance points.

In Figure 19, the quadratic regression between the Frame Error Rate (FER) and the distance between the
antennae (R), empirically implies the following proportionality:
𝐹𝐸𝑅 ∝ 𝑅2
But in the simulation of our transceiver we also observed that,
1
𝑆𝑁𝑅
∝ 𝐹𝐸𝑅
So, we can conclude that,
𝑆𝑁𝑅 ∝
1
𝑅2
Which is one of the important takeaways of the Friis Transmission Equation we outlined in an earlier
section of this report. So we see that our transceiver is definitely obeying the Friis transmission equation
and is therefore functioning correctly.
Observed SNR Variation for Path Loss
Our transceiver obeying the Friis transmission equation is a quite a good measure of its functionality, but
let us see how the Frame Error Rate behaves when the line of sight between the Tx and Rx antennae is
blocked by objects, or how the FER behaves in different media. We will try to keep the distance constant
but introduce objects in the line of sight or record the FER in different media.
1) When we measured the FER with a co-axial cable (longer than the one in the picture we have
earlier in the report) connecting the two USRPs, its value was 0.82% (length of the cable was fixed
at about 1 meter)
2) In air, when the antennae are in clear line of sight and 1 m apart, the FER is 1.62%
3) When we put the receiver USRP under the workbench, so the two antennae are blocked by a thick
wooden table, the FER rises to 46.50%. The distance between the USRPs was about 1 meter.
Hence it is quite apparent that within different media and with objects blocking the line of sight, the FER
rises, which means the signal has more noise in it, most probably because of loss of signal power in path
loss. So path loss can decrease the SNR, which is something we outlined earlier.
More Analysis of Results
Now we have come to a point where we know that our transceiver definitely works. However, let’s analyze
our results a little more. We have already analyzed our results for the inverse square law with distance and
the path loss effects. However, in an earlier section of this report, we discussed that SNR can also be
affected by interference, diffraction and noise temperature. Unfortunately do not have an easy way of
measuring the interference or diffraction of the signals from the transmitter USRP. However, during our
experiments, whenever we moved the USRPs, we made sure that their orientation remained the same
when we recorded the data (we maintained an antenna side facing antenna side orientation for the USRPs).
This should be able to give us similar diffraction/interference affects no matter what the distance is. Also,
we can assume that the additive noise temperature throughout our experiments remains the same, because

we are not introducing any new hardware during our experiments which could contribute to increasing
the given thermal noise that already exists for all our hardware. Also, the 0.82% FER that exists even
when the USRPs are connected via co-axial cable can probably be explained by thermal noise.
Possible Future Work
EECS Senior Thesis
Since the student researcher is interested in working in this field further, looking ahead is quite fair. There
is a vast field of opportunity for what can be done in this field. After a discussion with Dr. Dutta about
what lies ahead, we learned that we can use Hardware Description Languages (e.g. VHDL and Verilog)
to program the FPGA in the USRP so that it can spit out data at a far faster rate. CPUs are by default quite
slower than programmed FPGAs, so a USRP can be turned into a powerful device for transmitting and
receiving data. This is because FPGAs perform tasks in parallel processes, whereas CPU perform tasks
sequentially. This research can be used to work toward an EECS Senior Thesis at KU, by applying for
Department Honors in Summer 2016.
Code Appendix
All the code in this section is written in MATLAB.
Signal Reconstruction Code
clear all; clc;
% Author: Arjan Gupta
% Purpose: Reconstructing a cosine signal with rectangular pulses
Ts = [0.001, 0.01, 0.05, 0.1];
ta = 0:0.001:1;
M = length(ta);
for i = 1:length(Ts)
% cosine signal
n = 0:Ts(i):1;
N = length(n);
x = cos(20*pi*n);
% RECONSTRUCT RECTANGULAR PULSES
yrect(i,:) = x*rectpuls(ones(N,1)*ta-[0:N-1]'*Ts(i)*ones(1,M),Ts(i));
% Plot the reconstructed pulses
figure(1)
subplot(4,1,i)
plot(ta,yrect(i,:))
title(sprintf('Rectangular reconstruction for T = %d', Ts(i)));
end

PLCP Preamble Construction Code
close all; clc;
% Description: PLCP Preamble Construction
% expected short preamble
spreamb = [zeros(1,8), (1+1i), zeros(1,3), (-1-1i), zeros(1,3)];
spreamb = [spreamb, (1+1i), zeros(1,3), (-1-1i), zeros(1,3), (-1-1i), zeros(1,3),
(1+1i), zeros(1,3)];
spreamb = [spreamb, zeros(1,4), (-1-1i), zeros(1,3), (-1-1i), zeros(1,3), (1+1i),
zeros(1,3)];
spreamb = [spreamb, (1+1i), zeros(1,3), (1+1i), zeros(1,3), (1+1i), zeros(1,7)];
spreamb = ((13/6)^(1/2)).*spreamb;
% inverse fast fourier transform of spreamb
ifft_spreamb = ifft(spreamb);
% extend ifft_spreamb
ifft_spreamb = [ifft_spreamb, ifft_spreamb, ifft_spreamb(1:33)];
% multiply ifft_spreamb by window function
ifft_spreamb(1) = 0.5*ifft_spreamb(1);
ifft_spreamb(161) = 0.5*ifft_spreamb(161);
% all even values of ifft_spreamb seem to be negative, so let us rectify that
for k = 1:length(ifft_spreamb)
if (mod(k,2) == 0)
ifft_spreamb(k) = ifft_spreamb(k)*-1;
end
end
% expected long preamble
lpreamb = [zeros(1,6), ones(1,2), -1.*ones(1,2), ones(1,2), -1, 1, -1, 1];
lpreamb = [lpreamb, ones(1,5), -1.*ones(1,2), ones(1,2), -1, 1, -1, ones(1,4)];
lpreamb = [lpreamb, 0, 1, -1.*ones(1,2), ones(1,2), -1, 1, -1, 1, -1.*ones(1,5),
1];
lpreamb = [lpreamb, 1, -1.*ones(1,2), 1, -1, 1, -1, ones(1,4), zeros(1,5)];
% inverse fast fourier transform of lpreamb
ifft_lpreamb = ifft(lpreamb);
% put the second half of the lpreamb in front
ifft_lpreamb = [ifft_lpreamb(33:end), ifft_lpreamb(1:32)];
% extend ifft_spreamb
ifft_lpreamb = [ifft_lpreamb, ifft_lpreamb, ifft_lpreamb(1:33)];
% multiply ifft_lpreamb by window function
ifft_lpreamb(1) = 0.5*ifft_lpreamb(1);
ifft_lpreamb(161) = 0.5*ifft_lpreamb(161);
% all even values of ifft_lpreamb seem to be negative, so let us rectify that

for k = 1:length(ifft_lpreamb)
if (mod(k,2) == 0)
ifft_lpreamb(k) = -1*ifft_lpreamb(k);
end
end
preamble = [ifft_spreamb(1:160), (ifft_spreamb(161)+ifft_lpreamb(1)),
ifft_lpreamb(2:160)];
% Ideal PLCP preamble in IEEE 802.11 WLAN!
figure
abs_preamb = abs(preamble);
plot(1:320,abs_preamb);
legend('Expected PLCP preamble');
TX Captured Signal Plot Code
close all; clc;
% Description: USRP tx packet samples analysis
% This code reads and plots the USRP samples
fh = fopen('data.dat', 'rb');
data = fread(fh,'int16');
cdata = complex(data(1:2:end),data(2:2:end));
fclose(fh);
re = real(cdata);
img = imag(cdata);
figure
subplot(2,1,1)
plot(re)
title('Real values of transmitted signal');
subplot(2,1,2)
plot(img)
title('Imaginary values of transmitted signal');
RX Captured Signal Plot Code
close all; clc;
% Description: USRP rx packet samples analysis
% This code reads and plots the USRP samples
fh = fopen('data_rx.dat', 'rb');
data = fread(fh,'int16');
cdata = complex(data(1:2:end),data(2:2:end));
fclose(fh);
re = real(cdata);
img = imag(cdata);
figure

subplot(2,1,1)
plot(re)
title('Real values of received signal');
subplot(2,1,2)
plot(img)
title('Imaginary values of received signal');
FER vs. Distance Plot Code
close all; clc;
% Purpose: Plot the FER vs. distance
distances = [0.5, 2.5, 5, 7];
FERs = [1, 5.16, 19.40, 30.53];
p = polyfit(distances,FERs,2);
x1 = linspace(1,10,19);
y1 = polyval(p,x1);
figure
stem(distances,FERs,'o');
hold on
plot(x1, y1)
hold off
xlabel('Distance (m)');
ylabel('FERs (%)');
legend('Observed data','Quadratic fit for FER vs. distance');

Bibliography
Works Referenced
[1] Malik, Bilal. "Analog to Digital Converter and How ADC Works." (n.d.): n. pag. Micro Controllers
Lab. 31 July 2013. Web. 16 May 2016. <http://microcontrollerslab.com/analog-to-digital-adc-
converter-working/>.
[2] Adat, Rachad. "EECS 360 Signal and System Analysis Lab 10: Sampling and Signal Reconstruction."
Web. 17 May 2016. <http://people.eecs.ku.edu/~esp/class/S16_360/lab/Lab10ATAT.pdf>
[3] Information technology--Telecommunications and information exchange between systems Local and
metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications," in ISO/IEC/IEEE 8802-11:2012(E)
(Revison of ISO/IEC/IEEE 8802-11-2005 and Amendments), vol., no., pp.1-2798, Nov. 21 2012.
22 March 2016. doi: 10.1109/IEEESTD.2012.6361248
<http://standards.ieee.org/getieee802/download/802.11-2012.pdf>
[4] "USRP™ N200/N210 Networked Series." (n.d.): n. pag. Ettus Research. Web. 15 May 2016.
<www.ettus.com>.
[5] Šolc, Tomaž. USRP N210 with SBX and top cover off. Digital image. Tablix. N.p., 07 June 2012.
Web. 14 May 2016. <https://www.tablix.org/~avian/blog/articles/about/>.
[6] Bloessl, Bastian, Michele Segata, Christoph Sommer, and Falko Dressler. "An IEEE 802.11a/g/p
OFDM Receiver for GNU Radio." (n.d.): n. pag. Institute of Computer Science, University of
Innsbruck, Austria, Dept. of Information Engineering and Computer Science, University of Trento,
Italy, Mar. 2013. Web. 20 Mar. 2016. <http://www.ccs-labs.org/bib/bloessl2013ofdm-tr/>.

USRP Project Final Report

More Related Content

What's hot

Viewers also liked

Similar to USRP Project Final Report

USRP Project Final Report