ECE 496Y Project Proposal (Draft B) Meeting Form - Images Festival

ECE 496Y Project Proposal (Draft B) Meeting Form *Session Code (e.g. GT4): H 1430
[* fill in before submitting report]
Project No:2008323 Supervisor(s):Prof. Sean V. Hum * Meeting Date & Time: October 1, 2008; 4:30 PM
Project Title: Software Defined Radio
ECC Staff:

The Edward S. Rogers Sr. Department of
Electrical and Computer Engineering
University of Toronto
ECE496Y Design Project Course
Group Project Proposal (Draft B)
Title: Software Defined Radio
Project I.D.#: 2008323
Team members:
Name:
Email:
(Select one member to
be the main contact.
Alp Kucukelbir 994422629
alp.kucukelbir@utoronto.ca
Mark with ‘*’) *Rajat Mark Grover 995705241 mark.grover@utoronto.ca
Tyler de Witt 990759292
tyler.dewitt@utoronto.ca
Supervisor:
Prof. Sean V. Hum
Section #: 5
Course Administrator: Prof. Hamid Timorabadi
Date: September 25, 2008

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
Executive Summary
The Software Defined Radio (SDR) movement aims to bring reconfigurable, adaptive solutions
to an otherwise hardware-dominated, rigid world of communications. SDR transmitters
and receivers have attracted much interest from professional and amateur organizations,
thereby encouraging a strong development. Most amateur implementations
of SDR systems are based on a Personal Computer and low-cost radio frequency (RF)
equipment. Our goal is to design and build a stand-alone SDR receiver capable of receiving
a variety of RF signals using different modulation schemes. Various other alternate
designs are considered within, and contrasted to our own. A preliminary feasibility and
risk analysis is also conducted, aiming to elucidate any potential problems in the early
stage of development. Also included is a work breakdown structure and a Gantt chart.
Finally, a financial plan is presented for budgeting purposes.
ECE496 Page 1 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
Contents
1 Project Description 3
1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Project Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Project Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Validation and Acceptance Tests . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Validation Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Acceptance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Technical Design 8
2.1 Possible Solutions and Design Alternatives . . . . . . . . . . . . . . . . . . . 8
2.1.1 Alternative A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Alternative B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Alternative C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Work Plan 10
3.1 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Financial Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Contingency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Feasibility Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1 Skills and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2 Required Equpiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
ECE496 Page 2 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
1 Project Description
1.1 Background and Motivation
What is Software Defined Radio?
Simply put Software Defined Radio is defined as: “Radio in which some or all of the
physical layer functions are software defined. A radio is any kind of device that wirelessly
transmits or receives signals in the radio frequency (RF) part of the electromagnetic
spectrum to facilitate the transfer of information. In today’s world, radios exist in a multitude
of items such as cell phones, computers, car door openers, vehicles, and televisions.”
— from SDRforum.org.
What is the benefit of a SDR receiver?
“A SDR receiver would allow provide end-users with access to ubiquitous wireless communications
– enabling them to communicate with whomever they need, whenever they
need to and in whatever manner is appropriate.” — from SDRforum.org.
Other benefits include:
1. Upgradeability – a new modulation scheme can be implemented and downloaded to
the receiver.
2. Adaptability/Versatility – a single device that can operate on a large spectrum through
narrowband and/or wideband operation without the need for specific/costly hardware.
ECE496 Page 3 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
Who are the stakeholders and how does SDR benefit them?
1. Radio equipment developers/manufacturers
• Creation of “lateral” layers of portability will greatly reduce development across
multiple “radio products” – e.g. same modulation scheme, different frequency
band or different platform
2. Radio service/network providers
• Reduction in operational costs and upgradability within radio networks. Less
hardware based major investments and more flexible, “future-looking” approaches
in day-to-day implementations
3. The end-user of a SDR system
• Communication in whatever method/manner is best suitable, and compatibility
with legacy standards – all in one
4. Governments, Public safety alliances and frequency allocation organizations
• Potential free-up of frequency bands, and allocation of wide-band “free-space”
for frequency sensitive applications
Where are the applications of SDR?
1. Immediate applications include: Military Joint Tactical Radio Systems (JTRS), and
amateur short-wave radio systems.
2. Goals include: commercial radio systems (radio/cellular/wireless ad-hoc networks),
frequency sensitive platforms.
ECE496 Page 4 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
Why is Team Phoenix motivated?
1. We are motivated to develop a standalone software defined radio, to demonstrate
the practicality and adaptability of software-reconfigurable systems emerging in
communications. We are inspired by the idea of “Plug-and-Play” practicality in
complex communication systems.
1.2 Project Goal
This project aims to develop a general purpose, reconfigurable standalone SDR platform.
Electronically, the device shall change function to demodulate arbitrary RF signals received
from a selectable spectrum. The device is meant to be a portable, general purpose
tool to act effectively as a ‘swiss-army knife’ radio receiver. To demonstrate reconfigurability,
at least 2 different demodulation schemes shall be implemented for the platform.
1.3 Project Requirements
1.3.1 Functional Requirements
RECONFIGURABILITY:
• The device shall demodulate at least two modulation schemes using software signal
processing techniques. Specifically the following shall be demonstrated:
1. Reception, demodulation, and output of commercial FM broadcasts.
2. Reception, and display of text messages transmitted using digital modulation
via a test RF transmitter.
ECE496 Page 5 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
PORTABILITY:
• The device shall be small and light enough for a single person to carry, setup, and
operate in a remote location in less than 10 minutes.
1.3.2 Objectives
RECONFIGURABILITY:
• The device shall apply arbitrary demodulation schemes to carrier waves selectable
over a wide electromagnetic spectrum.
PORTABILITY:
• The device shall be made to be as small and light as possible.
1.3.3 Constraints
• The receiver shall be smaller than 50 × 50 × 30 cm 3 .
• The receiver shall not weigh more than 4 kilograms
• The receiver shall not cost Team Phoenix more than $1500 CAD.
1.4 Validation and Acceptance Tests
1.4.1 Validation Tests
RECONFIGURABILITY:
Resources Needed: Receiver and two RF signals modulated differently in schemes supported
by the receiver.
Testing Procedure: Configure the receiver to receive each signal one at a time.
ECE496 Page 6 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
Verification Procedure: Analyze and compare the output to the expected output (a perceivable
signal in case of an audio output, a decipherable message on the screen in
case of a text output).
Acceptance Level: Test passes if the audio signal is perceivable as the sent signal and if
the text output is the same as the message sent.
PORTABILITY:
Resources Needed: Pre-programmed receiver and a source of power.
Testing Procedure: Individual carries receiver to a different location and set it up.
Verification Procedure: Analyze the receiver output and note the time taken for setup.
Acceptance Level: Test passes if the receiver can receive the output to a perceivable extent
and the project was setup in 10 minutes or less.
1.4.2 Acceptance Tests
GENERAL PURPOSE RECONFIGURABLE PLATFORM
Resources Needed: Receiver and an arbitrarily modulated RF signal.
Testing Procedure: Program the receiver to demodulate the new (arbitrary) modulation
scheme. Ensure correct spectral selection on both receiver and transmitter.
Verification Procedure: Analyze the output and compare to desired output.
Acceptance Level: Test passes if the receiver output matches the expected out, fails otherwise.
ECE496 Page 7 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
2 Technical Design
2.1 Possible Solutions and Design Alternatives
The software radio will consist of three stages:
1. Radio frequency stage to receive and amplify radio signals
2. AD converter stage to convert radio signals to digital data
3. Digital processing stage for demodulating signals
The following solutions deal with the design alternatives for the three stages and methods
of interfacing them. For each solution, we list pros and cons of each combination with
reference to design parameters.
2.1.1 Alternative A – General purpose PC interfaced to a consumer sound card acting
as an AD converter, fed by an analog RF antenna/receiver.
General purpose computer
Pros: configurable, easy to test, IO peripherals present for control.
Cons: not portable, less reliable due to reliance on operating system.
Low speed data converter (sound card)
Pros: simple and inexpensive
Cons: small bandwidth avaiable to process (20khz), requires downmixing and tuning to
be done by analog receiver
ECE496 Page 8 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
High performanced RF receiver and down mixer
Pros: could be purchased, put out of the scope of the design
Cons: requires more analog circuitry, less configurable, complex
2.1.2 Alternative B – DSP development board interfaced to a high speed AD converter,
fed by an RF antenna/receiver with simplified downmixing.
Embedded DSP development board
Pros: small, self contained, reliable
Cons: requires external controls, more difficult to test
High speed data converter board
Pros: move bandwidth available (10s of Mhz), allows digital downmixing for tuning
Cons: expensive
RF receiver with simplified IF/downmixing stage
Pros: RF downmixing stage simplified since AD converter can sample a larger spectrum
2.1.3 Alternative C – Custom designed embedded system with onboard chips for DSP,
AD conversion and RF downmixing, interfaced to an antenna.
In this solution, the three stages are embedded on a single board.
Pros: very small and portable, reliable
Cons: large design effort, risky
ECE496 Page 9 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
Team Phoenix believes that Alternative B provides a good tradeoff between the constraints,
objectives, and functional requirements defined for this project, and will develop
a product within the framework described in Alternative B.
3 Work Plan
3.1 Work Breakdown Structure
Figure 1: Work Breakdown Structure
3.2 Gantt Chart
A Gantt Chart is appended to the end of this document.
ECE496 Page 10 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
3.3 Financial Plan
Please see Table 1 for a tabulated presentation of our financial plan.
Table 1: Financial Plan
Item Maximum Price Notes
DSP Development
$600 Possibility of borrowing lower
Board
end performance board from
Communications Lab for $0
High Speed A/D
$300
Converter
PC/Laptop $0 Already owned
RF Transmitter $50
Misc Electrical
$50
Components
Test Equpiment $0 Design Centre and Communications
Lab
$1000 Net Expense
Contribution Amount Notes
Design Centre Funding
$300
Team Contribution $300
$600 Net Contribution
−$400 NET DEFICIT
3.3.1 Contingency
A slightly lower performance DSP development board from the communications lab is
available for $0. In the event that funding cannot be secured from the design centre, our
team is prepared to absorb all expenses.
ECE496 Page 11 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
3.4 Feasibility Assessment
3.4.1 Skills and Resources
This project requires skills and knowledge in the areas of programming, DSP, digital
design, antenna design and EM waves. Together, the team members have strong relevant
coursework and/or background in these areas. Professor Hum specializes in antenna/radio
design and will provide advice for the RF side. Practical information for
DSP programming will be obtained from spec sheets, manuals, and the internet.
3.4.2 Required Equpiment
The key hardware items are available at estimated price of $900 or less. They are manufactured
in large numbers and immediately available for purchase. Test equipment in the
SF design centre will also be utilized throughout the project development.
Example equipment breakdown
TMS320C6455 DSP Starter Kit (DSK) $595
ADS5525EVM 12-bit 170MSps $299
3.5 Risk Assessment
Software radio attempts to implement as much as possible through a digital embedded
system. Most failures can be mitigated by moving a particularly onerous function to a different
stage. This can be done by substituting a non custom component, or by marginally
reducing the functionality of the overall system. The project is modular enough that the
ECE496 Page 12 of 13

Team Phoenix – de Witt, Grover, Kucukelbir
Project Proposal – Draft B
different stages can be developed and tested independently, mitigating the risk of a difficulty
halting the whole development process.
A few key risks are summarized below:
Risk: Difficulty in implementing a controllable RF receiver
• The risk is due to the team members possessing the least amount of knowledge
in RF circuitry, and the custom design required for reconfigurable RF functionality.
Mitigation: Make use of a purchased FM receiver to tune and downmix the FM band
to base-band. In this case, the radio will lose part of its reconfigurability, but the
system will still meet its functional requirements. Yet the DSP facet of the project is
not dependent on the RF receiver.
Risk: Direct sampling of large bandwidth too much for DSP chip to process
• The risk is due to the uncertainty in the DSP algorithms we will develop.
Mitigation: Early testing will be performed on the development board. Failure will necessitate
downsampling in the analog RF stage, or the introduction of an additional
hardware module for dedicated digital downsampling.
ECE496 Page 13 of 13