SDR BASED OFDM FOR LOW RATE VIDEO TRANSMISSION SYSTEM

MOHD HIDIR BIN MOHD SALLEH

UNIVERSITI TEKNOLOGI MALAYSIA

 PSZ 19:16 (Pind. 1/07)

UNIVERSITI TEKNOLOGI MALAYSIA

DECLARATION OF THESIS / UNDERGRADUATE PROJECT PAPER AND COPYRIGHT

Author’s full name : MOHD HIDIR BIN MOHD SALLEH

Date of birth : 11th JANUARY 1989

Title : SDR BASED OFDM FOR LOW RATE VIDEO TRANSMISSION

SYSTEM

Academic Session : 2011/2012

I declare that this thesis is classified as :

CONFIDENTIAL (Contains confidential information under the Official Secret

Act 1972)*

RESTRICTED (Contains restricted information as specified by the

organisation where research was done)*

√ OPEN ACCESS I agree that my thesis to be published as online open access

(full text)

I acknowledged that Universiti Teknologi Malaysia reserves the right as follows:

1. The thesis is the property of Universiti Teknologi Malaysia.

2. The Library of Universiti Teknologi Malaysia has the right to make copies for the purpose
of research only.
3. The Library has the right to make copies of the thesis for academic exchange.

Certified by :

SIGNATURE SIGNATURE OF SUPERVISOR

890111-23-5425 PROFESSOR DR NORSHEILA BT FISAL

(NEW IC NO. /PASSPORT NO.) NAME OF SUPERVISOR

Date : 3 JULY 2012 Date : 3 JULY 2012

NOTES : * If the thesis is CONFIDENTAL or RESTRICTED, please attach with the letter from
the organization with period and reasons for confidentiality or restriction.
 i

“I hereby declare that I have read this thesis and in my opinion this thesis is sufficient in
terms of scope and quality for the award of the degree of Bachelor of Engineering
(Electrical-Telecommunication).”

Signature : ……………………………………..
Name of Supervisor : PROF. DR NORSHEILA BT FISAL
Date : 3rd July 2012
SDR BASED OFDM FOR LOW RATE VIDEO TRANSMISSION SYSTEM

MOHD HIDIR BIN MOHD SALLEH

A thesis submitted in fulfillment of the requirements for the award of

the degree of Bachelor of Engineering (Electrical-Telecommunication)

Faculty of Electrical Engineering

Universiti Teknologi Malaysia

JULY 2012
 ii

I declare that this thesis entitled “SDR based OFDM for low rate video transmission” is
the result of my own research except as cited in the references. The thesis
has not been accepted for any degree and is not concurrently submitted in
candidature of any degree.

Signature : ………………………………………...
Name : MOHD HIDIR BIN MOHD SALLEH
Date : July 2012
 iii

Dedicated, to….

My beloved and adored parent,

All my cherished sisters (Noni, Sartini & Asma‟),
All my precious brothers (Rudy, Hadi, Azmi & Kamal)
and
All SET members batch 2008-2012…
In appreciations of most love, continual support, encouragement and infinite motivations.
 iv

ACKNOWLEDGEMENT

First and foremost, all praise is to Allah, the Almighty, the Benevolent for His
blessings, guidance and for giving me strength, health and the inspiration to embark on
this journey. I would also like to show my gratefulness to my most adorable supervisor
Prof. Norsheila Binti Fisal for all her long last guidance and motivation including her
willingness on sharing her deeply and essential knowledge towards me to accomplish this
project.

Secondly, I would also like to express my appreciation to all Telekom research

group members especially to Mr. Hilmi, Mr. Khairul, Mr. Arief and Mr. Hadi for giving
me such a continual helps and guidance. On top of that, they also help me by
recommending me related notes, reference, and trying together to solve problems appear
in this project.

My appreciation also goes to my laboratory partner, Natasya for being a helpful

and tolerates company for the whole one year of period of taking Undergraduate project
course. Nevertheless, my special thank to my parents which have always supported me
for the last four years of my undergraduate. Last but certainly not least, I would like to
thank all SET members especially for batch 2008-2012 and also the SET seniors for
helping me either in directly or indirectly ways and manners.
 v

ABSTRACT

Video signals require high bandwidth channels to ensure good Quality of Service (QoS).
However, if the channels have a limited capacity, then there is a need to provide a design
a mechanism that gives reasonable Quality of Service (QoS). The challenge is to design
an appropriate baseband processing for low bit rate video transmission in order to achieve
the desired QoS. An example of and video data transmission application that has a
limited capacity is video transmission in wireless sensor network. This project deploys a
software defined radio (SDR) platform using USRP and GNU radio to provide
programmable architecture for low bit rate video transmission over the wireless medium.
This thesis presents the implementation of video transmission using Software Defined
Radio (SDR) for M-ary quadrature amplitude modulation (M-QAM) in Orthogonal
Frequency Division Multiplexing (OFDM) system.
 vi

ABSTRAK

Isyarat video memerlukan saluran jalur lebar yang tinggi untuk memastikan Kualiti
Perkhidmatan (QoS) yang baik. Walau bagaimanapun, jika saluran mempunyai kapasiti
yang terhad, adalah menjadi keperluan untuk menyediakan mekanisme reka bentuk yang
memberikan Kualiti Perkhidmatan (QoS) munasabah. Cabaran yang dihadapi adalah
untuk mereka bentuk pemprosesan jalur asas yang sesuai untuk video penghantaran
berkadaran bit rendah bagi mencapai QoS yang diingini. Satu contoh dan applikasi video
penghantaran data yang mempunyai kapasiti yang terhad adalah penghantaran video
dalam rangkaian sensor tanpa wayar. Projek ini berplatformkan radio ditakrifkan oleh
perisian (SDR) yang menggunakan USRP dan GNU radio untuk menyediakan seni bina
atur cara bagi video penghantaran berkadar bit rendah pada medium wayarles. Tesis ini
membentangkan pelaksanaan penghantaran video menggunakan Radio didefinikan oleh
Perisian (SDR) untuk M-Ary pemodulatan amplitud sukuan (M-QAM) dalam sistem
Pemultipleksan Pembahagian Frekuensi ortogonal (OFDM).
 vii

TABLE OF CONTENT

CHAPTER TITLE PAGE

DECLARATION ii
DEDICATION iii
ACKNOWLEDGEMENTS iv
ABSTRACT v
ABSTRAK vi
TABLE OF CONTENTS vii
LIST OF TABLES x
LIST OF FIGURES xi
LIST OF ABBREVIATIONS xiii
LIST OF SYMBOLS xv

1 INTRODUCTION 1
1.1 Project Background 1
1.2 Introduction To SDR 2
1.3 Problem Statements 3
1.4 Objectives 4
1.5 Scope Of Work 4
1.6 Thesis Outline 5

2 LITERATURE REVIEW 7
2.1 Video 7
2.1.1 Analog video 8
2.1.2 Digital video 8
 viii

2.1.2.1 Video Format 9

2.1.3 Video properties 10
2.1.4 FFMPEG Encoder 12
2.1.4.1 FFMPEG transcoding process 14
2.2 Hardware 17
2.2.1 USRP 17
2.2.2 Daughterboard 19
2.2.3 ADC 20
2.2.4 DAC 21
2.2.5 USB 2.0 21
2.2.6 FPGA 22
2.3 Software Defined Radio System 23
2.3.1 Gnu Radio 23
2.3.2 SDR Architectural Limitations 24
2.4 OFDM 25
2.4.1 Cylic Prefix 27
2.5 QAM 28

3 METHODOLOGY 30
3.1 Methodology Of Project 30
3.2 Hardware Setup 30
3.3 Software Setup 31
3.3.1 GNU radio installation for Ubuntu 31
3.4 System Design 33
3.4.1 Designing a simple digital video broadcasting 34
3.4.2 Creating a pipeline 35
3.4.3 Gstreamer source coding 37
3.4.4 GNU Radio Companion 39
3.4.5 Bitrate calculation 41
3.5 Summary 44
3.5.1 Transmitter Flowchart 45
 ix

3.5.2 Receiver Flowchart 46

4 RESULT & ANALYSIS
4.1 Introduction 47
4.2 Preliminary Experiments 48
4.2.1 Study on the effect of FFT length 48
4.2.2 Study on the effect of modulation scheme 53
4.2.3 Study on the effect of payload length to the video quality 57
4.3 Main Experiments 62
4.3.1 Investigate the effect of BER for different FFT bin 62

5 CONCLUSION 64
5.1 Conclusion 64
5.2 Suggestions/Recommendation 65
5.2.1 Python 66
5.2.2 Synchronization 66
5.2.3 Protocol 66

REFERENCES 67
APPENDIX A 70
APPENDIX B 71
APPENDIX C 75
APPENDIX D 79
 x

LIST OF TABLES

TABLE NO. TITLE PAGE

2.1: Examples of standards aspect-ratio 11

2.2 Some important video parameters and its formula 12
2.3 USRP and USRP 2 18
3.1 The important formulas to calculate data rate 41
3.2 Calculated data rate for experiment 4.2.1 43
3.2 Calculated data rate for experiment 4.2.2 43
3.3 Calculated data rate for experiment 4.2.3 43
3.4 Calculated data rate for experiment 4.3.1 43
4.1 The achievable bit rate of various occupied subcarriers
for 128 FFT length 49
4.2(a) The video snapshot of 32 occupied subcarriers for
128 FFT length 50
4.2(b) The video snapshot of various occupied subcarriers in
128 FFT length 51
4.3(a) The received video snapshot for 1 modulation bit 54
4.3(b) The received video snapshot for 2,3 and 4 modulation bit 55
4.4 Effect of modulation scheme to the delay 56
4.5(a) Video Screenshot for different payload length 58
4.5(b) Video Screenshot for different payload length 59
4.6 Effect of Payload Length to the video bitrate 60
 xi

LIST OF FIGURES

FIGURE NO. TITLE PAGE

1.1 SDR Architecture 2

2.1 Horizontal Scan Vs Display Brightness 8
2.2 Overview for SDTV and HDTV video format 10
2.3 Ffmpeg transcoding processes 14
2.4(a) A simple encoder before considering filtergraph 15
2.4(b) A simple encoder with a simple filtergraph 16
2.5 Simple filtergraph block diagram 16
2.6 Complex filtergraph block diagram 16
2.7 USRP Architecture 18
2.8 Various type of USRP daughter boards 20
2.9 The USRP board 22
2.10 Basic SDR system based on USRP and GNU Radio 23
2.11 OFDM simulation flowchart 26
2.12 Simple OFDM blok transmitter 27
2.13 Digital 16-QAM with example constellation points 29
3.1 Synaptic Package Manager Screenshot 32
3.2 Simple Video transmission setup 34
3.3 A transceiver system with pipeline connection 36
3.4 Gstreamer code at the transmitter terminal 38
3.5 A basic OFDM transceiver flow graph 40
 xii

3.6 Transmitter flow-chart 40

3.7 Receiver flow-chart 41
4.1 Percentage of achievable bit rate for various subcarriers 49
4.2 Snapshot of transmitted video 50
4.3 Snapshot of transmitted video through OFDM system 54
4.4 Snapshot of transmitted video through OFDM system
for experiment 4.2.3 57
4.5 Percentage of achievable bit rate for various payload length 60
4.6 The BER counts for different size of FFT and samples size 63
7 Experimental Setup 70
 xiii

LIST OF ABBREVIATIONS

SDR - Software Defined Radio

USRP - Universal Software Radio Peripheral
ADC - Analog to Digital Converter
DAC - Digital to Analog Converter
USB - Universal Serial Bus
FPGA - Field Programmable Gate Array
OFDM - Orthogonal Frequency Division Multiplexing
QAM - Quadrature Amplitude Modulation
SNR - Signal to Noise Ratio
HDR - Hardware Defined Radio
RF - Radio Frequency
AFRL - Air Force‟s Rome Laboratory
ICNIA - Integrated Communications, Navigation, and Identification
Architecture
LNA - Low Noise Amplifier
BPF - Bandpass Filter
MPEG - Moving Picture Experts Group
PA - Power Amplifier
ISM - Industrial, Scientific and Medical
MUX - Multiplexer
DEMUX - Demultiplexer
RGB - Red, Green, Blue
 xiv

CMYK - Cyan, Magenta, Yellow, Black

CD - Colour Depth
MIMO - Multiple Inputs, Multiple Outputs
CPU - Central Processing Unit
CP - Cyclic Prefix
BER - Bit Error Rate
SER - Symbol Error Rate
QoS - Quality of Service
FFT - Fast Fourier Transform
IFFT - Inverse Fast Fourier Transform
QPSK - Quadrature Phase Shift Keying
OS - Operating System
PAL Phase Alternating Line
NTSC National Television System Committee
SECAM Sequential Couleur Avec Memoire
SDTV Standard Definition Television
HDTV High Definition Television
PC Personal Computer
SPM Synaptic Package Manager
 xv

LIST OF SYMBOLS

W - Width
H - Height
Fr - Frame Rate
GHz - Giga Hertz
MHz - Mega Hertz
Kbps - kilobits per second
dB - Decibel
BW Bandwidth
DR Data rate
CR Coded Rate
Tg Guard interval
Tfft FFT period
df Subcarrier spacing
Tsymbol OFDM symbol period
 1

CHAPTER 1

INTRODUCTION

1.1 Project Background

Conventional television, radio and telephone which are built based on special RF
circuit are considered as hardware dependent technologies. All of these devices may be
categorized as hardware defined radio (HDR) due to their limitation in functionality
which depends on dedicated RF card. All parameters in radio access interface are fixed
parameters which cannot be reconfigured. HDR devices were specially designed to meet
the end-user application. By doing that, users only need to buy and use the hardware
according to the specification provided by the suppliers. The problems exist when the
user wants to reconfigure the hardware especially for other purposes. Users have to buy
and replace with new hardware to be used for the other specific application. Software
Define Radio (SDR) devices allow simple reconfiguration of the software or design
instead of new program to make it function as they wanted to. Today, the usage of SDR
is crucial as it will save a lot of expenses in developing outstanding applications.
 2

1.2 Introduction To SDR

Software Defined Radio (SDR) is a structure in which software will define

modulation, signals, frequency and (optionally) cryptography. SDR design started as
early as 1987, when the United States Air Force‟s Rome Laboratory (AFRL) developed a
programmable modem in which was based on the integrated communications, navigation,
and identification architecture (ICNIA) [1].

Figure 1.1: SDR Architecture

The basic hardware architecture of SDR contains an analog and a digital part as
illustrated in figure 1.1. The analog of Radio Frequency (RF) end part is on the left hand
side of the antenna. The right hand side part is the digital end part. In the analog form,
the signal received from the antenna is first amplified by using Low Noise Amplifier
(LNA). Then, it is mixed and filtered by a band pass filter (BPF) to generate an
intermediate frequency (IF) signal. The signal is then digitized by the ADC using high
speed converter before it is down-converted to a baseband signal. Then, the digital signal
 3

is demodulated and packetized at full baseband processing by a special command built on

the software interface. Lastly, the packet data will be decoded by a suitable video
decoder such as ffmpeg decoder before it can be played by an end user.

Similarly at the transmitter part, the video is first modulated into baseband signal
and changed into analog output. It is then up-converted and bandpass filtered to generate
the RF signal. The RF signal is further amplified by the Power Amplifier (PA) and the
fed to the antenna.

1.3 Problem Statement

Video transmission requires high bandwidth and good quality of service (QoS)
applications mainly involves streaming as well as applications that require higher quality.
However, if the channels have limited capacity, then it is required to provide a design
mechanism that gives reasonable QoS. The challenge is to design an appropriate
baseband processing for low bit rate video transmission in order to achieve the desired
QoS.

1.4 Objectives

The main goal of the project is to develop and implement a low rate
reconfigurable video transmission on ISM band via SDR.
 4

The specific objectives of this project include:

1. To develop reconfigurable video transmission using GNU Radio software on
USRP.
2. To design an appropriate baseband processing for low bit rate using SDR
architecture.
3. To develop a low rate video transmission system with an acceptable QoS.

1.5 Scope Of Work

In order to determine the span of the project, scope of work for this project must
be identified first at the beginning of the project. In this project, the main scope is to
apply M-ary Quadrature Amplitude Modulation (M-QAM) modulation scheme in OFDM
system for video transmission application. The OFDM system is constructed by using
SDR technique with M-QAM as the mapper.

The SDR technique comprises of both software and hardware platforms. GNU
radio software will be used as the software whiles the Universal Software Radio
Peripheral (USRP) as the hardware platform.

On the software part, the GNU Radio Companion which is graphical interface for
GNU Radio software has been used to make the reconfiguration process become easier.
The GNU Radio is a Python based programming which implemented in open source
operating system such as Ubuntu or Fedora. The basic functions of GNU Radio has been
 5

programmed by using C++ and the block functions must be glued together to make an
OFDM system by using Python programming.

The overall project designs is implemented at 2.4 GHz industrial, scientific and
medical (ISM) band that provided by RFX 2.4 daughterboard

1.6 Thesis Outline

This project report comprises of five chapters includes introduction, literature

review, methodology, result and discussion and conclusion. The introduction of this
project described in chapter 1. This chapter is focused on introducing the title and
objective of this project. Furthermore, this chapter explains the scope of work and the
outlines.

Chapter 2 concentrates on literature review of related projects to provide basic

understanding about related terms and functions of system designs such as OFDM,
USRP, video signal and etc. On top of that, this chapter also includes basic video
transmission understanding and SDR architecture.

Chapter 3 is the methodology of this project. The project workflow consists

of software and hardware setup, design process, and experimental setup and testing. The
GNU Radio installation guide and the design of Video transmission system using
gstreamer and GNU Radio are discussed in details in this chapter.
 6

Chapter 4 discusses the result and discussion related to this project. The results
obtained is divided into two parts, where the first part consists of serial experimental to
achieve the best configuration in OFDM system while the second part is analysis on the
BER and quality of received video.

Chapter 5 is the last part of this project. In Chapter 5, the overall project design
and experiments is concluded. In addition, the limitations and future work of this project
also are discussed.
 7

CHAPTER 2

LITERATURE REVIEW

2.1 Video

There are several types of composite video such as Phase Alternating Line (PAL),
National Television System Committee (NTSC) and Sequential Couleur Avec Memoire
or sequential color with memory (SECAM). PAL is one of widely use analogue
television encoding system. The encoding process is different and incompatible between
each other. Once the video signal is received, there is a need to create the color of the
picture, and synchronize the line and frame pulse.

The luminance (brightness) and chrominance (color) of color must be separated

while recreating the video color. The luminance of the picture is combined linearly with
the chrominance information from modulated subcarrier. One of the color space that
separated between luma and chroma is YUV where combination of one Y (luminance)
and two chrominance U and V colors.
 8

2.1.1 Analog Video

By capturing the video signals and scanning to the computer or television screen,
a picture can be drawn. An electrical signal was horizontally drawn across the display
one line at a time. The amplitude of this signal versus time represents the instantaneous
brightness at that physical point on the display. Figure 2.1 shows the signal amplitude
relationship to the brightness on the display.

Figure 2.1: Horizontal Scan Vs Display Brightness

2.1.2 Digital Video

The digital video standard is determined by more than 60 companies who joined a
consortium for digital video format consumer. The companies include Panasonic, Sony,
Victor Corporation of Japan (JVC), Sanyo, Hitachi and many more. Digital video
consists of a series of orthogonal bitmap digital images displayed in rapid succession at a
constant rate. These images are called frames. The rate at which frames are displayed is
measured in frames per second (FPS). Since every frame is an orthogonal bitmap digital
 9

image, a frame comprises a raster of pixels. Pixels are described by one property, their
color. The color of a pixel is represented by a fixed number of bits. If more bits are used,
the more subtle variations of colors can be reproduced. This is called the color depth
(CD) of the video.

Digital video uses intra-frame and interfiled compression. Intra-frame

compression fully depends on the present frame of data, not on the preceding or the
following frames. Inter-field compression produces static image which is clearer
compared to the moving area of images because it compresses any detectable difference
between two interlaced of a frame.

2.1.2.1 Video Format

There are several formats used in digital television (TV), webcam or other video
products such as standard definition television (SDTV) and high definition television
(HDTV). Both of these formats are distinguished by scanning modes, frame rates, video
dimension and etc. Figure below illustrates the SDTV and HDTV dimension formats.
 10

Figure 2.2: Overview for SDTV and HDTV video format

2.1.3 Video properties

Before compressing and encoding of a video signal, there are several terms and
configurations should be set at the transmitter such as dimension, aspect-ratio, color-
space and video frame rate in order to derive the image formats.

 Dimension and aspect-ratio

The term dimension is not necessarily refers to the size when displaying the video
but it shows the pixel array used to encode the video. This is because many video
standards do not use square type of pixel. The dimension of a video is usually in
the format of width x height (w x h) and the unit is pixel. Aspect-ratio or the ratio
between video widths to its heights represents the captured video in a single
frame. The aspect-ratio standards are written in whole number such as 4:3 and
16:9. However, most of video standards use pixels aspect-ratio to display the real
frame as the pixels is mostly in rectangular forms.
 11

Table 2.1: Examples of standards aspect-ratio [24].

Standards Applications
aspect-ratio
4:3 SDTV, Digital Cameras, Computer Displays
5:4 Computer Displays
3:2 35mm Film, DSLR Cameras
16:10 Widescreen Computer Displays
16:9 HDTV, Widescreen SDTV
37:20 Cinema Film
47:20 Cinemascope

 Frame rate and color space

Frame rate can be represented as the total images produced by a device within certain
duration and the unit of frame per second (fps) is often used. There are several
standards of frame rate frequently used in TV and film-making business such as
24fps, 25fps and 30fps. Color model such as red, green and blue (RGB) and cyan,
magenta, yellow and black CMYK must be first determined and mapped using color
space format such as sRGB and Adobe RGB [17].

For example, if a video used a frame size of 320x240 (Width x Height or WH) at a
color depth, CD of 24bits and a frame rate, Fr of 10fps within duration of 1 hour
(60x60=3600seconds). Therefore, the properties of the video are as follows:
 pixels per frame = 320 * 240 = 76800 pixels
 bits per frame = 76800 * 24 = 1843200 = 1.84Mbits
 bit rate (BR) = 1.84Mbits * 10 = 18.4Mbits/sec
 video size (VS) = 18.4Mbits/sec * 3600sec = 66 240Mbits = 8.28 Gbytes
 12

All of the fundamental formulas is summarized to the table below:

Table 2.2: Some important video parameters and its formula

Properties Formula

Bitrate BR=W * H *CD * Fr

Video Size VS = BR * T = W * H * CD * Fr * T

pixels_per_frame W*H

pixels_per_second W * H * Fr

bits_per_frame W * H * CD

(units are: BR in bit/s, W and H in pixels, CD in bits, VS in bits, T in seconds)

2.1.4 FFMPEG Encoder

FFmpeg is fast video or audio converter software program that produces libraries
and programs to facilitate user while using multimedia data such as video and audio. The
ffmpeg is able to read any raw video files and resize it to desired size with a high quality
polyphase filters. Besides that, ffpmpeg is also able to convert arbitrary input files such
as pipes, regular video, network streams and etc. into arbitrary output files which need to
be specified by output filenames.

The most important packages that are involved with the use of FFmpeg are
libavcodec (a library for audio / video codec), libavformat (a library for audio / video
container mux and demux), and ffmpeg command line program to transcode multimedia
 13

files. FFmpeg is published under the GNU Lesser General Public License 2.1 + or the
GNU General Public License 2 + (depending on the options allowed) [16].

Ffmpeg encoder can support many video formats such as moving picture
excellent group-4 (MPEG-4), H.264 and MPEG-4 advanced video coding (AVC) through
its library called libx264. Therefore, it is important to download the library lib264
including the headers as a pre-installation before users can really use the configuration.
To build the libx264 library, the command below must be configured [23]:

--enable-libx264

After enabling the libx264, users can try configuring the desired input and output
of a video by using the following commands:

i. Set the frame rate of output file to 25 frame per second (fps):
ffmpeg –i input.avi –r 25 output.avi

ii. Force the input (only for raw types video) frame rate to 1fps and 24fps output
frame rate:
ffmpeg –r 1 –i input.m2v –r 25 output.avi

iii. Force the output bitrate to 128kbit/s :

ffmpeg –r 1 –i input.avi –b:v 128k output.avi
 14

2.1.4.1 FFMPEG transcoding process

Transcoding is a direct conversion data from digital to digital between an encoder

to another encoder. The process must be done since not all encoder can support the
formats of input data. On the other hand, if a target device has limited capacity and need
to reduce the quality or to convert the signal to better formats that can support them,
transcoding is performed. The process of transcoding a video is illustrated by the figure
2.3.

Figure 2.3: ffmpeg transcoding processes

Firstly, a library namely libavformat which contains demultiplexers is called by

ffmpeg to read the input signal and encode it to make it as packets. FFmpeg shall
perform synchronization of the data when they come with multiple numbers of inputs by
searching for the lowest timestamp on any input.

Then the packets data will be passed to the decoder except for the data which is
streamcopy types is selected to the stream. The function of decoder is to produce data
frames with original size without compression. The frames is further transfer to the filter
so that filtration of video can be performed be being encoded. The filtered frames are
 15

then encoded by using encoder before they were further multiplex by the muxer. At this
rate, the output will become packets once again. Finally, the muxer process the packets
data and write the output

Before the frames can be encoded, the filtration process needs to be performed by
ffmpeg via filter provided in libavfilter library. The filters can be connected to each other
to build a chain of filters namely as filtergraphs. There are two types of filtergraphs that
can be identified by ffmpeg software. Those filtergraphs were distinguished in terms of
complexity as the first type is a simple filtergraph and the other one is a complex
filtergraph.

Figure 2.4(a): A simple encoder before considering filtergraph

A simple filtergraph is a chain of filters having one input and one output. From
figure 2.4(a), a simple filtergraph can be added to the diagram to illustrate the process of
encoding filtered frames. The fitergraph is added in between decoded frames and
encoded packets data to become figure 2.4 (b) as shown below:
 16

Figure 2.4(b): A simple encoder with a simple filtergraph

The filtration process can be described by the following simple filtergraph diagram in
Figure 2.5. Likewise, the figure 2.6 shows the complexity of Complex filtergraph.

Figure 2.5: Simple filtergraph block diagram

Figure 2.6: Complex filtergraph block diagram

 17

2.2 Hardware

The main focus that must be achieved in SDR technique is to construct the RF-
related works by using software dependence system. Eventually, there still a need of
hardware structure to ensure that digital signal processing must be done and to convert
the digital data into analogue form before it can be transmitted to the respected channel.
The Universal Software Radio Peripheral (USRP) type 1 will be used in this project as
the hardware platform. The chosen of USRP rather than USRP2 is because it is
significantly easier to be setup when compared to the USRP2 which will take longer time
since there is additional memory card needed in USRP2 that make them more powerful
compare to USRP. In order to provide MIMO (multiple inputs, multiple outputs)
systems, all sampling clocks and local oscillators must be in coherent. The advantage of
USRP and USRP2 is the hardware can apply both transmit and receive operation
simultaneously.

2.2.1 USRP

The main function of USRP 1 provides a hardware platform as well as to trigger

engineers to implement powerful software radio system at a faster duration. This
hardware can provide a low cost but flexible platform for engineers and designers to
develop more outstanding technologies in the future. USRP architecture includes a high
speed USB 2.0 interface, four high speed analog to digital converters, four high speeds
digital to analog converters, and a large Altera Cyclone field programmable gate array
(FPGA) that centrally connected all of the aforementioned devices as illustrated in figure
2.7 below [2]:
 18

Figure 2.7: USRP Architecture

Table 2.3: USRP and USRP 2 [13]

USRP USRP2
8 MHz instantaneous of RF bandwidth 25 MHz instantaneous of RF bandwidth
The radio can be accessible from one the radio to be accessible from more
computer than one computer
USB interface Gigabit Ethernet interfaces
Lowest cost Highest cost
Slower FPGA Faster FPGA
ADCs (12-bits 64 MS/s) ADCs (14-bits 100 MS/s)
ADCs (14-bits 128 MS/s) ADCs (16-bits 400 MS/s)
 19

2.2.2 Daughter board

There are 4 slots available on USRP motherboard for the daughter boards to be
mounted to give a fully integrated RF fronts-end. The daughter boards may divide into
several types depends on the frequency spectrum being used on certain application. The
maximum allocation for transmitter daughter board and receiver daughter boards are two
of each type in one time. The daughterboard itself contains a pair of high speed analog to
digital converter (ADC) for the receiver and a pair of digital to analog converter (DAC)
for the transmitter.

The daughter boards are divided into several types depending on their
applications either transmit, receive or both transmit and receive at one time. The
daughter board types can also be categorized based on their operating RF frequency such
as 400MHz, 900Mhz, 2.4Ghz and etc. Figure 2.8 below shows the details of several
popular types of daughter boards.
 20

Figure 2.8: Various type of USRP daughter boards [13]

2.2.3 ADC

The analog-to-digital converter is the bridge between the physical world of

continuous analog signals and the world of discrete digital samples manipulated by
software.ADC has the ability to convert the analog or continuous signal into digital or
discrete time signal. In SDR, the signal received from antenna was digitized at the
 21

receiver using high speed ADC. The ADC used in this USRP is four ADC with sampling
rate 64M symbol/s 12 bit ADC.

2.2.4 DAC

DAC functioned to convert the digital or discrete time signal into analog or
continuous signal. In SDR, before the signal being transmitted to antenna it was
converted from digital into analog at the transmitter path using high speed DAC. The
DAC used in this USRP is up to four DAC with sampling rate 128M symbol/s 14 bit
ADC.

2.2.5 Universal Serial Bus (USB) 2.0

Universal Serial Bus (USB) is the industry standard in the mid-1990s developed,
used cable assemblies, connectors and communication protocol on the bus for the
communication connection, and the power of computers and electronic devices. [3].

USB is designed to streamline connectivity peripherals such as keyboard, mouse,

digital camera and network card for personal computers, both for communication and
power supply. USB usage has become commonplace on other devices such as smart
phones, PDAs and game consoles. Ready USB interface effectively replaces many serial
and parallel ports, and provide separate power charger for mobile devices.
 22

2.2.6 Field Programmable Gate Array (FPGA)

Before users can start exploring the GNU Radio, they must first understand the
fundamental process in the FPGA. As can be seen from figure 2.9 below, all 4 ADCs and
4 DACs need to be connected to the FPGA simply to perform a high bandwidth signal,
but in order to connect to USB 2.0, it must reduce the bit rate.

Standard FPGA contains digital down converters (DDC) with cascaded integrated
comb (CIC) filter and also digital up converters (DUC). There are four DDCs in FPGA
which can be connected to whether 1, 2 or 4 RX channel in the eceiver path. Each of
these DDCs contain two inputs; I and Q that enables the ADCs in RX path to route either
in I or Q input of any DDCs and therefore enable multiple channels to be selected from
similar ADC [7].

Figure 2.9: The USRP board

 23

2.3 Software Defined Radio System

Software radio is a way of getting the code as close as possible to the antenna. In
the proposed SDR system, the software platform for SDR is GNU Radio which is a
software toolkit to develop and organize software radio. The hardware is the USRP
board.

2.3.1 GNU Radio

Figure 2.10: Basic SDR system based on USRP and GNU Radio[13]

Figure 2.10 illustrates how GNU Radio and USRP are both related to each
other. After the received signal is down-converted into baseband signal, the GNU
Radio takes over and plays its role to process the signal until it being modulated and
able to be played back
 24

2.3.2 SDR Architectural Limitations

Based on [19], there are several limitations need to be considered while dealing
with the SDR architecture. These limitations may impact some processes in the system
to be delayed or ineffective. The limitations are:

i. Bus delays:
Bus delay is a fixed delay occurs due to the bus transmission. It is relatively
easy to deal with by supporting the accurate scheduling. However, large
effects can occur to the spectrum of the delay and the carrier sensing.
Therefore, it will affected the related packets, and the fast recognition packets
because they need information that is time consuming for the implementation
of a number of tasks.

ii. Queuing delay:

Queuing delay may be smaller when compared to the bus delay, however, can
increase the queuing delay jitter in a system. This can provide difficulties for
scheduling up to the level of precision microseconds if not impossible.

iii. Stream-based architecture of SDRs:

Frontend which operates at sample streams can result in non functional fine-
grained radio control and access to physical layer information from the host.
This occurs because the stream samples increase the complexity to the
interaction between MAC layer that implements on host CPU and the radio
frontend. Thus made difficulties in combining control information on radio
information with a group of samples such as those who belonging to a
particular packet.
 25

2.4 Orthogonal Frequency Division Multiplexing (OFDM)

Orthogonal frequency division multiplexing (OFDM) is among popular

modulation technique that has widely used recently. By applying this modulation
technique, a wideband signal can be converted into multiple serial independent
narrowband signals [20]. The converted signals can overlap each other and placed side-
by-side in the frequency domain. The main goal of OFDM is to provide a multiple
number of n parallel data stream by translating an outgoing data into OFDM symbols.
There are several fundamental terms in OFDM symbols that need to be identified such as
subcarriers, occupied bandwidth, pilot carrier, cyclic prefix and etc. In OFDM
modulation, the allocated bandwidth is occupied by the total number of subcarrier
determine at the transmitter.

The implementation of OFDM is quite complex due to its synchronization

problem and this has recently scarce the applications of OFDM. However, the OFDM
modulation can alleviate the multipath fading problem as it transmit a low rate
narrowband signal with the equals throughput between all subcarriers. By referring to
802.11a standards, there are 4 pilot tones in total from all 52 designated subcarriers. The
main reason of creating pilot tones is to adjust the residual frequency so that the channel
estimation is more accurate.
 26

Figure 2.11: OFDM simulation flowchart

Figure 2.11 above shown OFDM simulation flowchart from a MATLAB

simulation code [5]. Firstly, the input data which is serial was converted into serial to
parallel converter to provide a certain numbers of parallel set data before the IFFT can be
performed. At each subcarrier, there are a set of data and all data in subcarrier were
arranged first in horizontal axis in frequency domain before they were transformed in
inverse fast Fourier transform (IFFT). The IFFT converts the data into its corresponding
time domain before they were converted into serial OFDM signal by sequentially produce
output from time domain samples. Likewise, the receiver part performs the splitting of
OFDM signal first and converted into parallel set of data in time domain. The data then
performed FFT function and last but not least the parallel data in frequency domain were
reconverted into serial stream to recover back the original data.

The channel allowed for noise effect testing, multipath test and also clipping. In
order to add noise effect, a pseudo-random data were added to the transmitted signal.
While in multipath test, some copies of data with attenuation and delayed were added to
the transmitted signal. Meanwhile, in clipping effect the amplifier saturation were varied.
 27

Figure 2.12: Simple OFDM block transmitter [18]

Based on [18], a simple OFDM transmitter as illustrated in figure 2.12 must

includes modulation or mapping, serial to parallel converter, IFFT and parallel to serial
blocks in the Digital Signal Processing blocks. Before a serial data can be converted into
parallel, the OFDM system must provide a function which modulates the encoded data to
the respected modulation scheme such as M-QPSK or M-QAM. The modulated data
then can be processed in DSP before the Digital to Analog Converter can process the
digital stream into analogue signal. The signals then being up converted and can be
transmitted wirelessly.

2.4.1 Cylic Prefix

In order to avoid delay spread in video transmission, a sort of signal can be added
at the beginning of the OFDM symbol as the Cyclic Prefix (CP). The use of CP can be
 28

either as guard interval of OFDM symbol or as the repetition of the OFDM symbol.
According to [10], the OFDM symbol should at least 5times of the guard bands.

2.5 Quadrature Amplitude Modulation (QAM)

In QAM, the constellation points are usually arranged using square grid so that
the vertical and horizontal spacing have equal distance from each point, although other
configurations might be possible such as cross-QAM. The number of constellation points
usually in power of two (e.g.: 2,4,8…) due to the digital properties which is in binary.
Since QAM is usually square, some of these are rare; the most common forms are 16-
QAM, 64-QAM and 256-QAM.

By increasing number of bit in constellation diagram, it is possible to transmit

more bits per symbol. However, if the mean energy of the constellation need to remain at
the same (by way of making a fair comparison) value, the constellation points must be
closer together and are thus more susceptible to noise and other corruption. As a result, as
QAM order increases in terms of order there is an increasing of error rate as well which
make themselves achieve a higher data rate transmission but with less reliably
performance than the lower order of QAM, for sake of constant mean constellation
energy. Figure 2.13 below shows the constellation diagram for 16-QAM.
 29

Figure 2.13: Digital 16-QAM with example constellation points.

 30

CHAPTER 3

METHODOLOGY

3.1 Methodology of Project

This project developed a video transmission in OFDM system via SDR technique
which concerned both software and hardware problems. This chapter discusses the
method and algorithms used in this project.

3.2 Hardware Setup

This project requires the use of hardware and software. Before it can be started,
users need to make sure all the hardware is sufficient and running in good condition. The
first hardware needed in this project is two units of PCs; the first one is used as
transmitter whiles the other one as receiver. However, users may only require using one
PC only which will acts as both transmitter and receiver at the same time. The PC must
 31

be installed with an operating system of Linux, either Fedora or Ubuntu OS versions. In

this project, Ubuntu 11.04 was installed on my PC, since the installation of Ubuntu is bit
simpler than other OS. Users need at least one set of USRP type 1 because it is low cost
and suitable for beginners. The USRP should include motherboard and needed daughter
board. This project utilizes a daughterboard with 2.4GHz operating frequency. Appendix
A shows the overview of the hardware setup by using 2PCs.

3.3 Software Setup

This section provides explanation on the installation of GNU radio to user‟s

operating system (OS). There are several ways of installing GNU radio depends on the
chosen OS, either Fedora or Ubuntu, while it is not necessarily limited to these OS only.
Appendix B discusses about the installation steps if the Fedora OS was chosen as the
open source platform. Otherwise, the Ubuntu users can follow the steps in section 3.3.1.

3.3.1 GNU radio installation for Ubuntu

The installation of GNU radio is easier for Ubuntu users because there is an
application named „Synaptic Package Manager‟ allows users to select the necessary
package to be downloaded and installed automatically. After Ubuntu is installed
successfully, user will found many applications on the Ubuntu menu bar such as terminal,
home folder, Ubuntu software centre and Synaptic Package Manager (SPM).
 32

By right click on the SPM on Ubuntu menu bar, the screenshot as shown in figure
3.1 will appears and allows users to search for the desired package.

Figure 3.1: Synaptic Package Manager Screenshot

After that, users only need to search for „gnu radio‟ in the search box before the
related package appears below the search box. The necessary package is then chosen and
applied for installation.

After few minutes (depends on the internet speed) the installation is completed
and ready to be used. By default, the gnuradio package is installed in path below:

usr/lib/python2.7/dist-packages/gnuradio
 33

The GNU radio also provides some examples as benchmark for new users to try.
The benchmark is saved automatically to the path:

usr/lib/python2.7/dist-packages/gnuradio

Users might also try to play with some python examples which have been already saved
at:

usr/share/gnuradio/examples/digital

3.4 System Design

This chapter explains in details the system design for transmitting a video using
OFDM system with SDR as the architecture. There are two important software need to
be configured in this project, which are gstreamer and GNU Radio Companion (GRC).
Gstreamer is powerful open source software enough to design the desired video
specification at the transmitter as well as to display the received video. On the other
hand, GRC is flexible software in handling RF signal of the video. The design is further
explained in section 3.4.1 to 3.4.4.
 34

3.4.1 Designing a simple digital video broadcasting

This section describes how to design a simple digital video transmission system
using GNU Radio, USRP and Ubuntu operating system. Those are the main components
needed to be prepared for the system:

i. Video Webcam
The webcam can either be built internally or externally connected to a PC. The
webcam is turned on or activated by inserting “v4l2src” command at the
beginning part of gstreamer.

ii. A Computer installed with GNU Radio and Gstreamer (the gstreamer can be
installed directly from Ubuntu software center)

iii. A USRP or USRP 2 (for this project, USRP with RFX 2.4Ghz daughter board is
being used).

USRP
Webcam

Figure 3.2: Simple Video transmission setup

 35

The hardware setup including a webcam and a USRP connected to the desktop as
shown in Figure 3.2. The webcam can either be externally or internally connected to the
desktop. The software setup is achieved on the desktop with Linux, either Fedora or
Ubuntu operating system is recommended.

3.4.2 Creating a pipeline

Pipeline creation is the most important step to provide the environment of real
time video transmission. Pipeline acts as a tunnel which connects between multimedia
files to GNU Radio. To create a pipeline, the user can apply the following commands:

mkfifo videotx.ts (for transmitter) and

mkfifo videorx.ts (for receiver)
 36

Figure 3.3: A transceiver system with pipeline connection

Figure 3.3 shown an OFDM transceiver with 2 Unix pipeline connected to the
gstreamer. In order to experience the real time video transmission, a pipeline linking
between gstreamer model and GNU Radio software must be created first and saves at any
path in the desktop. There are 2 Unix pipeline need to be created, which are videotx.ts
and videorx.ts for the transmitter and receiver respectively.

A video transmission begins when the camera at the transmitter is turned on. The
video is first compressed to desired size by reconfiguring it at the terminal using
gstreamer code before being encoded and multiplexed and write the output to the
pipeline. Section 3.4.3 discussed further about the operation of gstreamer.

In GRC blocks discussed in section 3.4.3, the file source block is to provide any
video source such as raw video, video files or pipe as the source. By choosing the
videotx pipeline as the source, the video from gstreamer that has been transmitted to the
 37

videotx pipeline, is the input of the OFDM system. The OFDM system that is configured
in GRC, produces baseband configuration, which is then transferred to be processed in
USRP.

The signal transmitted from Tx antenna on USRP is then received by the received
Rx antenna to be demodulated using OFDM demodulation. The output from the
demodulation is then sent to the videorx pipeline as the last station in GRC. The pipeline
must be read by gstreamer using the necessary code configured at the terminal, which is
discussed in section 3.4.3.

3.4.3 Gstreamer source coding

In [21], there are several ways of configuring gstreamer video. To transmit the
video using gstreamer and send it through the pipeline that has been created in section
3.4.2, the following command are used:

gst-launch -e v4l2src ! video/x-raw-yuv, framerate=10/1, width=320, height=240 !

ffmpegcolorspace ! x264enc bitrate=256 ! flutsmux ! filesink location=videotx.ts
 38

Figure 3.4: Gstreamer code at the transmitter terminal.

By implementing the previous commands as shown in figure 3.4, the video will
automatically send through the pipeline namely videotx. The pipeline will remain in the
pause condition as long as there is no further processing done to the pipeline.

The next step is to activate the pipeline using GNU radio source code, at this rate
the user need to create a reliable digital signal processing flow graph using GNU Radio
Companion (GRC). On top of that, users also can configure the source code by using
python programming and simulate it by using GNU radio. In this project, the uses of
GRC is more practical, since it can save time to reconfigure the RF options such as
modulation schemes, system bandwidth and etc.

On the receiver part, the reverse operation of the transmitter takes place. User
need to play the video by activating the videorx pipeline using the following commands:
 39

gst-launch -v playbin uri=file:/videorx.ts

Note that the file of videorx.ts is saved by default at Ubuntu home files. Despite
of using pair of encoder-mux such as “x264enc-flutsmux”, users can also try to replace it
with another pair such as “theoraenc-oggmux” or “ffenc_mpeg4-avimux”. The video
quality varies based on the encoder used at the transmitter.

3.4.4 GNU Radio Companion

To create signal flow graphs and generate flow-graph source code for the system
design, a GNU Radio Companion (GRC) software based on graphical user interface
(GUI) is used. It is currently still under development by Josh Blum, a member at Ettus
Research group. GNU Radio Companion (GRC) is used in this project due its simplicity
to reconfigure. Each GRC block is python based programmed and combined to a
dedicated xml file. The xml files may contain but not limited to their parameters, IO
ports and template to generate corresponding output. To ensure blocks compatibility for
the future, the id key and file name must match the GNU radio blocks modules.
Appendix B is an example of xml file for OFDM basic clock. The Figure 3.5
corresponds to the OFDM transceiver system flow graph that has been used in this
project.
 40

2 3

Figure 3.5: A basic OFDM transceiver flow graph

The OFDM modulation block is marked with number one and red circle is the
most important block to be configured. There are several parameters such as payload
length, FFT length and occupied tones that need to be configured by the user. The xml
file of the block is shown in Appendix C.

The number 2 and number 3 mark the generating and simulating tools in GRC.
The numbered 2 tool used to generates the Python code of the system in this project as
shown in Appendix D. After the Python code has been generated, user can now simulate
the system to get the output by clicking the tool as marked by number 3 in figure 3.5.
 41

3.4.5 Bitrate calculation

Table 3.1: The important formulas to calculate data rate

Parameters Formula
Subcarrier spacing, df BW/Nfft
OFDM subcarrier period, Tfft 1/df
Guard period, Tg (CP/Nfft) x Tfft
Tsymbol Tfft + Tg
Nsymbol 1/Tsymbol
Coded bit rate occupied tones x bits/subcarrier x Nsymbol
Data rate coded rate x encoder rate
Bandwidth capacity (Occupied tones/Nfft) x System bandwidth

In order to calculate the coded bit rate some parameters need to be set such as:
i) System bandwidth, BW = 1MHz
ii) Number of FFT bin = 64
iii) Number of occupied tones = 32
iv) Number of cyclic prefix =16
v) Encoder rate = 1/2 or 2/3

For the system specified as above, we can calculate some important parameters as
below:

• Df = 1M/64 = 15.625kb/s
• Tfft = 1/df = 64us
• Tg(25%) = (16/64)(64us)=16us
• Tsymbol = 80us
 42

• Nsymbol = 12500

Then, the coded bit rate is calculated depending on the modulation scheme being
used whether 16-QAM, 8-QAM or QPSK:

i) For 16-QAM
CR = 32x4x12500 = 1.6Mb/s
DR = 6.4 Mb/s x ½ = 0.8Mb/s

ii) For 8-QAM

CR = 32x3x12500 = 1.2Mb/s
DR = 6.4 Mb/s x ½ = 0.6Mb/s

iii) For QPSK

CR = 32x2x12500 = 0.8Mb/s
DR = 6.4 Mb/s x ½ = 400kb/s

iv) For BPSK

CR = 32x1x12500 = 400kb/s
DR = 6.4 Mb/s x ½ = 200kb/s

The OFDM capacity can simply be calculated by using the formula of bandwidth
capacity as shown in table 3.1 as:

BW= (32/64)x1MHz= 500MHz

 43

Table 3.2: Calculated data rate for experiment 4.2.1

Number of occupied subcarriers (FFT=128)

32 48 64 80
Data Rate, DR
400 600 800 1000
(kbps)

Table 3.3: Calculated data rate for experiment 4.2.2

Modulation scheme (FFT=128)
16-QAM QPSK BPSK
Data Rate, DR
800 400 200
(kbps)

Table 3.4: Calculated data rate for experiment 4.2.3

Number of payload length (kb)
128 256 512 1024 2048
Data Rate, DR
800 800 800 800 800
(kbps)

Table 3.5: Calculated data rate for experiment 4.3.1

Number of (occupied subcarriers/FFT length)
32/64 64/128 128/256 256/512
Data Rate,DR
800 800 800 800
(kbps)
 44

3.5 Summary

As a conclusion, the overall OFDM system applied in this project is done by

using GRC software as shown in Figure 3.5. In order to implement a real-time video
transmission Unix pipeline need to be first created at the Ubuntu terminal. Then the users
need to define the video decoder and basic parameters using gstreamer commands in the
terminal. The overall project steps are summarized in the flowchart as in sub section
3.5.1 for transmitter and sub section 3.5.2 for the receiver.
 45

3.5.1 Transmitter flow chart

User interface

 Turn ON webcam

Terminal

 Choose appropriate video encoder and

multiplexer, video size, frame rate and
compression size

GNU Radio

 Defined the DSP need to be done by the FPGA

(modulation type, IFFT bin, desired IF and RF
frequency)

USRP

 FPGA done the DSP

 The digital data converted to analog
 Daughterboard process the RF signal before it
transmitted to
 antenna

Figure 3.6: Transmitter flow-chart

 46

3.5.2 Receive Flow Chart

GNU Radio
 Defined the DSP need to be done by the FPGA
(demodulation type, FFT bin, desired IF and RF
frequency)

USRP
 Daughterboard process the RF signal before it
transmitted to antenna
 The digital data converted to analog
 FPGA done the DSP

Terminal
 Choose appropriate video decoder and demux

User interface
 Display the received video

Figure 3.7: Receiver flow-chart

 47

CHAPTER 4

RESULT & ANALYSIS

4.1 Introduction

Some experiments have been conducted using one USRP and one laptop as
transceiver. The results for those experiments will be further discussed in this chapter as
well as the preliminary and main parts of this chapter. In preliminary part, the conducted
experiments were more focus on transmitting and receiving video using OFDM
modulation while in main part, the quality of the video will be discussed based on Bit
Error Rate (BER) as well as the Symbol Error Rate (SER).
 48

4.2 Preliminary Experiments

The main objective in the preliminary works is to get an acceptable QoS video at
the receiver side. As the main modulation mapping used in this project is to use M-QAM
modulation, therefore several experiments has been conducted by varying the necessary
variables purposely to observe the best quality of received video.

4.2.1 Study on the effect of FFT length

It is known that we can transmit video signal by using OFDM modulation due to
its high bit rate transmission advantage. However, to adapt with low bandwidth
limitation in USRP, some variable might need to be set in suitable value to achieve
acceptable quality of service. In order to observe the ability to display the video on
receiver side, the numbers of subcarriers were varied from 32 to 80 while some other
variables such as FFT length and cyclic prefix were fixed to a certain value as below:

i) Gstreamer:
-frame rate: 10fps and
- bitrate compression:256kbps

ii) GRC:
-modulation:16-QAM
- FFT length:128
-occupied tones/subcarriers: varied
-cyclic prefixes: 32
 49

The achieved bit rate for every configuration was calculated and their average is
tabulated in table 4.1 below.

Table 4.1: The achievable bit rate of various occupied subcarriers for 128 FFT length
Number of occupied subcarriers
32 48 64 80
Average Bit rate
46.9 97.8 130.4 177.2
(kbps)
Max bandwidth
250 375 500 625
(kHz)
% of achieved
18.76 26.08 26.08 28.35
bitrate

Figure 4.1: Percentage of achievable bit rate for various subcarriers

 50

Figure 4.2: Snapshot of transmitted video

Table 4.2(a): The video snapshot of 32 occupied subcarriers for 128 FFT length
Occupied Subcarrier Video Snapshot

32
 51

Table 4.2(b): The video snapshot of various occupied subcarriers in 128 FFT length
Occupied Subcarrier Video Snapshot

48

64

80
 52

Table 4.1 reveals that the achievable system bit rate can be increased by
increasing the occupied subcarriers in the OFDM system. As a result, the percentage of
bit rate achieved for their respective maximum bandwidth was increased as well as
illustrated in figure 4.1. As a conclusion, 80 subcarriers is the best configuration among
these four subcarriers as it can achieve more than 28% of bandwidth usage.

Table 4.2(a) and 4.2(b) is the received video snapshot for several configurations
of subcarriers as studied in this experiment whereas the transmitted video snapshot shown
in figure 4.2. Based on the results in figure 4.1 and table 4.2 (a) and (b), it can be
concluded that the more the bitrate achieved by the system, the better the quality of
receivable video as the good QoS required the maximum throughput of the system
 53

4.2.2 Study on the effect of modulation scheme.

Basically, there are only two types of modulation provided in GNU Radio
Companion (GRC) 3.2.2 which are Phase Shift Keying (PSK) and Quadrature Amplitude
Modulation (QAM). This experiment was conducted to compare on video ability while
using 16-QAM modulation scheme to other scheme such as QPSK and BPSK. All of
these schemes were possible to be used in OFDM but, this experiment is to determine the
best modulation to adapt with USRP environment.

In this experiment, the modulation schemes are varied and the following value is fixed:

iii) Gstreamer:
-frame rate: 10fps and
- bitrate compression:256kbps

iv) GRC:
-modulation:16-QAM
- FFT length:128
-50% occupied tones/bandwidths
-25% cyclic prefixes
 54

Figure 4.3: Snapshot of transmitted video through OFDM system.

Table 4.3(a): The received video snapshot for 1 modulation bit

Modulation type (no. of
Video Snapshot
modulation bits)

BPSK (1 bit)
 55

Table 4.3(b): The received video snapshot for 2,3 and 4 modulation bit

QPSK (2 bit)

8-QAM (3 bit)

16-QAM (4 bit)
 56

Table 4.4: Effect of modulation scheme to the delay

Time taken to display received video for several modulation scheme
Attempts (seconds)
16-QAM QPSK BPSK
Ave delay (s) 59.3 31.32 11.06

Based on Table 2 above, it is shown that the best way to transmit a video by using
USRP is by using BPSK modulation scheme. Although, it was possible to transmit using
16-QAM modulation, it is verified that using a lower transmission rate such as BPSK is
more reliable as the daughter board allows limited data rate of 256kb/s. Lower bit rate
experience lower probability of bit error rate. 16-QAM using 4bits/FFT subcarrier
provides high bit rate which is not suitable enough for smaller sampling rate of DAC and
ADC in USRP.

As calculated in part 3.4.5, and tabulated in table 3.3 bit rate for 16-QAM system
with 50% occupied bandwidth and 25% of CP, the data rate is 800kbps, while 400kbps
and 200kbps for QPSK and BPSK respectively. However, the video is compressed to
256kb/s and thus, the BPSK with bit rate of 200kb/s is the most suitable modulation
scheme to adapt with 256kb/s channel bandwidth.
 57

4.2.3 Study on the effect of payload length to the video quality.

One of the reasons of why a video cannot be displayed is because there is too
much packet lost during transmission. The number of packet transmitted can be reduced
by increasing the payload length. In this experiment, the QoS on the displayed video is
studied by manipulating the payload length from 128 to 2048 kbit/packet at the
transmitter and the following value is fixed:

i) Gstreamer:
-frame rate: 10fps and
- bitrate compression:256kbps

ii) GRC:
-modulation:16-QAM
- FFT length:128
-50% occupied tones/bandwidths
-25% cyclic prefixes

Figure 4.4: Snapshot of transmitted video through

OFDM system for experiment 4.2.3
 58

Table 4.5(a): Video Screenshot for different payload length

Payload Length Displayed Video

128

256

512
 59

Table 4.5(a): Video Screenshot for different payload length

Payload Length Displayed Video

1024

2048
 60

Table 4.6: Effect of Payload Length to the video bitrate

Payload Length
128 256 512 1024 2048
Average bitrate 125.1 147.6 151.4 187.5 188.5
(kbps)
Max. bandwidth 625 625 625 625 625
(kHz)
% of achieved bit 20.02 23.62 24.22 30 30.16
rate

% of achievable bit rate

35

30

25

20

15

10

0
128 256 512 1024 2048
% of achievable bit rate 20.02 23.62 24.22 30 30.16

Figure 4.5: Percentage of achievable bit rate for various payload length
 61

From table 4.5, it can be concluded that, the percentage of achievable bit rate is
significantly increased while increasing the Payload Length from 128 to 2048. However,
there is not much different while increasing the payload length from 256 to 512 and from
1024 to 2048. Consequently, the video quality was improved as the Payload Length
increases as shown in the table 4.5(a) and 4.5 (b). However, the maximum payload
length allowable by GRC is 4096 and the increases of payload length to a higher value
might cause the video failed to be displayed.
 62

4.3 Main Experiments

In previous experiments, we have verified that some suitable configuration can be

set in order to achieve an acceptable QoS of video at the receiver. By using these
configurations, several experiments have been conducted in order to achieve the lowest
bit rate and also good quality of video on the receiver part by varying modulation scheme
which is M-QAM.

4.3.1 Investigation on the effect of BER for different FFT bin

BER is a common way to measure on how much error occurs when signals
received. A good system should have very minimum number of BER counts even though
a zero BER is nearly impossible for a system to be designed. FFT bin will provide the
desired narrowband for a single subcarrier, the higher the FFT bin, the narrower the
subcarrier signals. The following value must be configured before transmit the video:

i) Gstreamer:
- frame rate: 10fps and
- bitrate compression:256kbps

ii) GRC:
- modulation:16-QAM
- FFT length: variable
 63

Figure 4.6: The BER counts for different size of FFT and samples size

Figure 4.6 above shows the BER counted at the receiver while using 16-QAM
modulation schemes. As can be seen, the BER is significantly large for all sizes of FFT
since there is no synchronization that has been made in this project. By using 5000
samples, the BER is slightly decreased when the number of FFT length increases.
However, as the samples data increase to 10000, the BER is significantly improved as the
FFT size increases from 128 to 256 and from 256 to 512 FFT size. As a conclusion, the
error rate can be reduced as the number of subcarrier increases.
 64

CHAPTER 5

CONCLUSION

5.1 Conclusion

By utilizing GNU Radio Companion (GRC) Software, an OFDM system has been
built for purpose of video transmission. At the transmitter part, a pipeline namely
„videotx‟ has been created first to enable streaming application likewise a „videorx‟
pipeline on the receiver part to enable streaming on the receiver. The video must be
configured first at the transmitter to ensure a low rate video transmission by set up the
suitable encoder, multiplexer, frame rate, compression rate and specified the pipeline
location where it wants to be transmitted. A bandwidth of 1 MHz was set at the USRP as
the hardware platform in which the digital signals were processed before it can be
transmitted through real antenna. There are many flexible configurations which can be
set by the user to meets their needs. At the terminal, user can reconfigure the video
which they want to transmit for example users can add time overlay to enhance the time
management if necessary besides choosing appropriate pair of encoder and multiplexer.
Most of the video signals were encoded using commands „ffenc_mpeg‟ and „avimux‟ as
encoder and multiplexer respectively because it is lossy type of encoder which suitable to
 65

do the experiments. However, there are other pairs such as „theoraenc & oggmux‟ and
„x264enc & flutsmux‟ that can replace the encoder & muxer pair as long as the software
library has been downloaded in Linux.

The flexibility of this project was not only limited in terminal but also in the
software platform in SDR which is GNU Radio. The modulation schemes are among the
popular part in GNU Radio where a user might want to reconfigure especially for the
researchers besides the channel frequency, system bandwidth, signals filter and etc.

In conclusion, a video transmission system which based on OFDM modulation

has been developed in this project even though a lot of improvement still can be done.
The received video also can be analyzed at the receiver especially in terms of video QoS,
bit rate and error rate. For the best performance in low rate video transmission, FFT
signals of 128 with 64 or 50% occupied tones and 32 or 25% of CP length has been
proposed. On top of that, a large size of payload length such as 1024 or 2048 and the
lowest modulation bit such as BPSK is preferred to give a best video quality. For a
higher bit rate transmission, USRP 2 is preferably to be used as its can cover up to
20MHz of data transmission.

1.2 Suggestions/Recommendation

This section might be useful for further study of OFDM or if someone wants to
make project related to this topic or to improve this project.
 66

1.2.1 Python

A strong foundation of python or any basic programming should be learned first

as to ensure a good understanding on GNU Radio or GRC. This is necessary because
users might want to make adjustment for troubleshooting purpose. A byte of python is
one of good website which provides some notes regarding python language.

1.2.2 Synchronization

One of the crucial problems occurs in OFDM system is regarding

synchronization. Once the orthogonality of this system fail to be maintained it may
caused lot of errors and video might fail to be display as well due to uncontrollable
packet losses.

1.2.3 Protocol

There are some protocols can be added to the USRP such as Wireless Sensor
Network (WSN) for low rate transmission and Wireless Local Area Network (WLAN)
for higher data rate transmission. The setup guidance for both of these protocols has been
discussed in more details in [13].
 67

REFERENCES

1. Bruce A. Fette, et al, (2006)”Cognitive Radio Technology” Newnes, , page 656,

ISBN-10: 0750679522, ISBN-13: 978-0750679527.
F
2. Ettus Research LLC, web page ” www.ettus.com”, visited 2011-12-27

3. "Boston Globe Online / Business / USB deserves more support". Simson.net.

1995-12-31. Retrieved 2011-12-12.

4. GNU Radio, web page” www.gnuradio.org “, visited 2011-12-28

5. Alan C. Brooks, Stephen J. Hoelzer. Design and Implementation of Orthogonal

Frequency Division Multiplexing (OFDM) Signaling.

6. “http://en.wikipedia.org/wiki/Quadrature_amplitude_modulation”,visited 2011-
12-28

7. Dawei Shen (2005), Tutorial 4: The USRP Board, August 8, 2005

8. Dawei Shen(2005), Tutorial 1: GNU Radio Installation Guide - Step by Step, May
19, 2005
 68

9. GNU Radio on-line document: How to Build from CVS,

http://comsec.com/wiki?HowtoBuildFromCVS

10. Muhammad Nasir Bin Othman (2011). Cyclic Prefix Design For Orthogonal
Frequency Division Multiplexing (OFDM) Using FPGA.

11. Joseph Wamicha,Simon Winberg (2011), IEEE 802.11 OFDM Software Defined
Radio Beacon Frame Transmission.

12. Mohamed Syahrezal bin Kudus (2010). Video Transmission Via Software Defined
Radio. Universiti Teknologi Malaysia.

13. Alalelddin Muhamed (2010). Studying Media Access and Control Protocols.
Sweden.

14. Chao Chen, Robert W. Heath Jr., Alan C. Bovik And Gustavo De Veciana
(2011),” Adaptive Policies For Real-Time Video Transmission: A Markov
Decision Process Framework”,

15. Nur Saffiyah bt Mohd Suhaimi (2010). Audio Data Transmission Using Software
Defined Radio. Universiti Teknologi Malaysia

16. http://en.wikipedia.org/wiki/FFmpeg, retrieved 2012-06-14,

17. http://en.wikipedia.org/wiki/Color_space, retrieved 2012-06-17,

18. Hen-Geul Yeh, Paul Ingerson (2010), Software-Defined Radio for OFDM
Transceivers,

19. Dipankar R, Mario G, Emerging Wireless Technologies and the Future Mobile
Internet, Cambridge Books Online, page 185-186
 69

20. Gavin Y., Mineo T. and Rajive B. (2005), Effects of Detailed OFDM Modeling in
Network Simulation, Society for Modeling and Simulation International (SCS)

21. Gstreamer Cheat Sheat,

wiki.oz9aec.net/index.php/Gstreamer_cheat_sheet, retrieved June 28,2012

22. Simple DVB with Gstreamer and GNU,

Radiohttp://wiki.oz9aec.net/index.php/Simple_DVB_with_Gstreamer_and_GNU
_Radio, retrieved on June 28,2012

23. Ffmpeg documentation,

http://ffmpeg.org/ffmpeg.html#Encoders, retrieved June 28,2012

24. Aspect ratio, http://www.equasys.de/aspectratio.html, retrieved July 2012

 70

APPENDIX A

Figure 7: Experimental Setup

 71

APPENDIX B

GNU RADIO INSTALLATION GUIDE

1. Downloading necessary packages or tarballs

First of all, USRP users need to download and install necessary packages as
presented in table below:

gnuradio-core (*) the 2.x core library

gnuradio-examples
gr-audio-oss (*)
gr-audio-alsa (*)
gr-usrp (*)
gr-wxgui (*) wxPython based GUI tools including FFT and
gr-howto-write-a-
block examples,
gr-gsm-fr-vocoder
usrp (*)
examples for the 2.x tree
soundcard support using OSS
soundcard support using ALSA
glue that connects usrp into GNU Radio
framework
o‟scope
Makefiles and article source
GSM 06.10 13kbit/sec vocoder
USRP board support

All of these modules must be installed first especially the modules with (*) mark
because those were important components. The modules can be downloaded from GNU
 72

Radio‟s website and the new version of these modules can be checked and downloaded
using following commands:
$export CVS_RSH="ssh"
$cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/gnuradio co -P <modulename>

The USRP CVS tree is hosted on SourceForge. Use these commands to check the usrp
module out:

$cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/opensdr login

$cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/opensdr co -P usrp

Then a directory with the module name will appear in your current folder. Every time you
should

run ./bootstrap first to generate the configuration and make files.

2. Installing gnuradio-core
This step will requires many pre-installed packages and is the very important
step/module. In order to avoid further trouble, the development tools and the X-window
development tools must be checked during Linux and GNU installation. These are 3
important packages that often found to be missing and necessary to be installed:

1. FFTW
Webpage: http://www.fftw.org/
Download page: http://www.fftw.org/download.html

2. cppunit
Webpage: http://cppunit.sourceforge.net
Download page: https://sourceforge.net/project/showfiles.php?group id=11795

3. SWIG
 73

Webpage: http://www.swig.org
Download page: http://sourceforge.net/projects/swig/

The following steps will install the gnuradio-core. Users must ensure that the following
commands were install in gnuradio-core folder downloaded from CVS in step 3.3.1:
2. $ ./bootstrap
3. $ ./configure --enable-maintainer-mode
4. $ make
5. $ make check
6. $ make install

3. Installing gr-audio-oss, gr-audio-alsa

These are two important modules which provide access to our sound card. The
commands „./bootstrap‟ need to run first to ensure configuration has been generated and
also to make a specific files.

4. Installing of gr-wxgui

Webpage: http://www.wxPython.org/
Download page: https://sourceforge.net/project/showfiles.php?group id=10718

To enable the graphical user interface (GUI) such as FFT graph and oscilloscope
function in GNU Radio, there is a need to install gr-wxgui and it is based on wxPython.
Therefore, the installation of wxPhyton should come first.

5. Installing of usrp and gr-usrp

Webpage: http://sdcc.sourceforge.net/
Download page: http://sourceforge.net/project/showfiles.php?group id=599
The above link is to download SDCC free C compiler. SDCC is important to
build the firmware interfaces for GNU Radio‟s use.
 74

6. Installing of gnuradio-examples, gr-howto-write-a-block and gr-gsm-fr-

vocoder
The three packages above is just additional recommended packages need to be
installed in this project.
The failure of these modules installation will not certainly affect the GNU Radio.

7. Post-installation tasks
After the steps in 3.3.1-3.3.6 done, users may want to open the files. The installed
file will be by default save in:

/usr/local/lib/python2.3/site-packages (if python 2.3 is used)

 75

APPENDIX C

XML CODE FOR OFDM MODULATION USING GRC

<?xml version="1.0"?>
<!--
###################################################
##OFDM Mod
###################################################
-->
<block>
<name>OFDM Mod</name>
<key>blks2_ofdm_mod</key>
<import>from grc_gnuradio import blks2 as grc_blks2</import>
<import>from gnuradio import blks2</import>
<make>grc_blks2.packet_mod_$(type.fcn)(blks2.ofdm_mod(
options=grc_blks2.options(
modulation="$modulation",
fft_length=$fft_length,
occupied_tones=$occupied_tones,
cp_length=$cp_length,
pad_for_usrp=$pad_for_usrp,
log=None,
verbose=None,
),
),
payload_length=$payload_length,
)</make>
<param>
<name>Input Type</name>
<key>type</key>
<value>float</value>
<type>enum</type>
<option>
<name>Complex</name>
<key>complex</key>
<opt>fcn:c</opt>
</option>
 76

<option>
<name>Float</name>
<key>float</key>
<opt>fcn:f</opt>
</option>
<option>
<name>Int</name>
<key>int</key>
<opt>fcn:i</opt>
</option>
<option>
<name>Short</name>
<key>short</key>
<opt>fcn:s</opt>
</option>
<option>
<name>Byte</name>
<key>byte</key>
<opt>fcn:b</opt>
</option>
</param>
<param>
<name>Modulation</name>
<key>modulation</key>
<type>enum</type>
<option>
<name>BPSK</name>
<key>bpsk</key>
</option>
<option>
<name>QPSK</name>
<key>qpsk</key>
</option>
<option>
<name>8PSK</name>
<key>8psk</key>
</option>
<option>
<name>QAM8</name>
<key>qam8</key>
</option>
<option>
<name>QAM16</name>
<key>qam16</key>
</option>
<option>
 77

<name>QAM64</name>
<key>qam64</key>
</option>
<option>
<name>QAM256</name>
<key>qam256</key>
</option>
</param>
<param>
<name>FFT Length</name>
<key>fft_length</key>
<value>512</value>
<type>int</type>
</param>
<param>
<name>Occupied Tones</name>
<key>occupied_tones</key>
<value>200</value>
<type>int</type>
</param>
<param>
<name>Cyclic Prefix Length</name>
<key>cp_length</key>
<value>128</value>
<type>int</type>
</param>
<param>
<name>Pad for USRP</name>
<key>pad_for_usrp</key>
<type>enum</type>
<option>
<name>Yes</name>
<key>True</key>
</option>
<option>
<name>No</name>
<key>False</key>
</option>
</param>
<param>
<name>Payload Length</name>
<key>payload_length</key>
<value>0</value>
<type>int</type>
</param>
<sink>
 78

<name>in</name>
<type>$type</type>
</sink>
<source>
<name>out</name>
<type>complex</type>
</source>
<doc>Payload Length: 0 for automatic.</doc>
</block>
 79

APPENDIX D

PYTHON SOURCE CODE

#!/usr/bin/env python
##################################################
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Fri Jun 29 14:06:51 2012
##################################################

from gnuradio import blks2

from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.wxgui import scopesink2
from grc_gnuradio import blks2 as grc_blks2
from grc_gnuradio import usrp as grc_usrp
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx

class top_block(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="Top Block")

##################################################
# Variables
##################################################
self.samp_rate = samp_rate = 2000000

##################################################
# Blocks
##################################################
self.blks2_ofdm_demod_0 =
grc_blks2.packet_demod_b(blks2.ofdm_demod(
options=grc_blks2.options(
modulation="qam16",
fft_length=128,
occupied_tones=64,
 80

cp_length=32,
snr=15,
log=None,
verbose=None,
),
callback=lambda ok, payload:
self.blks2_ofdm_demod_0.recv_pkt(ok, payload),
),
)
self.blks2_ofdm_mod_0 = grc_blks2.packet_mod_b(blks2.ofdm_mod(
options=grc_blks2.options(
modulation="qam16",
fft_length=128,
occupied_tones=64,
cp_length=32,
pad_for_usrp=True,
log=None,
verbose=None,
),
),
payload_length=64,
)
self.gr_file_sink_0 = gr.file_sink(gr.sizeof_char*1,
"/home/ubuntu/videorx")
self.gr_file_source_0 = gr.file_source(gr.sizeof_char*1,
"/home/ubuntu/videotx", True)
self.gr_multiply_const_vxx_0 = gr.multiply_const_vcc((5000, ))
self.gr_throttle_0 = gr.throttle(gr.sizeof_gr_complex*1, samp_rate)
self.usrp_simple_sink_x_0 = grc_usrp.simple_sink_c(which=0, side="A")
self.usrp_simple_sink_x_0.set_interp_rate(128)
self.usrp_simple_sink_x_0.set_frequency(2400000000, verbose=True)
self.usrp_simple_sink_x_0.set_gain(0)
self.usrp_simple_sink_x_0.set_enable(True)
self.usrp_simple_sink_x_0.set_auto_tr(True)
self.usrp_simple_source_x_0 = grc_usrp.simple_source_c(which=0,
side="A", rx_ant="TX/RX")
self.usrp_simple_source_x_0.set_decim_rate(64)
self.usrp_simple_source_x_0.set_frequency(2400000000, verbose=True)
self.usrp_simple_source_x_0.set_gain(15)
self.wxgui_scopesink2_0 = scopesink2.scope_sink_c(
self.GetWin(),
title="Scope Plot",
sample_rate=samp_rate,
v_scale=0,
t_scale=0,
ac_couple=False,
 81

xy_mode=False,
num_inputs=1,
)
self.Add(self.wxgui_scopesink2_0.win)

##################################################
# Connections
##################################################
self.connect((self.blks2_ofdm_demod_0, 0), (self.gr_file_sink_0, 0))
self.connect((self.gr_file_source_0, 0), (self.blks2_ofdm_mod_0, 0))
self.connect((self.usrp_simple_source_x_0, 0),
(self.blks2_ofdm_demod_0, 0))
self.connect((self.blks2_ofdm_mod_0, 0), (self.gr_multiply_const_vxx_0,
0))
self.connect((self.gr_multiply_const_vxx_0, 0), (self.gr_throttle_0, 0))
self.connect((self.gr_throttle_0, 0), (self.usrp_simple_sink_x_0, 0))
self.connect((self.usrp_simple_source_x_0, 0), (self.wxgui_scopesink2_0,
0))

def set_samp_rate(self, samp_rate):

self.samp_rate = samp_rate
self.wxgui_scopesink2_0.set_sample_rate(self.samp_rate)

if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = top_block()
tb.Run(True)