TTT4145 Radio Communication

Digital Voice Communication

with USRP2 & GNU Radio



Report handed in 2/11/2011





Jon Petter Skagmo, MTEL
Per yvind Eid Fjuk, MTEL
Kristian Rygh Jerndahl, MTEL



Contents
Abstract ........................................................................................................................................... 1
Introduction .................................................................................................................................... 1
System overview ............................................................................................................................. 1
Software Defined Radio .............................................................................................................. 1
Universal Soft Radio Peripheral 2 (USRP2) ................................................................................. 1
GNU Radio Companion (GRC) ..................................................................................................... 2
Theory ............................................................................................................................................. 3
Source ..................................................................................................................................... 3
Channel Model ........................................................................................................................ 3
Source Coding/Decoding ........................................................................................................ 5
Channel Coding/Decoding ...................................................................................................... 5
Pulse Shaping .......................................................................................................................... 6
Modulation/Demodulation ..................................................................................................... 7
Link Budget Calculations ......................................................................................................... 8
Practical system ............................................................................................................................ 11
Building blocks .......................................................................................................................... 12
Audio source ......................................................................................................................... 13
AGC2...................................................................................................................................... 13
Multiply const ....................................................................................................................... 13
Float to char .......................................................................................................................... 13
Packet encoder (and decoder) .............................................................................................. 13
GMSK modulator (and demodulator) ................................................................................... 14
Throttle ................................................................................................................................. 14
USRP2 sink (and source) ....................................................................................................... 14
Sample rate calculations ........................................................................................................... 14
Results ........................................................................................................................................... 15
Discussion...................................................................................................................................... 16
Conclusion ..................................................................................................................................... 17
Abbreviations ................................................................................................................................ 18
Appendix ....................................................................................................................................... 18



1
Abstract
A digital communication system was implemented with a USRP2 software defined radio and a
computer running GNU radio companion. We achieved good quality audio and a range of
approximately ten meters.
Introduction
The goal of the project was to implement a digital communication system using USRP2, which
will be introduced later, and a general purpose computer. We were given a free range of
options on how to solve the problem, and little to no actual demands in terms of specifications.
Despite the lack of requirements, the task of becoming familiar with GRC proved to be quite
challenging, and we spent a lot of time experimenting with the software. As will be shown later,
we experienced some differences between calculated values and actual measurements, but our
knowledge about physical phenomena like free space loss, small- and large scale fading seemed
to correspond very well with practice.
System overview
Software Defined Radio
The concept of Software Defined Radio is to implement as much as possible of a
communication system in code on programmable hardware. This includes computers,
microcontrollers, FPGA etc. This adds a lot of flexibility, as a radio system can be completely
changed without as much as touching the physical hardware. It is needless to say what kind of
advantage this is e.g. in a satellite radio system. Other advantages include the simplicity of
quickly testing new technology, as well as testing individual hardware components by
simulating the surrounding components in software.
Universal Soft Radio Peripheral 2 (USRP2)
This is an open source platform that, combined with a general purpose computer, will act as a
complete radio communication system [1]. The USRP2 itself is a motherboard with a gigabit
ethernet interface and an onboard FPGA, which can do signal processing before the data is
passed to the computer. The RF front-end is exchangeable, and various daughter boards can be
bought and easily connected to the motherboard inside the USRP2.


2

For this task, we will use the RFX2400 daughter board, which is a 2.3 to 2.9 GHz transceiver with
50 mW output power. The daughter boards are mainly just a filtered front end and an
adjustable mixer.


Fig. 1: USRP2 with daughterboard [2]
GNU Radio Companion (GRC)
GNU Radio Companion is a python/C++ based open source tool for creating a software radio
system. GRC allows a designer to connect components and create a signal flow diagram using a
graphical drag-and-drop interface. Component blocks are generally implemented in C++ and
connected using the Python programming language.

The system comes with a large amount of commonly used radio components, such as
modulators/demodulators, filters and amplifiers. It also features a lot of instruments for
graphical feedback, such as a scope and an FFT-plot. This makes GRC a powerful tool both for
simulating results of a planned system, as well as implementation of actual SDR systems.

One of the shortcomings of GRC is that many blocks are made for specific applications and are
not very well documented.



3
Theory



Fig. 2: Block schematic of a theoretical digital communication system
Source
In a digital communication system, the source can be a number of different things; voice, a
sensor, a bit-stream, etc. Common for all the sources is that it is converted into quantized
voltage levels and passed on into the next block in the communication system. The source in
this project is our own voice. We want to be able to have one-way communication between our
two transceivers. Voice communication has most of the information in the lower frequencies of
the audible 0-20 kHz frequency span, so it is common to use a sample rate which is as small as
possible, but still enough to ensure clear and easily readable voice. In addition to a smaller
sampling rate it is also possible to have a non-linear quantization of the signal, but that will be
more thoroughly discussed in the Source Coding section.
Channel Model
The major problem with non-ideal communication channels is noise. If noise dominates the
received signal sufficiently, the received signal might be interpreted as a different signal/symbol
than it actually is. One of the simplest noise models is the additive noise model. I.e. if the
voltage sent is x and the noise is w, then the voltage received y is equal to the voltage sent plus
the noise.

y x w = + (1.1)



4

Fig. 3: Additive Noise Channel Model

The noise contribution can be either positive or negative. If we assume as follows below, it can
be showed by using the central limit theorem that the noise has a Gaussian distribuition [3]
with mean equal to 0, and variance 'sigma';
1. The total noise is a result of many sub-noises.


1 2
...
m
w n n n = + + + (1.2)

2. These sub-noises have little correlation with each other and are statistically independent
3. Each sub-noise contributes with an equal amount of energy.
4. There are many sources of sub-noises, i.e. thermally, device imperfections,
measurement inaccuracy, other transmitters, etc.

This channel type is commonly denoted as an Additive White Gaussian Noise channel (AWGN).
Regarding detection of signals, there also exists several models. The most intuitive types is
binary symmetric (BSC) and binary erasure channel (BEC). They are also easily convertible as q-
ary channels. BSC decisioning will give give a digital '0' or '1', while BEC will give either '0','error'
or '1'. The 'e' is an error, denoting if the received signal has a high possibility of being
interpreted wrong.

Fig. 4: BSC and BEC channel models [4]

In addition to noise, the channel is affected by sudden changes in the channel response due to
small scale and large scale fading. Large scale fading includes e.g. multi pathing due to
reflections from a mountain, or changing atmospheric conditions like rain, aurora etc. Small
scale fading is mainly caused by small changes in position on the transmitter or receiver side,
which in turn can cause phase shifted multipath signals to partially or completely attenuate the
resulting signal.


5


Fig. 5: Multiple paths from transmitter to receiver [5]

Source Coding/Decoding
The source usually contains a lot of redundant information. In communication techniques it is
beneficial to construct this redundancy in such a way that is most optimal for the
communication channel. This is done by removing redundant information by source coding and
adding structured redundancy by applying channel coding. Channel coding is described in more
detail in the next section. Shannon derived a fundamental limit regarding information content
in a message called the entropy (Shannon entropy) of the channel. The entropy is defined as:

( ) ( )
2
1
log
k
i i
i
H P P P
=
=

(1.3)

Where P is the probability of symbol i from the table of symbols is sent. One of the most
efficient source codes used is the Huffman code that exploits the property of some
words/symbols is sent more frequent than others (variable length coding). Hence the most
used words/symbols are allocated the shortest code word. The code is also a prefix-free code
where no code word is a prefix of another in order to cancel the possibility for a code word to
be ambiguous when it is decoded.

Channel Coding/Decoding
While the source coding removes redundancy, channel coding adds structured redundancy in
order to minimize the bit error rate (BER). The channel adds different types of distortion like
noise, interference and fading to the signal, thus some effort should be done in order to make
the signal more resistant to these effects. By applying clever codes it is possible to get less bit
errors compared to using uncoded signals. One of the simplest types of coding is parity code,
where the first or last bit of a sequence of transmitted symbols is an XOR'ed product of all the
other information bits. The biggest weakness of this code is that it only detects if there is an
odd number of errors. There exists codes that is error detecting and/or correcting, like


6
Hamming code. The optimal code has to be decided with regards to the channel type, rate,
feedback, complexity and link budget.

Shannon provided us with another formula applicable for the AWGN channel. The channel
capacity is given by the following formula:


2 2
0
log 1 log 1
P S
C B B
N B N
| |
| |
= + = +
| |

\ .
\ .
(1.4)

Shannon also presented a theorem stating that there exists a code that will achieve the channel
capacity (for a certain error rate and sufficient length). However, he did not say anything about
how to find that code in a structured way. In more recent time, good linear codes (although
complex) have been created that is close to achieving the channel capacity. Turbo codes and
low-density parity check (LDPC) codes is some of the most commercially used codes, especially
Reed-Solomon (RS).
Pulse Shaping
Even though we figuratively send out square-shaped bits/pulses it is not optimally to do that in
practice due to the required bandwidth and energy to do so. Instead a more smooth pulse is
used with an optimized narrow frequency. The most optimal utilization of the bandwidth is to
use a sinc-pulse that gives a square response in the frequency domain. However, this gives very
slow ripple decay of the pulse, thus the robustness of timing-jitter is very poor. Just a small
mismatch in timing would result in a large mixing with the other pulses that is sent and might
result in detection error. To compensate for this, then a raised cosine pulse can be used that
has a faster decay of the ripple. However, the trade-off is losing bandwidth efficiency.


( )
2
2
2
cos
sin ,0 1
1 4
t
t T
h t c
t T
T

| |
|
| |
\ .
=
|
\ .

(1.5)


( )
1
2
1 1 1
1 cos ,
2 2 2 2
0
f
T
T
T T
H f f f
T T T
otherwise

( | | + (
= +
( |
(

\ .

(1.6)


7

Fig. 6: Raised cosine characteristics [6]

The limit 0 = gives the sinc-function and with varying it is possible to adjust the ripple
decay, but suppressing ripples decreases bandwidth efficiency. The raised cosine pulse satisfies
the Nyquist criteria regarding inter symbol interference (ISI) free signaling:

( )
1, 0
0, 0
s
n
h nT
n
=
=

(1.7)


1
1
k
s s
k
H f
T T
+
=
| |
=
|
\ .

(1.8)

In practice it states that ISI-free signaling is achieved when the super-positioned spectrum of
the pulses creates a flat frequency spectrum.
Modulation/Demodulation
The process of modulation is basically just changing our source data into something more
suitable for transmission on the channel we have available. This includes e.g. mixing our signal
with a high frequency carrier to fit it inside a band pass channel and/or interchange variations
in amplitude, phase of frequency with certain techniques to reduce need of bandwidth and/or
power.

In our system, we will use Gaussian Minimum Shift Keying (GMSK), which is a modulation
scheme that relies on basic MSK modulation working in conjunction with a Gaussian filter to
reduce sideband power. MSK on the other hand, is just a derivation of normal frequency shift
keying (FSK), with a modulation index k of 0.5. This essentially means that the difference in
frequency between the modulated bits is as small as possible and the frequency change occurs


8
at the zero-crossings. By doing so, we eliminate discontinuities in the signal and greatly increase
bandwidth efficiency. The bandwidth usage for MSK can be expressed as:

1.5
b
B R = (1.9)

Where
b
R represent the data rate. The Gaussian filter applied in GMSK further increases
spectral efficiency, but comes at the cost of greater risk of inter symbol interference. A
parameter BT defines the properties of the Gaussian filter. B represents the 3 dB bandwidth
of the Gaussian filter, and T represents the bit duration. GSM uses GMSK with a filter BT-value
of 0.3, which is the lowest useable BT-value without suffering severe ISI.

The bandwidth of GMSK-modulated data can be expressed as follows:


b
B BT R = (1.10)
Link Budget Calculations
The link budget can be calculated in several ways, depending on how many variables you want
to take in consideration and which you think is affecting the channel in the given situation. A
simple link budget we use is denoted here:


0 TX TX RX RX A
S
P G L k B G T L
N
= + + (1.11)

At this point we will calculate the link budget according to the implementation in the practical
part. As will be mentioned, this implementation turned out to be pretty far from theory.



9
We start off by listing all the parameters as we know them:

Parameter Description Our approximated value
TX
P Power transmitted 50
10 log 17
1
mW
dBm
mW
| |
=
|
\ .

TX
G Transmitter antenna
gain
2.1 dBi
Signal wavelength
8
3 10 /
12.5
2.4
c m s
cm
f GHz

= =
d Distance between the
communicating parts
5m
0
L Free space attenuation 4 4 12.5
20 log 20 log 54,02
5
cm
dB
d m
| | | |
= =
| |
\ . \ .

k Bolzmanns constant
( )
23
10 log 1,38 10 / / 228,6 / / W Hz K dBW Hz K

=
RX
G Receiving antenna gain 2.1 dBi
RX
T

Receiver noise
temperature
( ) 8
10 10
0
10 1 290 10 1
1539.8 31.87
NF dB
T T K
K dB
| | | |
| |
\ . \ .
| | | |
= = = | |
| |
\ . \ .
=

B
Bandwidth
( ) 0.35 48 8 134,4 51.28
b
B BT R KHz KHz dB = = = =

A
L

Additional losses 30 dB
Table 1: Link budget - practical setup

The transmitter power is taken from the RFX2400 data sheet, and the antenna gain is under the
assumption that we are using dipole antennas. The receiver noise temperature is a rough
assumption based on the receiver noise figure, which was said to be 6-10dB [7]. Unfortunately
this was the best we could do, as detailed specifications for the RFX2400 is not available. The
bandwidth is calculated with the formula mentioned under Modulation/Demodulation.

The other losses
0
L is hard to determine, but we have assumed a factor of 30 dB. This includes
some attenuation from multi path signals, non-ideal antennas and interfering transmissions
from other wireless equipment at NTNU.


10


0
17 2,1 54,02 228,6 51,28 2,1 31,87 30
82,63
TX TX RX RX A
S
P G L k B G T L
N
dBm dBi dB dB dB dBi dB dB
dB
= + + =
+ + + = (1.12)

This S/N-ratio is very big, and probably not realistic, but this will be discussed in the Discussion-
part later.


11
Practical system

The theoretical setup turned out to be hard to realize. We were pretty much limited to use the
pre-made blocks for GNU radio companion, and many of these were made for custom use in
specific applications. The practical system has no channel- or source coding due to the lack of
suitable GRC-blocks, and the transmitted data is GMSK-modulated 48 KHz 8-bit PCM audio. A
picture below shows the setup as used on the lab, featuring two computers and two USRP2s.

The transmission channel in this project is a low distance indoor static channel with only
concrete walls as obstacles. Multi pathing could be a problem due to the high frequencies and
concrete walls. The noise sources will primarily be internal and external thermal noise from the
electrical devices inside the room. There is also a 2.4 GHz wireless network all over NTNU that
might interfere with our signals, even though WLAN uses spread spectrum technology and
therefore should affect our signal which is significantly higher than the noise floor.



Fig. 7: The practical setup


12
Shortly described, the system receives 32-bit floating point samples at a rate of 48 KHz from the
sound card. These samples are converted to 8-bit integer samples at the same sample rate. The
packet encoder makes each of the 8-bit samples to eight single boolean values, as the GMSK-
modulator modulates one bit in each symbol, and therefore only accepting one bit at a time.
The output of the GMSK-modulator is directly fed into the USRP2-sink.
Building blocks


Fig. 8: Transmitter blocks


Fig. 9: Receiver blocks




13
Audio Source
The Audio Source block enables us to capture the audio from a sound card, and more
specifically the microphone input. The output of this block is 32-bit floating point samples with
values ranging from -1 to 1, and the sample rate depends on the hardware. Typically supported
sample rates are 44.1 KHz and 48 KHz. The A/D-converter in most sound cards outputs 16-bit
integer samples, so the reason for this block to output floating point values is probably just for
compatibility with other GRC blocks.
AGC2
As will be explained later, our system only has an audio resolution of eight bits. This is sufficient
as long as we use the full dynamic range. To make sure of this we use automatic gain control to
normalize the audio level without thinking about the input audio level. This also means the
operator of the transmitter station can move back and forth from the microphone without
affecting the audio level on the receiver station.
Multiply Const
This block will simply multiply the incoming signal with a fixed value. We need this block to
amplify the samples from the Audio Source block to levels in the -127 to 127 range. This is
approximately the span of possible values in an 8-bit signed integer, also known as a signed
char.
Float to Char
Following the Multiply Const block, we want to convert the floating point float type samples to
eight bit char/byte type integer samples, which is easily done with a Float to char block.
Packet Encoder (and Decoder)
The packet encoder makes the incoming stream of samples to chunks of bits. The number of
bits in each chunk can be adjusted to match the next block; the modulator. A GMSK-modulator,
for example, modulates one bit in each symbol. This means each bit in the incoming eight bit
samples should be sent out one bit at a time. What this also implies is that the sample rate is
changed from the input to the output, and this needs to be taken into account.
Unfortunately, this block is a typical example of the resource overhead in GRC; each of the
bools outputted are handled as 32-bit floats!

The Packet decoder does the exact opposite process as the Packet encoder.



14
GMSK Modulator (and Demodulator)
As described in the theory part, the modulator makes the incoming data to an RF-transmittable
signal. The GMSK-modulator has certain parameters which will be mentioned under the sample
rate calculations below.

The GMSK demodulator does the exact opposite process as the GMSK modulator.
Throttle
The Throttle block is mainly used to keep a constant flow of samples through a system when
sample rate limiting blocks like the USRP2 and the sound card are not used. On other words it
prevents the computer from using all available resources to process samples at the highest rate
possible. As far as we have tested, we have also found the block to help with buffering when
there are slight differences in sample rate between blocks, but we have not found any
documentation to extensively explain the functionality of the Throttle block.
USRP2 Sink (and Source)
To communicate with the USRP2, we need a USRP2 sink or source. As mentioned the USRP2
accepts samples at 100 MS/s, but the built in interpolator and decimator makes the hardware
very flexible when it comes to sample rate. These parameters are easily set as part of the block
parameters as shown in the block diagram. The center frequency and RX/TX-gain can also easily
be set this way.
Sample Rate Calculations
There are two fixed sample rate blocks in the transmitter system; the sound card source and
the USRP2 sink. These are the first and last blocks, respectively. We need to do certain
calculations to ensure the flow of samples will not result in overflow or underrun in the last
block.

At the transmitter end, the sound card source outputs 32-bit float samples at 48 KHz. These are
in turn multiplied with 127 and converted to eight bit integers. The GMSK-modulator outputs
two samples per symbol, and each symbol carries one bit of data. The USRP accepts samples at
a 100 MHz sample rate, so we will use the USRP2 interpolator and calculate the closest match
for the interpolation factor.

The interpolation factor for the USRP2 should be:



15

100 / 100 /
130.2
768 /
48 8 2 1
Rawdatarate MS s MS s
b S symbol
Desired rate kS s
KHz
S symbol b
= = =

(1.13)
As the interpolation factor cannot be a fractional number, we round it down to 130. This might
result in some unwanted buffer underruns or overflow, but it is the best we can do. On the
receiver end the calculations are the same as for the transmitter, except we should decimate
with the number 130.
Results
The system was tested in- and outside the lab and we were able to maintain the
communication link at a distance of about 10 m with one concrete wall and one wooden-door
between the two units. Moving the receiver with only a few centimeters gave significant signal
attenuation, most likely due to multi path effects. Variation in polarization also resulted in high
attenuation. The worst case experience occurred when the receiving antenna was pointing
towards the transmitter, which caused the signal to be buried in noise. In addition, the
communication link was highly system dependent, due to the different USRP setups seemingly
having varying performance. The built-in microphone in the computer was used and it
performed acceptable.

As shown in the FFT plot below, the S/N-ratio at a distance of five meters was approximately 45
dB. At a distance of ten meters, the S/N-ratio dropped to about 40 dB and the communication
was abrupted. Unfortunately it was not possible to determine the absolute power levels of the
noise floor and signal strength, as there are amplifiers in both software and hardware
throughout the system and the values does not have any reference. The 3 dB bandwidth can
be estimated to be approximately 200 KHz.


Fig. 10: Frequency plot of the received signal


16
Discussion
Starting off with the signal budget we noticed a pretty big difference from theory to practice.
Theory estimated an S/N-ratio of about 77 dB, but we measured an S/N-ratio close to 45 dB.

Some of the parameters in the theoretical S/N-ratio were not reliable. The noise figure was
found on a non-official page, as we couldnt find any numbers on the Ettus Research home
page.

The measurements were done in a simple matter. As mentioned, the output from the USRP2
can be scaled with gain parameters on the receiver side, and as far as we have observed they
do not have a reference level. It is therefore hard to know what these numbers actually mean.

The quality of the sound was a bit varying with some random glitches, but fully readable. It
might have been better if we had implemented channel coding, but as mentioned we were
limited by the available blocks.

The difference in interpolation/decimation factors from calculated values also created a
steadily increasing delay that resulted in a glitch when the buffer suffered an overflow and
flushed after a few minutes.

Variation in hardware performance introduced a big problem, as the noise floor varied from
day to day, and some of the USRP2s were almost unaffected by disconnecting the antenna. It is
reasonable to believe that this was caused by bad termination of the coaxial cable inside the
chassis. The results in this report are based on the best measurements, and are therefore
hopefully unaffected by faults in hardware.

The attenuation tests regarding distance and polarization showed expected results.
When we increased the distance from 5 to 10 meters the signal strength fitted very well with
the
2
1/ r relationship between signal strength and distance, which would imply a 6 dB loss in
signal strength when doubling the distance. Changing the polarization had great effect, but
pointing the receiver antenna at the transmitter resulted in a complete loss of signal. This
behavior matched perfectly with the radiation pattern of a theoretical dipole antenna.




17
Conclusion
A one-way digital voice-communication system was implemented using SDR. The system
performance was about what we expected, with 10 m range and clear audio, but the
performance was clearly limited by the lack of source and channel coding. This can in turn be
said to be a limitation in GRC unless we were expected to make these blocks ourselves. The
range and polarization tests showed just what was expected from theory. Overall, we found the
project to be exiting, and it was fun to finally have tested some SDR-equipment.



18
Abbreviations
GRC GNU Radio Companion
GNU GNU's not Unix
ISI Intersymbol Interference
AWGN Additive White Gaussian Noise
USRP Universal Soft Radio Peripheral
FPGA Field-Programmable Gate Array
BER Bit Error Rate
BSC Binary Symmetric Channel
BEC Binary Erasure Channel
LDPC Low-Density Parity Check
WLAN Wireless Local Area Network
SDR Software Defined Radio
MSK Minimum Shift Keying
FSK Frequency Shift Keying
GMSK Gaussian Minimum Shift Keying
FFT Fast Fourier Transform
Appendix
1. GNU Radio UsrpFAQIntro. Accessed October 24
th
, 2011.
http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQIntro
2. Picture: Accessed November 28
th
, 2011.
http://www.dl8rds.de/images/6/69/Usrp2-open-lfrx.jpg
3. Ramchandran, Kannan. (2011) EE121: Digital Communications, A Statistical Model for
Additive Noise. UC Berkeley, Berkeley
4. Picture: Accessed November 21
st
, 2011.
http://wifo.eecs.berkeley.edu/wiki/doku.php/figures:infotheory
5. Piture: Accessed November 28
th
, 2011.
http://ytdp.ee.wits.ac.za/cctpng/Fading.png
6. Picture: Accessed November 21
st
, 2011.
http://en.wikipedia.org/wiki/File:Raised-cosine-filter.png
7. USRP Reference. Accessed November 28
th
, 2011.
http://wiki.oz9aec.net/index.php/USRP_Reference