Radio Station Monitor - Stellenbosch University
Transcript of Radio Station Monitor - Stellenbosch University
Stellenbosch University
Electrical and Electronic Engineering Department
Radio Station Monitor
Student:Jarrett Engelbrecht
Study leader:Prof G-J van Rooyen
Final year project presented in partial fulfilment of the requirements forthe degree of Electrical and Electronic Engineering
BEng (Electrical & Electronic)
November 2012
Declaration
I, the undersigned, hereby declare that the work contained in this report is
my own original work unless indicated otherwise.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signature Date
i
Acknowledgements
Thank you Prof G-J van Rooyen for your guidance and advice throughout the
project and also for allowing us to work in the MIH Media Lab.
Thank you to MTN for sponsoring the project.
Thank you to the guys from Trinity Telecomms for providing us with training
and especially Travis for answering all my emails when I had problems.
ii
Abstract
The Media Development and Diversity Agency who pays out grants for com-
munity radio stations requires a way to remotely determine if the stations are
active. A system is developed that can operate in a remote location and con-
firm that a community radio station is transmitting by uploading data using
a GSM modem. The system is designed and implemented with commercial-
off-the-shelf components as a machine-to-machine communication device. The
modem is provided by Trinity Telecomms and is connected to a virtual pri-
vate network over the cellular network. Data is processed by their SMART
platform and displayed on the platform’s graphical, web-based user interface.
The system is shown to be an adequate solution for radio station broadcast
monitoring.
iii
Opsomming
Die Media Ontwikkeling en Diversiteitsagentskap wie toekennings uitbetaal
aan gemeenskapradiostasies benodig ’n manier om van ver af te bepaal of die
stasies aktief is. ’n Stelsel is ontwikkel wat kan funksioneer in ’n afgelee plek en
bevestig dat ’n gemeenskap radio stasie uitsaai deur die oplaai van data met be-
hulp van ’n GSM modem. Die stelsel is ontwerp en geımplementeer met kom-
mersiele-van-die-rak-af komponente as ’n masjien-tot-masjien kommunikasie
toestel. Die modem is verskaf deur Trinity Telecomms en is gekoppel aan ’n
virtuele privaat netwerk oor die sellulere netwerk. Data word verwerk deur
hulle SMART platform en vertoon op die platform se grafiese, web-gebaseerde
verbruikerskoppelvlak. Daar word getoon dat die stelsel ’n voldoende oploss-
ing is vir radiostasie-uitsending monitering.
iv
Contents
1 Introduction 1
1.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Project description and scope . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Objectives of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background information 3
2.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Arduino Uno board . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Arduino programming language . . . . . . . . . . . . . . . . . . . . 4
2.1.3 FM receiver shield . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 GSM communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Sierra Wireless Airlink modem . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 AT commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 AWTDA extended command set . . . . . . . . . . . . . . . . . . . . 5
2.3 M2M platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Sierra Wireless AirVantage platform . . . . . . . . . . . . . . . . . 6
2.3.2 Trinity SMART Sight platform . . . . . . . . . . . . . . . . . . . . 6
2.4 Discrete Hartley transform . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Relation to the discrete Fourier transform . . . . . . . . . . . . . . 7
2.4.2 Arduino FHT library . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 System design 9
3.1 Requirements specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Hardware overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Overall system design . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Subdiagrams of components . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Flow of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Detail design 13
4.1 Details of the hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 GPS shield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 Si4735 shield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
v
CONTENTS
4.1.3 Power considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4 System enclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Details of the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 Processing responses from the modem . . . . . . . . . . . . . . . . 19
4.2.2 Executing commands . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Seek all stations algorithm . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.4 Sending data to the platform . . . . . . . . . . . . . . . . . . . . . 23
4.2.5 Setting up command/data handlers . . . . . . . . . . . . . . . . . . 24
4.2.6 Implementation of the libraries . . . . . . . . . . . . . . . . . . . . 24
4.3 The platform and dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Tests 27
5.1 Testing of FM reception and radio control . . . . . . . . . . . . . . . . . . 27
5.2 Testing of the modem’s serial interface . . . . . . . . . . . . . . . . . . . . 28
5.3 Test sending of data to the platform . . . . . . . . . . . . . . . . . . . . . 29
5.4 Testing reception of data from the platform . . . . . . . . . . . . . . . . . 30
5.5 Testing the dashboard and execution of commands . . . . . . . . . . . . . 31
5.6 Determining the validity of the FHT operation . . . . . . . . . . . . . . . . 34
5.7 Overall system test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.8 System reliability test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Conclusion 39
6.1 Objectives achieved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Possible improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
References 41
A Project planning schedule 42
B Project specification 44
C Outcomes compliance 45
D Circuit diagram and PCB layout 46
E Data collected during testing 48
F Source code and libraries 51
vi
List of Figures
2.1 Communication between the platform and modem. . . . . . . . . . . . . . 6
3.1 System diagram of the main components. . . . . . . . . . . . . . . . . . . . 10
3.2 Subdiagram of the modem. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Subdiagram of the Si4735 shield. . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Subdiagram of the GPS receiver. . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 Data flow diagram of the system. . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Circuit diagram of the GPS shield. . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Circuit diagram of the Si4735 shield [1]. . . . . . . . . . . . . . . . . . . . . 16
4.3 Flowchart of the system’s main loop. . . . . . . . . . . . . . . . . . . . . . 18
4.4 Flowchart of the subroutine: Process response from modem. . . . . . . . . 20
4.5 Flowchart of the subroutine: Execute command. . . . . . . . . . . . . . . . 21
4.6 Flowchart of the subroutine: Seek all stations algorithm. . . . . . . . . . . 22
4.7 Flowchart of the subroutine: Send data to platform. . . . . . . . . . . . . . 23
4.8 Flowchart of the subroutine: Set up command/data handlers. . . . . . . . 24
4.9 Screenshot of the dashboard on the SMART Sight platform. . . . . . . . . 26
5.1 The frequency spectrograms of three different audio signals. . . . . . . . . 35
5.2 The route that was driven for the overall system test. . . . . . . . . . . . . 36
5.3 The SNR of the frequencies found over 3 days of autonomous operation. . . 38
A.1 Gannt chart of the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
D.1 Circuit diagram of the 2nd revision Arduino Uno board. . . . . . . . . . . 46
D.2 PCB layout of the GPS shield. . . . . . . . . . . . . . . . . . . . . . . . . . 47
vii
List of Tables
2.1 Memory characteristics of the Arduino FHT library [2]. . . . . . . . . . . . 8
5.1 Test 1: Results of sending different characters to the AVR sequentially. . . 28
5.2 Test 2: Results of sending different characters to the AVR sequentially. . . 29
5.3 Details of the commands that can be sent to the system. . . . . . . . . . . 32
5.4 The results of sending each command to the system. . . . . . . . . . . . . . 33
E.1 Test 7: Data collected and sent to the platform during driving with the
system in a car . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
viii
Nomenclature
Acronyms
ADC Analog-to-Digital Converter
ASCII American Standard Code for Information Interchange
BNC Bayonet Neill-Concelman
DC Direct Current
DCE Data Communications Equipment
DFT Discrete Fourier Transform
DHT Discrete Hartley Transform
DTE Data Terminal Equipment
FET Field Effect Transistor
FFT Fast Fourier Transform
FHT Fast Hartley Transform
FM Frequency Modulation
GPS Global Positioning System
GSM Global System for Mobile Communications
I2C Inter-Integrated Circuit
IC Integrated Circuit
ICSP In Circuit Serial Programming
LED Light Emitting Diode
M2M Machine to Machine
MDDA Media Develpoment and Diversity Agency
ix
Nomenclature
PCB Printed Circuit Board
PWM Pulse Width Modulator
RF Radio Frequency
SIM Subscriber Identity Module
SPI Serial Peripheral Interface
TTL Transistor-Transistor Logic
UART Universal Asynchronous Receiver/Transmitter
UI User Interface
USB Universal Serial Bus
VPN Virtual Private Network
Terminology
CR A carriage return is a control character used to reset a text
cursor to the beginning of a line.
LF A line feed is a control character used to signify the end of
a line of text.
x
Chapter 1
Introduction
A government agency who pays out grants for community radio stations requires a way to
remotely determine if the stations are active in their area. A system therefore needs to be
designed that can operate in a remote location and monitor the broadcasts of radio sta-
tions. The system must be automated and upload data through a mobile communications
(GSM) link to a web-based platform.
1.1 Problem statement
The Media Development and Diversity Agency (MDDA) was set up by an Act of Parlia-
ment (Act 14 of 2002) to encourage and provide support for the development of community
media and small commercial media. The end goal of this is to provide media access to
“historically disadvantaged communities and persons not adequately served by the media”
and “historically diminished indigenous language and cultural groups”[3].
The MDDA tries to reach this goal by awarding grants to community, small commercial
and research media projects. Some of these projects entail starting and operating a local
community radio station. The MDDA provides funding for the operation of such radio
stations until they can become financially self-sufficient from advertising and other sources
of revenue. The MDDA receives many grant applications and disburses grants in four
cycles a year. Since some of the community radio stations receiving grants are scattered
in remote places across South Africa, it can be difficult for the MDDA to confirm that a
community radio station is in operation.
1.2 Project description and scope
A telemetry system is required to operate in a remote location and confirm that a commu-
nity radio station is, in fact, transmitting. The system must sporadically monitor active
usage of the frequency band and upload data using a GSM modem. The system must
be built from commercial-off-the-shelf components. The provided modem is connected
to a virtual private network (VPN) administrated by Trinity Telecomms (Trintel) which
1
1.3 Objectives of the project
they have set up over the Vodacom and MTN cellular network. The received data will
be processed by Trintel’s SMART platform and displayed on the platform’s graphical,
web-based user interface (UI). The platform allows anyone with login details access to the
data from any internet device with a compatible browser.
1.3 Objectives of the project
The project will try to reach the following objectives:
• Provide an adequate solution to the MDDA’s problem of remotely determining
whether a community radio station is transmitting.
• Design a robust, weatherproof, battery powered radio station monitoring system
that can track when and where stations are transmitting and provide the data in
an easily understandable and accessible manner.
• Demonstrate the strengths and potential of the Trinity Telecomms SMART Sight
platform by using it effectively and providing meaningful feedback.
2
Chapter 2
Background information
The proposed system must be built from commercial-off-the-shelf components. There
are four main components, namely the FM receiver, GSM modem, GPS module and
microcontroller. This chapter provides information on the components and technologies
used — such as the programming environments and interfaces.
The choice of what microcontroller to use is one of the most important aspects of
the project. It must bring all the components together to form a complete, robust and
reliable system. Since most of the development time goes into the programming of the
microcontroller, a well documented instruction set and programming environment is a key
deciding factor. An Arduino microcontroller board was decided on as it meets the system
requirements and has been tried and tested by many.
There is no restrictions on what components may be used, except for the GSM mo-
dem. A preconfigured GSM modem was provided by Trintel, including a MTN SIM card
that is registered on their VPN. The provided modem uses the AT command set with
an extended command set developed by Trintel. The command set enables machine to
machine (M2M) communication between a modem and Trintel’s cloud platform. All of
the above mentioned as well as the mathematical Hartley transform implemented in the
system is discussed further in this chapter.
2.1 Arduino
The founders of the Arduino project describes it as “an open-source electronics pro-
totyping platform based on flexible, easy-to-use hardware and software” [4]. Arduino
microcontroller boards are based on the Atmel megaAVR (ATmega) series 8-bit micro-
controllers. A variety of boards are available with different ATmegas and interfaces such
as USB, UART and I2C. Several official Arduino shields and many unofficial shields from
other companies are available for purchase. A shield is a printed circuit board (PCB) that
can directly plug into the headers of certain Arduino boards, extending its capabilities.
Shields are an easy way to add functionality such as WiFi to an Arduino-based system.
3
2.1 Arduino
2.1.1 Arduino Uno board
An Arduino Uno board was acquired for the system. It is based on the ATmega328
microcontroller (referred to as the AVR from now onwards) and has all the necessary
circuitry to support it, as well as an USB connection, ICSP header, power jack and reset
button. The Uno has the following attributes:
Operating Voltage: 5VDigital I/O Pins: 14 (of which 6 provide PWM output)Analog Input Pins: 6Flash Memory: 32 kBSRAM: 2 kBEEPROM: 1 kBClock Speed: 16 MHz
The AVR can be programmed directly with standard AVR C code using the ICSP header
or it can be programmed through the USB connection with Arduino’s own C++ based
programming language [5].
2.1.2 Arduino programming language
The Arduino programming language has a standard set of libraries with many other
community-contributed libraries also available. It also links the standard AVR C library
(or libc), allowing the use of any of its functions. The Arduino language thus complements
the limited AVR libc with many extra functions that makes programming the AVR easier,
although it may not always be the most efficient implementation.
2.1.3 FM receiver shield
There are very few COTS 88–108 MHz band FM receivers available locally and none
of them are applicable for the proposed system. A small FM receiver IC is the best
solution, but are also hard to source. Distributors such as RS Components just do not
sell 88–108 MHz band radio components.
Since the Arduino platform is so popular, companies such as Sparkfun Electronics
design and manufacture a variety of shields for Arduino boards. Sparkfun sells an FM
and AM receiver shield based on the Silicon Labs Si4735 radio receiver IC. The shield is
available from Ne tram Technologies, the main distributor of Arduino products in South
Africa. The Si4735 FM receiver is suitable for the intended system and since the shield
can be plugged into the Uno board, it was a rational choice to procure one.
4
2.2 GSM communications
2.2 GSM communications
Data logged by the system will be sent to a server through GSM data communications.
The general wide area coverage of mobile operators make GSM an appropriate commu-
nication medium for most telemetry systems.
2.2.1 Sierra Wireless Airlink modem
The modem that is provided by Trintel for the project is the Sierra Wireless GL6100
programmable modem [6]. It is a quad band GSM/GPRS modem. It has an easily
accessible SIM card slot and it communicates with other devices through an RS-232 serial
port.
The modem is programmed with Sierra Wireless Firmware 7.45 which includes a com-
prehensive set of AT commands with which to control the modem. The modem is also
supported by the Open AT Application Framework, a software package that allows the
development of custom AT command sets for M2M applications.
2.2.2 AT commands
AT commands are ASCII encoded messages exchanged between an external application
(DTE) and a modem (DCE) using a serial link [7]. When the DTE sends an AT command,
the DCE must always send back a response. AT commands always start with “AT” and
end with a carriage return (CR). Responses always start and end with a carriage return
and line feed (CRLF), and will therefore be omitted from examples.
Responses may contain some other parameters in certain cases, but it will always
end with an “OK” if the command was executed successfully. If the command syntax is
incorrect, the response string will be “ERROR”. If the command syntax is correct, but
with invalid parameters, “+CME ERROR: (code)” is returned with appropriate error
codes if the CMEE flag is set. Unsolicited responses can also be returned at any time,
such as when the modem receives incoming data. Unsolicited responses usually start with
“+AT” and do not end with “OK”.
2.2.3 AWTDA extended command set
Trintel developed their own extended AT command set using the Open AT Application
Framework that enables data communication between a GL6100 modem and their M2M
platform. Data can be sent from the platform to the modem and vice versa. Commands
with parameters can be sent from the platform to the modem with the modem having to
send an acknowledgement of the command being completed. An event can be sent from
the modem to the platform which can then send a SMS or email notification to the relevant
person who needs to attend to the event. Figure 2.1 shows this flow of communication:
5
2.3 M2M platform
PLATFORM MODEM
EVENT
DATA
COMMAND
ACK
Figure 2.1: Communication between the platform and modem.
Data handlers need to be set up on the modem for each data metric and command that
it must listen for. This needs to be done every time after the modem reboots, otherwise
the modem will just ignore data received from the platform.
2.3 M2M platform
Technologies that enable automated communication between remote devices are referred
to as machine to machine (M2M) communications. It allows real time monitoring and
control of systems remotely without the need of human intervention. A M2M platform is
a central management server that collects data from remote devices and provide it to the
end user typically through a web application, SMS or email, as well as allowing control
of the remote device to the end user.
2.3.1 Sierra Wireless AirVantage platform
AirVantage is a comprehensive platform that allows service providers to rapidly develop
and deploy M2M services. The core of the platform is the Operating Portal that supports
operations such as subscription, device and asset management. Provided with the plat-
form is the Developer Suite, an Eclipse-based toolset supporting embedded and server
application development in C, C++, Java and Lua. It also supports web UI, mobile UI
and Google gadget development [8].
2.3.2 Trinity SMART Sight platform
Trintel developed their own web interface for the AirVantage platform called SMART
Sight. It includes a web-based tool for creating a graphical UI called a dashboard for each
asset. Data collected from an asset can be displayed on its dashboard in graphs, tables
and meters. Interactive buttons can also be used to send commands or data from the
dashboard to the asset. Login details can be provided to end users that gives them access
to the dashboard only, keeping them from changing settings on the platform.
6
2.4 Discrete Hartley transform
2.4 Discrete Hartley transform
The discrete Hartley transform (DHT) is similar to the discrete Fourier transform (DFT).
The difference is that the DHT only takes real-valued time-domain signals as input and
gives a real-valued sequence as output, with no involvement of complex numbers. Another
interesting property of the DHT is that the transform operation is identical to the inverse
transform, therefore the computation of the DHT consumes less memory than the DFT [9].
Given a finite discrete function f [n], with 0 ≤ n < N , the DHT is defined as
H[k] =N−1∑n=0
f [n]
[cos
(2π
Nnk
)+ sin
(2π
Nnk
)]
2.4.1 Relation to the discrete Fourier transform
Since the DHT is so similar to the DFT, the mathematical relation between them is
simple. With the even and odd parts of the DHT given by
E[k] =H[k] +H[−k]
2and O[k] =
H[k] −H[−k]
2
The DFT of f [n], denoted as F [k], can then be obtained from the DHT of f [n] by
F [k] = E[k] − iO[k]
Samples of the radio’s audio output will be put through the DHT and averaged over
a short period to estimate the signal spectrum.
7
2.4 Discrete Hartley transform
2.4.2 Arduino FHT library
Open Music Labs, a subsidiary of Sparkfactor Design, developed an implementation of
a standard fast Hartley transform (FHT) algorithm with the Arduino programming lan-
guage. The number of frequency bins can be adjusted between 16 and 256, and several
output methods are available. The output magnitude can be set to 16-bit linear, 8-bit lin-
ear, 8-bit logarithmic or 8-bit octave. Samples from the AVR’s analog-to-digital converter
(ADC) can be given as input to the FHT [2].
For this project the speed of the implementation is not much of a consideration, but
the memory usage is, seeing as the AVR only has 2 kB of SRAM. The implementation is
quite efficient with memory usage, since it uses lookup tables stored in the flash memory of
the AVR to approximate values instead of calculating them. Table 2.1 shows the memory
usage (in bytes) of the different functions and output methods of the FHT library.
Table 2.1: Memory characteristics of the Arduino FHT library [2].
S = SRAM, F = FLASH
Function run reorder window lin lin8 logN S/F F F S/F S/F S/F256 512/476 120 512 256/768 128/640 128/256128 256/224 56 256 128/768 64/640 64/25664 128/100 28 128 64/768 32/640 32/25632 64/40 12 64 32/768 16/640 16/25616 32/12 6 32 16/768 8/640 8/256
8
Chapter 3
System design
The overall design of the system is presented in this chapter. The required capabilities
of the system and how they are to be implemented is described. Block diagrams of the
system’s design and the different components are provided and discussed to form a clear
understanding of the hardware. The flow of data to, within and from the system are also
outlined.
3.1 Requirements specification
The system has the following functional requirements in order to solve the proposed
problem:
• The system must be able to receive FM radio stations between 87.5–108 MHz and
be able to tune to any specified frequency digitally.
• The system must be able to receive and send data through a GSM modem from and
to a web-based platform.
• The system must periodically report the SNR of the received signal at a specified
frequency.
• The system must be able to automatically scan through the spectrum to keep a log
of all the available radio stations and send it to the platform.
• A user must be able to remotely tune the radio to a specified frequency through the
platform.
• A user must be able to set the report in period of the system remotely from the
platform.
• The system must be able to obtain its position from a GPS module and send its
coordinates to the platform.
• The system must be able to run from a battery and be suitable for outdoor use.
9
3.2 Hardware overview
3.2 Hardware overview
The system is composed of four main components — the GSM modem, AVR microcon-
troller, FM radio receiver and GPS module. These components have different communi-
cation standards and different interfaces are used between them.
3.2.1 Overall system design
The interconnection of the main components is shown in figure 3.1. The modem and
AVR communicate through an UART serial connection. The Si4735 receiver and GPS
module both communicate with the AVR through a shared SPI bus with the AVR as the
master. When the AVR wants to communicate with a device on the SPI bus, it has to
pull the voltage of the device’s SS line low while the other SS line is kept high. Figure
3.1 also shows the external antenna needed by the Si4735 for good signal reception. The
modem and GPS module both have small antennas that can fit within the enclosure of
the system.
Modem Arduino Uno Si4735 shield
GPS shield
Rx
Tx SPI bus
SS
SS
Externalantenna(AVR)
Figure 3.1: System diagram of the main components.
3.2.2 Subdiagrams of components
Figure 3.2 shows the GL6100 modem with its antenna and a RS-232 to transistor-
transistor logic (TTL) signal level converter. The modem’s serial connection is based
on the RS-232 standard while the AVR operates with 5V TTL levels. A converter is
therefore needed for the AVR and modem to be able to communicate.
ModemRS-232 to TTLsignal converter
Rx
Tx
Rx
Tx
to AVR
Antenna
Figure 3.2: Subdiagram of the modem.
10
3.3 Flow of data
Figure 3.3 shows the components that are on the Si4735 shield. There is a small
impedance matching circuit between the antenna header and the Si4735’s RF input. The
Si4735 operates with 3.3V TTL levels. Circuitry is therefore needed to adjust the logic
levels to 5V to ensure reliable communication between the Si4735 and AVR.
Si4735Impedancematching
circuitAntenna
3.3V to 5Vlogic converter
SS
to AVRAudio out
SPI bus
Figure 3.3: Subdiagram of the Si4735 shield.
Figure 3.4 shows the GPS module with its extra components. The GPS specifically
uses a patch antenna with a BNC connector that is already matched to its RF input,
therefore no matching circuit is needed. A LED can be connected to the GPS to visually
show when it acquires a lock. The GPS also operates with 3.3V TTL levels and therefore
needs the same voltage conversion circuitry as the Si4735.
Antenna
3.3V to 5Vlogic converter
SS
to AVRSPI bus
GPS-310FS
LED Battery
Figure 3.4: Subdiagram of the GPS receiver.
3.3 Flow of data
The system is designed to ensure a reliable and continual flow of data. Figure 3.5 shows
the flow of data between the platform, modem, AVR and other components. There are
four different commands that an user can send to the system from the platform. Only
one command can be sent at a time. The first command that can be used tunes the radio
to a specified frequency. The second command can be used to set the period at which
the system reports in data in minutes from 0, meaning no reporting, to 240 minutes. The
frequency the radio is tuned to and SNR of the signal is sent to the platform every period,
as well as the GPS coordinates of the system. The third command that is available tells
the system to scan through the FM radio spectrum and report the frequencies of any
signals it picks up. The last command instructs the system to obtain the average DFT of
a short audio sample taken from the radio and send it to the platform.
The system reports its operating state to the platform every minute. This serves as a
heartbeat for the platform to know when the system’s GSM connection is up. When the
11
3.3 Flow of data
PlatformModem:
Receive and processcommand/Send data
AVR:
Response to command
Si4735
Command
AT command containing data
Unsolicited response containing data
Poll for reponse
ResponseSystem controller
Periodic NMEA strings GPS
Audio
Tune to frequency
Report in period
Find all stations
Perform FFT on audio sample
Frequency tuned to
SNR
FFT sample
Operating state
GPS coordinates
Commands
Data variables
Figure 3.5: Data flow diagram of the system.
system is busy performing the DFT operation, it sets its state to “sampling”, and when it
is busy searching through the spectrum, it sets its state to “seeking”. When the system is
not busy performing an operation and the reporting period is set to zero, it sets its state
to “idle”, and when the report in period is above zero, it sets its state to “monitoring”.
12
Chapter 4
Detail design
The detail of each hardware component’s design is presented in this chapter, as well as
the system’s operating code that was written for the AVR. Complete circuit diagrams
are provided and explained for parts of the hardware. The manner in which the system
operates is explained by using flowcharts. The reasoning behind design decisions are also
justified.
4.1 Details of the hardware
COTS components were used for the system and therefore the only part that was self-
designed is the breakout shield for the GPS module. Only the circuits of the GPS shield
and Si4735 shield is looked at and explained in this section, while the circuit diagram of
the Arduino Uno board is provided in Appendix D for interests sake.
4.1.1 GPS shield
Figure 4.1 shows the complete revised circuit diagram of the GPS shield. The PCB layout
of the shield is designed so that the pin-outs can directly plug into the headers of the Uno
board. The block named “UNO” represents the headers of the board.
The GPS module is surface mounted and has some external circuitry on the shield.
Connected to pin 9 of the GPS is a LED driven by an NPN bipolar junction transistor
that serves as a status indicator. Decoupling capacitors are connected between the RF
ground and DC power supply pins, as well as the baseband ground and DC power supply
pins to reduce noise. A ferrite bead is also connected between the two ground planes
to only let DC current through. Connected between the “RF-IN” pin and RF ground
is a BNC connector for an external antenna. The 1-pulse-per-second and two separate
UART serial outputs are connected to the “DEBUG” header so they can be accessed for
debugging purposes. The baseband DC power supply (pin 1) is connected through a zener
diode to the “V-BAT” pin and the “BATTERY” header that are also connected to each
other. The GPS can thus draw power from a battery or a DC power supply if either is
13
4.1 Details of the hardware
connected, and it also allows the battery to be charged by the power supply if its voltage
drops below a certain level.
The I/O pins that must be connected to the AVR need voltage conversion circuitry to
enable reliable communication. With a 5V supply voltage, the AVR’s output high voltage
can range from 4.2V–5V. The voltage at the GPS’s input pins may not exceed 3.6V and
anything above 2V is interpreted as high. Two equal resistors can therefore be used to
divide the voltage from the AVR to give a safe voltage range of 2.1V–2.5V to the GPS.
With a 3.3V supply voltage, the GPS’s output high voltage can range from 2.4V–3.3V.
The AVR’s minimum input high voltage is 3V and maximum 5.5V. The output voltage
of the GPS is therefore pushed up with a BSS138 enhancement mode FET. The drain-
source diode forward voltage of the FET is typically 0.7V, thus ensuring the minimum
high voltage seen by the AVR’s input pin is 3.2V.
Pin D4 of the Uno outputs to the reset pin of the GPS. The pin must be kept high, as
the GPS resets when the pin is low. The signals that are input to the GPS from the AVR
as part of the SPI interface is the slave select (SS), clock (CLK) and master-output-slave-
input (MOSI) signals. The master-input-slave-output (MISO) signal is the only input to
the AVR from the GPS. Data from the GPS is received by the AVR on this line.
GPS_310FS
10k
10k
10k
10k
10k
10k
10k
10k
10k
10k
MAX3323
2N390427
k470
0.1u 0.1u
0.1u
0.1u
4.7u
4.7u
10n
10n
BNC-O
WN
FB
ARDUINO_SHIELDLABEL
0.1u 390
DGND
RF-GND
3.3V 5V
5V
5VDGND
DGND
DGND
DGND
DGND
DGND
3.3V
3.3V
3.3V
RF-GNDRF-GND
DGND
3.3V
DGNDRF-GND
DGND
DGND
DGND
DGND
MISO
MISO
MOSI
MOSI
SS
SSRESET
CLK
CLK
DVCC 1
PMON 3RXD0 4TXD0 5TXD1 6RXD1 7GPIO3 8LED 9
RF-IN17
VCC-ANT19
VCC-RF20
V-BAT21
RESET22
GPIO023
SPI-CSN124
SPI-CSN0/PIO525
SPI-CLK/PIO126
SPI-DI/PIO1327
SPI-DO/PIO1228
1PPS29
GPIO1330 GND1 2
GND2 10
RF-GND718
RF-GND616
RF-GND1 11RF-GND2 12RF-GND3 13RF-GND4 14RF-GND5 15
GPS_MODULE
R1
R2 1
23
Q2
R3
R4 R5
R6
R7
R8
R9 R10
RS232-TO-TTLC1+ 1
C1- 3
C2+ 4
C2- 5
T1IN10
R1OUT9
V+ 2
V- 6
T1OUT 7
R1IN 8
TXENABLE11 RENABLE12
SHDN14 GND15 VCC16
VL13
MODEM123456
LED1
T1
R12
R13
C1 C2
C3
C4
C5
C7
C6
C8
ANTE
NNA
RXTX
D2*D3D4*D5*D6D7D8*D9*D10*D11D12D13
A0A1A2A3A4A5
VINRES
5V
AREFGNDGNDGND
3.3V
UNO
RB521S
C9
R11
BATTERY
12
DEBUG123
Figure 4.1: Circuit diagram of the GPS shield.
The MAX3323 is the RS-232 to TTL signal converter IC that is used for the UART
serial connection between the AVR and modem. It was added on the GPS shield since
there was extra unused space left on the PCB layout. The “MODEM” header is where
the wires of the modem’s data cable can be directly soldered to the board. Pin 2 and 3
14
4.1 Details of the hardware
is for the request-to-send (RTS) and clear-to-send (CTS) signals of the RS-232 standard.
It is connected together to spoof RTS/CTS handshaking since the AVR’s serial port does
not support this flow control mechanism.
The PCB layout of the shield that was fabricated is provided in Appendix D. The
debug and battery headers are missing, since those parts were only added afterwards to
the revised circuit diagram. After the GPS module and other components were soldered
to the PCB, the GPS was tested independently from the rest of the system. All the
connections were checked thoroughly and the 1 pulse per second and serial outputs were
monitored on an oscilloscope. When the GPS was powered from a DC power supply,
it drew 40 mA of current, but none of the outputs were functioning. The status LED
also did not switch on. Unfortunately the GPS module was either defective or it was
accidentally broken. It was decided not to order a replacement, since there was only a
few weeks left for the project and a new GPS module would not have been delivered in
time.
Even though the GPS module was not working, the necessary code was still written
to enable the AVR to retrieve coordinates from the GPS. Another Uno board was pro-
grammed to emulate the NEMA messages that the GPS should send on the SPI bus.
Parts of the code were thus successfully tested. Therefore if another one of the same GPS
modules can be obtained, it should take minimal effort to integrate it into the system.
4.1.2 Si4735 shield
Figure 4.2 shows the complete circuit diagram of the Si4735 shield as designed by Sparkfun
electronics. The PCB layout of the shield is also designed so that it can plug into an
Arduino board, hence the block with the Uno board’s pins. The Si4735 and GPS shield
can be stacked on top of the Uno board by using special stackable headers.
The shield has a 3.5 mm jack on it connected to the left and right audio output
channels of the Si4735. There are also separate headers with the necessary impedance
matching elements for a FM cable antenna and an AM ferrite loop antenna. The last
important component to notice is the hex converter IC that is used to lower 5V outputs
from the AVR to 3.3V for the Si4735’s input pins. The GPO1 pin of the Si4735 that is
connected to pin D12 of the Arduino header carries the MISO signal of the SPI interface.
The high level output voltage of the Si4735 can go as low as 2.64V, while the AVR only
interprets voltages above 3V as high. The AVR will therefore not consistently interpret
the output from the Si4735 correctly. Assuming it was an oversight by the designer(s),
the shield was modified to correct it. The copper line connecting the pins were scratched
out and a small logic level converter board (also made by Sparkfun) was mounted on the
prototyping area of the shield. One of the converter’s TX lines is connected between the
GPO1 and D12 pins.
Another fault in the design is that the analog reference pin (AREF) for the AVR’s
15
4.1 Details of the hardware
Figure 4.2: Circuit diagram of the Si4735 shield [1].
ADC is connected to ground. The fault was easily avoided though by not connecting the
pin to a header. A wire was also soldered to the left audio output pin (LOUT) to connect
it to the ADC0 input pin of the AVR.
4.1.3 Power considerations
The Si4735 and GPS-310FS both need a 3.3V power supply and they consume approxi-
mately 23 mA and 45 mA respectively. The voltage conversion circuitry also pulls some
current from the 3.3V power supply. The LP2985-33DBVR regulator on the 2nd and
3rd revision Uno board can supply 150 mA of current maximum. If the system is sitting
in direct sunlight and the ambient temperature inside the enclosure reaches 50◦C, the
maximum allowable power dissipation can be calculated from the datasheet as
PD =TJ(max) − TA
θJA=
125 − 50
206= 0.364W
As the 3.3V regulator is supplied by the 5V regulator, the power dissipation at 150 mA is
PD = (VIN − VOUT )IO = (5 − 3.3)0.15 = 0.255W
Since 0.255W < 0.364W , 150 mA can be safely drawn from the 3.3V pin even in
extreme conditions, which is more than enough for both the Si4735 and GPS shields.
4.1.4 System enclosure
The system is enclosed in an IP62 rated casing. The rating indicates that the enclosure is
dust tight and that it prevents the ingress of dripping water equivalent to 3 mm of rainfall
per minute.
16
4.2 Details of the software
4.2 Details of the software
Figure 4.3 is a flowchart of the system’s main loop. It demonstrates the looping program
flow while the system is powered up. A set of flags are sequentially checked in the loop
that alters the program flow when they are changed. The program flow can break off
into 5 different subroutines that are explained in their own flowcharts. Subroutines are
represented by a rectangle with an extra vertical line on each side.
The AVR’s watchdog is set up to trigger an interrupt if it is not reset within 2 seconds.
If the system hangs and the watchdog interrupt is triggered, all the necessary variables
needed for the system to continue with its current operation is saved in the EEPROM
before the AVR is reset. After a reset the last saved values of those variables are retrieved
from the EEPROM and the system can thus continue with its previous operation. Note
that only some of the variables that are saved is shown in the flowchart.
Data received from the modem is stored in a buffer, which is read one character at a
time and added to a string. The string is evaluated after each character added whether
it is a complete response from the modem, in other words, whether it starts and ends
with CRLF. The response is then processed by the subroutine in figure 4.4. The modem
echoes back all characters that are sent to it and therefore the string is also evaluated
whether it is an echo. This is not shown in the flowchart. Echoes are ignored, but if no
echo is received within half a second after sending characters to the modem, the AVR is
reset by the watchdog.
The next condition that is checked in the main loop is whether a minute has passed
since the last minute or reset. A free running counter which increments each millisecond
is used for this purpose. Each minute the operating state of the system is sent to the
platform. This serves as a system heartbeat to the platform. The platform only sends
data to the modem after it receives data from it. The minutes passed are also counted
and when the reporting period is reached, the minutes counter is reset to zero and the
current frequency and SNR of the radio is sent to the platform.
When a command is received, an acknowledge is immediately sent to the platform.
A command is only executed after it has been determined whether an acknowledge was
sent successfully. The subroutine in figure 4.5 shows how the different commands are
executed. A short algorithm is iterated in the main loop when the command to find all
the stations is received. It continues until the entire FM spectrum has been searched
through. The algorithm is shown in figure 4.6. Data writes to the platform must be
regulated and performed sequentially. If the modem’s communication link is up and a
data write is queued, it is handled by the subroutine in figure 4.7. The last condition
checked in the main loop is whether the command handlers need to be set up, which
needs to be performed every time the modem reboots. This process is handled by the
subroutine in figure 4.8.
17
4.2 Details of the software
Retrieve saved valuesfrom EEPROM
Watchdog interruptPower up
//Write to EEPROM:Operating stateFrequency
Report in periodMinutes passedNext data write
Add char to string
Process responsefrom modem
True
Byte from serial buffer
System reset
Reset watchdog
Setup
String complete?
Operating stateFrequency
Report in periodMinutes passedNext data write
Seek all stations?
modemUp? ANDData to be sent?(nextDataWrite > 0)
Executecommand
Send data toplatform
Set up command/data handlers
Acknowledge sent?(ackStatus == 2)
False
False
False
True
True
True
True
Seek all stationsalgorithm
Minute passed?
nextDataWrite = 1
reportPeriod == 0?
False
False
minutes ==reportPeriod?
minutes++nextDataWrite = 2
minutes = 0
True
TrueFalse
TrueFalse
Set handlers?AND handlerSet?
Figure 4.3: Flowchart of the system’s main loop.
18
4.2 Details of the software
4.2.1 Processing responses from the modem
Figure 4.4 is a flowchart of the subroutine that processes the response from the modem.
The response string is first compared against a lookup table containing the expected
responses to determine what was received. The lookup table is stored in the 32KB of
available flash memory and retrieved one row at a time. This is necessary since there is
only 2KB of SRAM available for the program during operation.
The modem sends its status to the AVR when it changes or otherwise every minute.
This response can be “+AWTDA: UP”, “+AWTDA: DN” or “+AWTDA: BOOT” and it
means its communications link is either up, down or its rebooting. A flag is used to keep
track of its connection status. When the modem loses its connection, it has to reboot
to reconnect and therefore the command/data handlers have to be reset. If the AVR
receives the up response and the flag, “modemUp”, is set to false, the flag used to set the
command/data handlers up is therefore set.
Responses from the modem that starts with “+AWTDA: c,” or “+AWTDA: d,” are
commands or data sent from the platform. The format of these responses are identical and
are therefore processed together. Each command or data job generated by the platform
has an unique identifying number that is sent with it. An acknowledge message containing
the identifier is immediately sent to the modem when a command is received. The flag,
“ackStatus”, is set to 1, meaning the program must first wait for the “OK” from the
modem that the acknowledge was successfully sent before executing the command. Next
the name of the command is compared against another part of the lookup table that
contains the command names. A command index variable is then set accordingly and the
parameter of the command is stored in a separate string. The command is thus ready to
be executed after the acknowledge has been sent.
The program flow is altered every time an “OK” is received according to the current
states of the different flags. If the command handlers is being set up and an “OK” is
received, it means one of the handlers has just been successfully set. The “handlerSet”
flag is therefore set to true and the “handlerNo” counter is incremented so that the next
handler can be set. If the handlers are not being set, the “ackStatus” flag is checked. If
it is set to 1, it means an acknowledge has been successfully sent and it is then set to 2,
indicating to the program that it can execute the received command. If no acknowledge
was sent either, it is lastly checked whether a data write has been performed, in which
case “nextDataWrite” will be equal to -1. If this condition is also false, the “OK” is
otherwise ignored.
If a data write has been performed, it is first determined whether consecutive samples
from the FHT operation needs to be sent, or the different frequencies where carriers were
picked up during a search through the FM spectrum. If neither of these conditions are
true, it is a single data write that took place, in which case the queued data write is set
19
4.2 Details of the software
to be performed next or if none is queued, the “nextDataWrite” flag is set to zero.
DownUp
False
Command/Data Error/Timeout
Compare response againstlookup table stored in flash
modemUp?
OK
Process response from modem
setHandlers?
samplesSent < 16?
handlerSet = truehandlerNo++
//Send next sample:nextDataWrite = 4
sendAll?
nextDataWrite = queuedDataWritequeuedDataWrite = 0
queuedDataWrite > 0?
samplesSent >= 0?sendAll = falseRevert opState
ackStatus = 2
nextDataWrite = 0 Return
nextDataWrite == -1?
True
True
False
False
False
True
False
True
True
False
Return
//Stop sending:samplesSent = -1Revert opState
FalseTrue
True
current address== last address
False
True
False
Return
ackStatus == 1?
Send acknowledgementackStatus = 1
Set commandIndexRetrieve parameter
Return
modemUp = truesetHandlers = true
modemUp = false
True
//Retry to send data:nextDataWrite = prevDataWrite
//Send next freq + SNR from ROM:nextDataWrite = 5
address += 3
Figure 4.4: Flowchart of the subroutine: Process response from modem.
20
4.2 Details of the software
4.2.2 Executing commands
Figure 4.5 is a flowchart of the subroutine that executes received commands. The com-
mand that was received has already been identified and is performed according to the value
of the command index. The “tuneTo” command tunes the radio to the integer value rep-
resented in the parameter string and sets the next data write to perform. The data to be
sent to the platform is the current frequency tuned to, SNR and GPS coordinates of the
system.
The “seekAll” command has a boolean as its parameter. If the boolean is true, the
“seekAll” flag is set to true and the operating state is set to 3 — indicating the system is
seeking. The radio is tuned to the low limit of the FM spectrum, 87.5 MHz, and then it
starts seeking upwards from there. The SNR threshold for a valid FM seek is 3 dB. If the
boolean is false, the “seekAll” flag is set to false, stopping the operation. The operating
state is also reset to its previous value, which would be either 1 or 2.
The “reportEvery” command sets the reporting period integer to the integer value
represented in the parameter string. The minutes passed integer is reset to zero and the
next data write is set to sending the reporting period to the platform. If the reporting
period is zero, the operating state is set to 1, otherwise it is set to 2 — indicating the
system is either idle or in monitoring mode respectively.
Execute command
commandIndex?
reportEvery
Set reportPeriodminutes = 0
nextDataWrite = 3
seekAll
seekAll = trueopState = 3
Tune to 87.5 MHzSeek up
Return
performFHT
//Start operation:samplesSent = 0
opState = 4
//Cancel operation:samplesSent = -1Revert opState
parameter?parameter?
tuneTo
Tune radio to frequencynextDataWrite = 1
seekAll = falseRevert opState
ReturnopState = 2reportPeriod == 0?opState = 1
True
False
FalseTrue
False
True
Figure 4.5: Flowchart of the subroutine: Execute command.
21
4.2 Details of the software
The “performFHT” command also has a boolean as its parameter. If the boolean is
true, the “samplesSent” counter is set to 0, which would start the FHT operation and
the sending of the subsequent samples to the platform. The operating state is set to 4 –
indicating the system is sampling the audio output of the radio. If the boolean is false,
the “samplesSent” counter is set to -1, stopping the operation. The operating state is also
reset to its previous value, which would again be either 1 or 2, depending on the current
reporting period.
4.2.3 Seek all stations algorithm
Figure 4.6 is a flowchart of the algorithm used to seek through the entire spectrum at
least once. The reply status is checked of the last command sent to the radio — which
would be the seek up command when the subroutine is entered. If the seek/tune complete
interrupt (STCINT) bit in the status byte is 0, the radio is still seeking and the subroutine
returns to the main loop. If the STCINT bit is 1, the seek is completed and the current
frequency of the radio is retrieved.
True
Seek all stations algorithm
Seek/Tunecomplete?
Get frequencyfrom radio
firstFreq == 0? firstFreq = frequency
Return
ReturnFalse
True
False
True
False
frequency == 10790?
Write freq and SNR to EEPROMaddress += 3Seek up
seekAll = falsesendAll = true
nextDataWrite = 5Tune radio to firstFreq
Figure 4.6: Flowchart of the subroutine: Seek all stations algorithm.
The seek command is set to stop when it reaches the upper limit of the spectrum.
Therefore it is checked whether the frequency equals 107.9 MHz, the upper limit of the
FM spectrum — indicating that the entire spectrum was searched through. If the upper
limit has not been reached yet, the frequency of the radio and its SNR is written to the
22
4.2 Details of the software
EEPROM at a predefined start address. Thereafter the radio starts to seek upwards
again. The value of the “firstFreq” variable is checked next, which will always equal zero
initially. The first frequency tuned to is therefore saved to the variable. When after
iterations of the algorithm the upper limit of the spectrum is reached, the radio is tuned
back to the first frequency. The “seekAll” flag is also set to false, stopping the iteration
of the algorithm. The “sendAll” flag is then set to true and the “nextDataWrite” flag
to 5 — indicating that all the frequencies that were validly tuned to and stored in the
EEPROM must be sent to the platform sequentially.
4.2.4 Sending data to the platform
Figure 4.7 is a flowchart of the subroutine that sends data to the platform. The “next-
DataWrite” variable serves as an index of which data needs to be sent to the platform.
The first three cases are used for sending one or more variables to the platform once. Cases
4 and 5 are used for where a set of data needs to be sent to the platform sequentially.
After data has been sent the data write index is set to -1 — which makes the program
wait for “OK” before sending any other data. The data write index is saved to another
variable before changing it so that the data can be resent in the case of a platform error.
Get frequency andSNR from radio.
Wait for GPS coords
1 (freq + SNR + coords) 2 (opState) 4 (sample)
Send the datato the platform
Return
Send reportPeriodto the platform
3 (reportPeriod)
nextDataWrite?
Send data to platform
Send opStateto the platform
Send sampleto the platform.samplesSent++
prevDataWrite = nextDataWritenextDataWrite = -1 (wait for OK)
Read freq + SNR fromEEPROM and sendit to the platform
5 (Data from EEPROM)
Figure 4.7: Flowchart of the subroutine: Send data to platform.
23
4.2 Details of the software
4.2.5 Setting up command/data handlers
Figure 4.8 is a flowchart of the subroutine that sets up the command handlers. When the
“setHandlers” flag is set to true, the different handlers are set up according to the current
handler number, which will always be 1 initially. After the AT command to set a handler
up has been sent to the modem, the “handlerSet” flag is set to true. When the “OK” from
the modem is received, the flag is set to true again and the handler number variable is
incremented by one. This is done in the subroutine that processes the modem responses.
The next handler is set up each time the subroutine is entered until the handler number
reaches 5, in which case it is reset to 1 and the “setHandlers” flag is set to false — thus
finishing the operation.
1 5
Set handler forperformFHT
Set handler forreportEvery
Set handler forseekAll
Set handler fortuneTo
handlerSet = falsesetHandlers = false
handlerNo = 1
Return
2 4
Set up command/data handlers
3
handlerNo?
Figure 4.8: Flowchart of the subroutine: Set up command/data handlers.
4.2.6 Implementation of the libraries
The Arduino FHT library developed by Open Music Labs is used to estimate the spectrum
of the radio’s audio output. The library is used without any alterations. Due to memory
constraints, only a 32-point FHT can be performed by the system.
A function was written that performs a single conversion. It starts by taking the
32 audio samples from the AVR’s ADC and storing it in the input array used by the
functions of the library. Four different functions are then called sequentially to obtain
an output. The input data is first multiplied with a window function to increase the
frequency resolution. Next the data is reordered for the way in which the FHT algorithm
processes the data. The data is then processed by the FHT algorithm and the resulting
frequency bins are stored in the same array. To get useful data from the bins, a function
is called that calculates the logarithmic magnitude of the bins scaled over an 8-bit range.
24
4.3 The platform and dashboard
The output values are stored in a separate array that only has 16 bins, since the second
half of the result is the mirror of the first half [2].
To try to estimate the audio spectrum, the results of 250 sequentially performed single
conversions are summed in a separate array and afterwards divided by 250 to obtain an
average. Although averaging the spectrum over a longer period would be give a better
estimate, once again the available memory is a constraint.
The Si4735 shield is provided with a simple library made by Sparkfun that can be used
to get the radio operational with an Arduino. An improved version of the library coded
by an Arduino hobbyist was used as a base to work from. The library was developed for
a dedicated radio player project using the Si4735 shield. As such a lot of unnecessary
features were stripped from the library to conserve memory.
The amount of flash memory the AVR has is sufficient for writing a lot of code and
using many libraries, but the amount of SRAM that can be used for variables is a con-
straint. Therefore the SRAM usage needs to be carefully calculated and optimized. As
such lookup tables that can be stored in the flash memory are used whenever possible.
Links to the project’s source code, the altered libraries and the original libraries are
provided in appendix F.
4.3 The platform and dashboard
Figure 4.9 is a screenshot of the dashboard that was made for the system on the SMART
Sight platform. The dashboard is meant to serve as an easy way for someone — with a
limited knowledge of the platform and system — to control the system and view the data
that it is collecting.
At the top of the dashboard the system’s current operating state is represented as a
colour and the last reported frequency and SNR is also displayed. The colours representing
the different operating states are grey (idle), green (monitoring) and yellow (sampling or
seeking). It is recommended to wait until the system is finished sampling or seeking before
sending a command. Therefore when the operating state is yellow, the user must wait
until it turns green again.
In the middle of the dashboard are two turn-knobs and two switches in a row. These
interactive elements can be used to send the four different commands. When one of the
turn-knobs has been set to a new value or one of the switches has been changed, the
command is submitted by clicking on the orange button at the top labelled: “Submit
Changes”.
Below the turn-knobs is a graph that displays the monitored frequencies reported by
the system. Next to it is a graph displaying the magnitudes of the frequency bins obtained
from the FHT operation. These graphs do not immediately show data as it is received.
There is always a delay before the data is displayed and some values appear twice in a
25
4.3 The platform and dashboard
row. Current data with their timestamps can be viewed by clicking on the data heading
on the platform if needed.
Lastly at the bottom of the dashboard an embedded google map is shown displaying
the last reported location of the system. But since the system currently does not have a
GPS receiver, a dummy location is displayed.
Figure 4.9: Screenshot of the dashboard on the SMART Sight platform.
26
Chapter 5
Tests
5.1 Testing of FM reception and radio control
The objective of this test is to determine whether the FM receiver is functioning and if it
can be controlled by the microprocessor.
5.1.1 Hypothesis
The Si4735 FM receiver can receive and demodulate signals in the 87.5–108 MHz frequency
range and output an audio signal. The AVR can tune the receiver to a specified frequency
by writing a command byte to the Si4735 on the SPI bus. The receiver can also seek for
a valid signal when given the command.
5.1.2 Test design
This test is done with the debug version of the program where a software serial port is used
for communicating with the modem. The hardware serial port is used for communicating
with a computer.
1. The Uno board is connected to a computer through an USB port.
2. A speaker is connected to the audio output jack of the Si4735 shield to be able to
listen to the received radio station.
3. A hyper-terminal is used to connect the computer to the AVR at a baud rate of
9600 (8-N-1).
4. The character ‘S’ is sent to the AVR to command the radio to seek up. The audio
output from the speaker is listened to to hear when it finds a station.
5. The character ‘g’ is sent to the AVR to see which frequency the radio is tuned to.
A 4 or 5 digit integer should be returned on the serial port that is in the unit of
×104 Hz.
6. The character ‘q’ is sent to the AVR to see information about the received signal
quality.
27
5.2 Testing of the modem’s serial interface
7. The character ‘s’ is sent to the AVR to command the radio to seek down. After the
radio is finished seeking, ‘g’ and ‘q’ is sent to the AVR to see the tuned to frequency
and received signal quality metrics.
5.1.3 Result
The green LED on the Uno board labelled “ON” switched on after connecting the Uno
to the computer’s USB port. Noise came out of the speaker after connecting it to the
Si4735 shield. The terminal successfully connected to the AVR at a baud rate of 9600.
Table 5.1 lists the results of sending the different characters to the AVR sequentially.
Table 5.1: Results of sending different characters to the AVR sequentially.
Charactersent
Result
‘S’ The speaker went silent for a moment until a radio station couldbe heard playing.
‘g’ “10360” was printed to the terminal.‘q’ “SNR: 10 dB, RSSI: 23 dBuV, Freq offset: -1 kHz” was printed to
the terminal.‘s’ The speaker went silent again until another radio station could be
heard playing.‘g’ “9260” was printed to the terminal.‘q’ “SNR: 7 dB, RSSI: 34 dBuV, Freq offset: -7 kHz” was printed to
the terminal.
The FM reception and control of the radio clearly functions correctly as expected.
The test was thus successful.
5.2 Testing of the modem’s serial interface
The objective of this test is to determine whether the AVR and modem is communicating
correctly through the UART serial interface.
5.2.1 Hypothesis
The modem’s UART is based on the RS-232 standard and the AVR’s UART operates
on TTL voltage levels. The MAX3323 IC converts the voltage levels of the receive and
transmit signals between the two devices, enabling the correct interpretation of bits.
5.2.2 Test design
This test is performed with the debug version of the program where a software serial
port is used for communicating with the modem. The hardware serial port is used for
communicating with a computer.
28
5.3 Test sending of data to the platform
1. The Uno board is connected to a computer through an USB port and the modem
is powered with 12V DC and connected to the Uno board.
2. A hyper-terminal is used to connect the computer to the AVR at a baud rate of
9600 (8-N-1). If necessary, the terminal is set to terminate messages with a CR.
3. The character ‘>’ is sent to the AVR. “Modem mode:” should be returned to the
terminal. The AVR should then send all characters (except ‘<’) it receives from the
computer to the modem and vice versa.
4. The string, “at”, is sent through the terminal. If “at” and “OK” is received, the
AVR and modem are communicating successfully.
5. Lastly a long string of characters is sent to see if the modem echoes all of them back
correctly.
5.2.3 Result
The Uno’s green LED switched on after connecting the board to the computer. After
connecting the modem to a 12V power supply, the green LED on the modem switched on
for a few seconds before it starting flashing slowly. The terminal successfully connected
to the AVR at a baud rate of 9600. Table 5.2 lists the results of sending the different
characters to the AVR sequentially.
Table 5.2: Results of sending different characters to the AVR sequentially.
Character sent Result‘>’ “Modem mode:” was printed to the terminal.“at” “at” and “OK” was each printed on a new line to
the terminal.“abcdefghijklmnopqrstw” “abcdefghijklmnopqrstw” was printed to the ter-
minal.
The results of the test indicate that the AVR and modem is communicating correctly
through their UART serial interface.
5.3 Test sending of data to the platform
The objective is to test whether the system can send data to the platform through the
modem.
5.3.1 Hypothesis
The AVR can send a data write AT command to the modem through the serial interface.
The modem identifies data variable names and their given values from the AT command’s
parameters and tries to send the data to the platform via the GSM network. If the the
modem succeeds in interpreting and sending the data, it sends an “OK” back to the AVR.
29
5.4 Testing reception of data from the platform
5.3.2 Test design
This test is performed with the debug version of the program where a software serial
port is used for communicating with the modem. The hardware serial port is used for
communicating with a computer.
1. The Uno board is connected to a computer through an USB port and the modem
is powered with 12V DC and connected to the Uno board.
2. A hyper-terminal is used to connect the computer to the AVR at a baud rate of
9600 (8-N-1).
3. After waiting for the message “Connection up!”, followed by die handlers being set
up, the character ‘G’ is sent to the AVR. The AT command to send the current
frequency and SNR is sent to the modem. The echo of the string and resulting
“OK” should be printed to the terminal.
4. The dashboard of the system is viewed at smart.trintel.co.za. The frequency
and SNR that was sent should be displayed. Under the displayed SNR the time of
the last update of the variable is shown.
5.3.3 Result
The Uno board and modem switched on and the terminal successfully connected to the
AVR. After “Connection up!” was printed to the terminal, ‘G’ was sent to the AVR.
Thereafter the following was printed to the terminal:
9260at+awtda=d,radio.status,2,“freq,INT32,9260”,“SNR,INT32,8”OK
The dashboard of the system was viewed in the browser. The “current tuned to frequency”
displayed was 92.6 MHz and the “SNR of station” displayed was 8 dB. The time of the
last update shown under the displayed SNR was 6:04 PM, which is the time when the
data was sent. The data was thus successfully sent from the modem to the platform.
5.4 Testing reception of data from the platform
The objective is to test whether jobs that are scheduled on the platform are executed and
if the data is received by the system.
5.4.1 Hypothesis
Command or data writing jobs scheduled on the Airvantage Operating Portal at platform.
trintel.co.za, is sent immediately after data is received from an asset — ensuring the
data is sent while the asset has a connection.
30
5.5 Testing the dashboard and execution of commands
5.4.2 Test design
This test is performed with the debug version of the program where a software serial
port is used for communicating with the modem. The hardware serial port is used for
communicating with a computer.
1. The Uno board is connected to a computer through an USB port and the modem
is powered with 12V DC and connected to the Uno board.
2. A hyper-terminal is used to connect the computer to the AVR at a baud rate of
9600 (8-N-1).
3. After waiting for the message “Connection up!”, followed by the handlers being set
up, the “reportEvery” command is sent from the Operating Portal with a integer
given as parameter.
5.4.3 Result
After connecting with the terminal to the AVR, “Connection up!” followed by the echoed
AT commands that set up the command handlers were printed to the terminal. Thereafter
the “reportEvery” command was sent from the Operating Portal with “60” as parameter.
The system sent its operating state as it periodically does and the command was received.
The following lines were printed on the terminal:
at+awtda=d,radio.status,1,“state,INT32,2”OKCommand or data:+AWTDA: c,534991,radio,reportEvery,INT32,60,CRC96at+awtda=a,radio,534991OK
The fourth line starting with “+AWTDA” is the unsolicited response from the modem that
contains the data received from the platform. The last AT command is the acknowledge
of receiving the command that must be sent to the platform. On the platform the state
of the command was shown as “DONE” after the acknowledge was sent. The data was
thus successfully received and the platform could mark the command as done.
5.5 Testing the dashboard and execution of commands
The objective is to test whether the four different commands can be sent from the inter-
active dashboard and be executed successfully by the system. The system is designed to
execute only one command at a time and therefore each command is tested independently.
31
5.5 Testing the dashboard and execution of commands
5.5.1 Hypothesis
There are four different commands that can be sent from the dashboard or Operating
Portal which the system can execute. The commands with their parameters and resulting
system actions are listed in table 5.3.
Table 5.3: Details of the commands that can be sent to the system.
Commandname
ParameterName Type Restriction Result or action
tuneTo frequency integer 8750–10790 The system tunes the radio to thespecified frequency.
reportEvery minutes integer 0–240 The reporting period is changed tothe specified minutes.
seekAll on/off string true/false The FM spectrum is scannedthrough to find all the stations.
fftSamples bool string true/false A 32-point DFT is obtained from anaveraged audio sample of the radio.
5.5.2 Test design
This test is performed with the normal operating program of the system. Therefore the
system can not be connected to a computer and it must be powered from a power supply.
1. The system is powered from a 12V DC source and a speaker is connected to the
radio’s audio output. Listening to the radio is a means of confirming that the system
is operational.
2. The communications status of the asset is checked on the SMART platform and
waited for until it turns green.
3. (a) The dashboard is opened on the SMART platform and under the heading:
“Tune to different frequency”, the knob is turned to another frequency than
the currently displayed frequency. After setting the frequency to where a radio
station is known to be, the command is submitted by clicking on the orange
button with the title “Submit Changes”.
(b) The radio is listened to until it is heard tuning to another frequency, after
which the refresh button is pressed on the dashboard. The displayed frequency
and its SNR should be updated to the frequency that the command was set to.
4. (a) Under the heading: “Report in period”, the knob is set to 5 minutes and the
command is submitted by clicking on the orange button. The current time is
noted.
(b) After waiting for at least 5 minutes, the dashboard is refreshed and the time
displayed under the SNR of the last update is checked. The time should be 5
minutes after the command was sent.
32
5.5 Testing the dashboard and execution of commands
5. (a) The “Find all stations” switch is set to “ON” and the command is submitted.
(b) The dashboard is continuously refreshed to see how the operating state colour
turns yellow and later back to green when the operation is completed.
6. (a) The “Perform FFT” switch is set to “ON” and the command is submitted.
(b) The dashboard is continuously refreshed to see how the operating state colour
turns yellow and later back to green when the operation is completed.
5.5.3 Result
The system was given power and a speaker was connected to the radio. The communica-
tion status of the asset was already green when it was checked on the platform. Table 5.4
list the times at which each command was submitted on the dashboard, what the results
were and when they occurred.
Table 5.4: The results of sending each command to the system.
Current frequencyand SNR
Command(parameter)
Submittedat
Results
92.6 MHz, 22 dB tuneTo(10360)
10:16 PM Radio tuned to different station. Datareported in at 10:16 PM: 103.6 MHz, 17dB.
103.6 MHz, 17 dB reportEvery(5)
10:17 PM Command state changed to “DONE”under Jobs within a minute. Report pe-riod of 5 received back at 10:18 PM.Data reported in at 10:22 PM: 103.6MHz, 19 dB.
103.6 MHz, 19 dB seekAll(true)
10:23 PM Operating state changed to yellow andthe following values were received withina minute, whereafter operating statechanged back to green:
Frequency (×104 Hz) SNR (dB)9260 159410 69600 89740 510090 910360 1410450 219260 19
92.6 MHz, 19 dB fftSamples(true)
10:25 PM Operating state changed to yellow andthe following sample values were re-ceived within two minutes, whereafteroperating state changed back to green:231, 216, 128, 105, 91, 79, 70, 64, 55, 49,41, 35, 35, 24, 19, 24.
33
5.6 Determining the validity of the FHT operation
From the results it is clear that all four commands can be sent from the dashboard
and that each one executes as expected.
5.6 Determining the validity of the FHT operation
The objective of this test is to determine whether the FHT operation provides a good
approximation of the audio signal spectrum. The goal is to be able to distinguish between
silence and speech or music being broadcast by looking at the audio signal spectrum.
5.6.1 Hypothesis
The AVR’s ADC samples the audio output of the radio at a rate of 38 kHz. A 32-point
FHT is performed — giving 16 frequency bins. The AVR averages the outputs of 250
FHT operations over approximately 1 second. This should enable seeing a distinction in
the spectrum between silence, noise and speech or music.
5.6.2 Test design
This test is performed with the normal operating program of the system. Therefore the
system can not be connected to a computer and it must be powered from a power supply.
1. The system is powered from a 12V DC source and a speaker is connected to the
radio’s audio output.
2. The communications status of the asset is checked on the SMART platform.
3. A program named Audacity, is used to generate and play an audio tone on a com-
puter. The audio output of the computer is connected to the ADC where the audio
output of the radio is normally connected.
4. On the dashboard the “Perform FFT” switch is set to “ON” and the command is
submitted.
5. The dashboard is continuously refreshed to see how the operating state changes and
thus when the operation is completed.
6. A silent audio signal is generated and played using Audacity. Steps 4 and 5 are
repeated.
7. The radio’s audio output is connected to the ADC again. Steps 4 and 5 are repeated.
8. The frequency bins obtained from the three different audio signals are compared.
5.6.3 Result
Figure 5.1 is a plot of the frequency bins obtained from the three different audio signals.
Although there is severe spectral leakage, the 9.5 kHz tone can still be identified, proving
34
5.7 Overall system test
0 10 200
20
40
60
80
100
120M
agnitude
Silence
0 10 200
20
40
60
80
100
120Radio
Frequency (kHz)
0 10 200
20
40
60
80
100
1209.5 kHz tone
Figure 5.1: The frequency spectrograms of three different audio signals.
that the FHT operation is valid. A difference in the magnitude of the bins can also be
seen between the silent signal and general speech and music from the radio.
The test indicates that the FHT operation can be used to distinguish between silence
and speech or music being broadcast on a carrier. There is no need to distinguish white
noise when no carrier is present at a frequency, since the SNR would be 0 anyway. The
argument is that when a radio station is not active at certain times, they might still be
transmitting an empty carrier — therefore the need to distinguish between silence and
speech or music.
5.7 Overall system test
The objective is to test the overall functionality of the system. This is done by testing
the capability of the system to collect and send data autonomously.
5.7.1 Hypothesis
By setting a schedule on the platform to periodically send the “seekAll” command, the
system can scan through the FM spectrum every few minutes and collect data on the
stations it finds. Using a GPS receiver while driving with the system in a car, it can be
determined which stations are broadcast in different areas.
5.7.2 Test design
This test is performed with the normal operating program of the system. Therefore the
system can not be connected to a computer and it must be powered from a power supply.
1. The system is set up in a car powered with 12V DC from the cigarette lighter socket
of the vehicle.
35
5.7 Overall system test
2. The radio’s audio output is connected to the auxiliary input of the car’s audio
system. Listening to the radio is the only indication of whether the system is
operational while driving.
3. A Garmin GPS is set up and switched on in the car.
4. On the AirVantage Operating Portal the “seekAll” command is scheduled to be sent
every 5 minutes.
5. After making sure every thing is working as expected, a long circle route is driven
in order to come within range of different radio stations.
5.7.3 Result
The AVR and modem were both powered from the car’s cigarette lighter successfully.
The Garmin GPS was switched on and it acquired the signal from the satellites. The
“seekAll” command was scheduled to be sent every 5 minutes from 19:30 to 21:00 on the
27th of October, 2012. A predetermined route was driven after waiting for the system
to perform the first “seekAll” command and checking that it was sending sensible data
to the platform. Figure 5.2 shows the circle route that was driven from Stellenbosch to
Brackenfell, Delft, Somerset West and back. The yellow pins are the GPS coordinates
logged at the estimated times when the “seekAll” command was performed.
Figure 5.2: The route that was driven for the overall system test.
Table E.1 in Appendix E contains all the data that was sent to the platform between
19:30 and 20:45 when the test was completed. The only way to link a SNR to a frequency
36
5.8 System reliability test
on the platform is by the timestamp of when it was received. Since the smallest interval
in the timestamp is a second, the system deliberately waits at least one second between
sending each frequency and its SNR. Note that the timestamp of the GPS coordinates
of each scan is earlier than the first data timestamp. This is because all the data is
saved to the EEPROM and only sent after completing the scan. The time at which the
scan was performed cannot be determined and therefore it is assumed that it was done a
few seconds before the first frequency and SNR was sent to the platform. If the system
operates with its own GPS receiver as it was designed for, the current coordinates will be
directly tied to a station when it is found — therefore eliminating the need to save GPS
timestamps.
As can be seen from the timestamps, the system did not perform a scan exactly every
5 minutes. This is due to the modem loosing its connection intermittently for a few
minutes at a time. The first three scans were performed as expected, but the scan that
was performed at 19:56 seemed to have searched through the spectrum at least four times.
This revealed a flaw in the algorithm that was not foreseen. How the algorithm works
after the flaw was corrected is as it is explained in section 4.2.3.
To determine when the entire spectrum was searched through previously, the system
checked whether the station’s frequency equalled the first frequency that was tuned to and
not the upper limit of the FM spectrum. It was done this way because the seek command
was set to wrap back around to the bottom of the FM spectrum when it reached the
upper limit. This method works consistently when the system is stationary, but clearly
not when the system is moving at a high speed in a car. In the time the system searches
through the spectrum it is possible that the first station that was found cannot be picked
up again. Presumably this happens as the system is displaced quite a distance within the
time it takes to search. Thus due to the path of the signal being different, the SNR of
the first station that was found could fall below the seek threshold of 3 dB.
At 20:13, 20:28 and 20:33 only the bottom frequency of the spectrum, 87.5 MHz, with
a SNR of 0 dB was sent each time. This is unexpected as the radio clearly received
the command to seek, but would not have stopped at 87.5 MHz if the SNR was 0 dB.
Presumably no stations could be picked up at the time when the command was performed.
The test was successful as it demonstrated that the system can be practically put to
use, even if it might still have some flaws. The test also revealed an unforeseen flaw that
was easily corrected.
5.8 System reliability test
The objective of this test is to ascertain if the system can operate reliably for a long
period of time. This is done by letting the system operate autonomously for a few days
without any human interference.
37
5.8 System reliability test
5.8.1 Hypothesis
By setting a schedule on the platform to periodically send the “seekAll” command, the
system can scan through the FM spectrum every hour and collect data on the stations it
finds. The system is able to operate consistently without any human interference.
5.8.2 Test design
This test is performed with the normal operating program of the system. Therefore the
system can not be connected to a computer and it must be powered from a power supply.
1. The system is powered from a 12V DC source.
2. The communications status of the asset is checked on the SMART platform.
3. On the AirVantage Operating Portal the “seekAll” command is scheduled to be sent
every hour for 72 hours.
5.8.3 Result
Figure 5.3 is a graph of the SNR reported of different frequencies every hour from 16:00,
Thursday, the 1st of November till 16:00, Sunday, the 4th of November.
The system successfully performed the “seekAll” command every hour for 3 days
without any human interference. Therefore the test indicates that the system is reliable.
Figure 5.3: The SNR of the frequencies found over 3 days of autonomous operation.
38
Chapter 6
Conclusion
6.1 Objectives achieved
The proposed system was successfully designed and built. The minimum requirements
were met and some extra functionality was added such as the FHT operation. The system
can tune to a specified FM radio station or it can scan through the spectrum and find
stations automatically. The system can also send and receive data via the GSM network.
The system should provide an adequate solution to the MDDA’s problem of remotely
determining whether community radio stations are transmitting. The MDDA can place
the system in a remote location where they need to monitor certain stations. They can
also place it in a vehicle that can drive around in order to determine the range of a
community radio station.
The system is easy to use and is reliable enough to operate consistently as long as it
has power. In its enclosure it is fairly robust and weatherproof.
The project demonstrates the potential of the Trinity Telecomms SMART Sight plat-
form. The strength of the platform is its ease of use and immediately data access. An
elegant dashboard can be quickly created with the user friendly tools. The platform re-
moves the need to create a custom web-based UI for an M2M system and therefore reduces
development time. After receiving training from Trintel on how to use the platform, we
were able to provide feedback about the training to them.
6.2 Possible improvements
Various improvements can be made to the current system. Firstly, a working GPS re-
ceiver can be added and the operating program can be modified to report the system’s
coordinates to the platform. The GPS coordinates can be sent along with the radio’s
frequency and SNR.
To enable the system to operate in a remote outside location, a battery and a small
solar panel with a charging circuit could be added. It is simple to implement, but it will
increase the system’s cost.
39
6.3 Future work
A way for the AVR to detect whether there is a fault with the radio or GPS receiver
could be investigated. This would improve the reliability of the system, as a warning
event could then be sent to the platform. The platform would then be able to notify a
person by email or SMS of the event.
6.3 Future work
If the MDDA or another organisation wants to use the system for radio monitoring, they
would most likely need to have many of them. The prototype system can be developed
into a more elegant and compact hardware design that can be produced fairly cheaply.
This would entail integrating all the hardware, except the modem, onto a single PCB that
can be securely mounted in a weatherproof enclosure.
40
References
[1] Sparkfun Electronics, SI4735 Shield-v12, https://www.sparkfun.com/products/
10342, 2011–04–19. [Accessed 2012–10–25]. vii, 16
[2] Open Music Labs, Arduino FHT Library, http://wiki.openmusiclabs.com/wiki/
ArduinoFHT, September 2012. [Accessed 2012–10–15]. viii, 8, 25
[3] Parliament of the Rebuplic of South Africa, Regulations in terms of section 22 of
the Media Develpoment and Diversity Agency Act, vol. 460, (Pretoria), Government
Gazette, October 2003. 1
[4] Arduino, Home page, http://arduino.cc/en/. [Accessed 2012–10–05]. 3
[5] Arduino, Arduino Uno, http://arduino.cc/en/Main/ArduinoBoardUno/. [Accessed
2012–10–05]. 4
[6] Sierra Wireless, AirLink GL61x0 programmable modem, http://www.
sierrawireless.com/en/productsandservices/AirLink/Programmable_Modems/
GL6100_GL6110.aspx. [Accessed 2012–10–25]. 5
[7] Sierra Wireless, AT Commands Interface Guide for Firmware 7.45, 18 February 2011.
5
[8] Sierra Wireless, Sierra Wireless AirVantage Platform, Brochure, 2010. 6
[9] R. Bracewell, “Discrete hartley transform,” JOSA, vol. 73, no. 12, pp. 1832–1835,
1983. 7
41
Appendix A
Project planning schedule
42
ID Task Name Duration
1 Component selection 38 days2 Determine suitability of given
Arduino board4 days
3 Select FM receiver 2 days4 Select GPS receiver 2 days5 Select enclosure 1 day6 Component orders 43 days7 FM receiver 7 days8 GPS receiver 21 days9 Enclosure 7 days
10 Design 21 days11 Overall system design 7 days12 GPS shield 7 days13 Circuit for GPS module 2 days14 PCB layout for GPS 5 days15 Fabrication of GPS PCB 7 days16 Mount system in enclosure 2 days17 Trintel training 2 days18 Software development 43 days19 Radio control 6 days20 Modem control 12 days21 Automation of system, data
reception and sending18 days
22 Seek all algorithm 8 days23 Implementaion of DFT 8 days24 Parsing of GPS messages 8 days25 Dashboard development 8 days26 System testing 21 days27 Report writing 27 days28 Draft (Introduction,
background info, system and detail design)
14 days
29 Draft evaluation by study leader
7 days
30 Test chapter 7 days31 Editing after feedback, writing
conclusion and finalising report.
6 days
E B M E B M E B M E B M E BJuly August September October November
Task
Split
Milestone
Summary
Project Summary
External Tasks
External Milestone
Inactive Task
Inactive Milestone
Inactive Summary
Manual Task
Duration-only
Manual Summary Rollup
Manual Summary
Start-only
Finish-only
Deadline
Progress
Page 1
Project: JarrettDate: Sun 12/11/04
Figure A.1: Gannt chart of the project.
43
Appendix B
Project specification
44
Appendix C
Outcomes compliance
ECSA Exit Level Outcomes Reference
Outcome ReferenceSections Pages
1. Problem solving: Demonstrate competenceto identify, assess, formulate and solve conver-gent and divergent engineering problems cre-atively and innovatively.
1, 3, 4.1, 4.2,5.6 & 5.7
1–2, 9–25, 34–37
2. Application of Scientific and EngineeringKnowledge: Demonstrate competence to ap-ply knowledge of mathematics, basic scienceand engineering sciences from first principlesto solve engineering problems.
2.4, 4.1, 4.2 &5.6
7–8,13–25,34–35
3. Engineering Design: Demonstrate com-petence to perform creative procedural andnon-procedural design and synthesis of com-ponents, works, products and processes.
3 & 4 9–26
4. Investigations, experiments and data anal-ysis: Demonstrate competence to design andconduct investigations and experiments.
5 27-38
5. Engineering methods, skills and tools,including information technology: Demon-strate competence to use appropriate engineer-ing methods, skills and tools, including thosebased on information technology.
3, 4 & 5 9–38
6. Professional and technical communication:Demonstrate competence to communicate ef-fectively, both orally and in writing, with engi-neering audiences and the community at large.
All All
9. Independent learning ability: Demonstratecompetence to engage in independent learningthrough well developed learning skills.
1.1, 2, 3, 4, 5.6& 5.7
1, 3–26,34–37
45
Appendix D
Circuit diagram and PCB layout
Figure D.1: Circuit diagram of the 2nd revision Arduino Uno board.
46
23 1
GPS_MODULE
R1R2
Q2
R3
R4R5
R6R7
R8R9
R10
U$1
JP1
LED1
T1
R12
R13
C1
C2
C3C4
C5
C7
C6
C8
(a) Top layer
23 1
GPS_MODULE
R1R2
Q2
R3
R4R5
R6R7
R8R9
R10
U$1
JP1
LED1
T1
R12
R13
C1
C2
C3C4
C5
C7
C6
C8
(b) Bottom layer
Figure D.2: PCB layout of the GPS shield.
47
Appendix E
Data collected during testing
Table E.1: Data collected and sent to the platform during the overall system test.
GPS timestamp GPS coordinates Data timestamp Frequency(×104 Hz)
SNR(dB)
19:32:40 S33.92929 19:31:30 9260 26E18.86620 19:31:32 9410 15
19:31:33 9600 719:31:35 10090 2619:31:37 10450 1919:31:37 9260 29
19:37:41 S33.92958 19:36:31 8780 6E18.86684 19:36:33 9090 11
19:36:35 9260 3419:36:38 9410 1619:36:40 9740 1419:36:42 10090 1219:36:44 10360 2419:36:47 10450 2019:36:48 8780 2
19:41:44 S33.92062 19:41:53 8780 10E18.85395 19:41:56 9090 18
19:41:57 9410 2319:41:59 9600 419:42:01 9740 1819:42:03 10090 819:42:05 10360 3319:42:06 8780 21
19:56:14 S33.85729 19:56:24 8820 8E18.69670 19:56:26 8900 8
19:56:28 8950 119:56:30 9130 1919:56:32 9210 2719:56:34 9300 2419:56:37 9450 27
Continued on next page
48
Table E.1 – continued from previous pageGPS timestamp GPS coordinates Data timestamp Frequency SNR
19:56:38 9530 2219:56:40 9580 719:56:42 9620 3019:56:46 9710 519:56:47 9780 3519:56:49 9820 419:56:51 9860 2619:56:53 9890 2319:56:55 9910 919:56:57 9950 3219:56:58 10040 2619:57:00 10130 2819:57:02 8900 819:57:04 9780 3519:57:06 10400 2819:57:07 8820 2019:57:08 8900 1319:57:09 8950 1119:57:11 9130 1619:57:13 9210 1619:57:15 9300 2419:57:16 9300 1919:57:18 9530 1819:57:20 9600 419:57:22 9620 2019:57:23 9780 2219:57:25 9860 2419:57:27 9890 2719:57:28 9950 2319:57:30 10040 1619:57:32 10130 2219:57:34 9950 3219:57:35 10210 1719:57:39 10300 2719:57:40 10400 2419:57:42 10490 3119:57:44 10570 1719:57:45 10660 2219:57:47 10750 1919:57:48 8820 27
20:03:06 S33.95767 20:03:08 8820 16E18.65685 20:03:11 9130 15
20:03:13 9210 1020:03:15 9300 1320:03:17 9450 15
Continued on next page
49
Table E.1 – continued from previous pageGPS timestamp GPS coordinates Data timestamp Frequency SNR
20:03:19 9530 1520:03:21 9600 520:03:22 9620 1420:03:25 9780 2520:03:28 9860 2320:03:35 9890 2120:03:37 9950 2320:03:39 10040 1120:03:41 10130 2020:03:42 10210 1620:03:44 10300 1720:03:46 10400 1620:03:47 10490 2520:03:49 10570 1220:03:52 10660 720:03:52 8820 16
20:09:12 S34.02788 20:09:10 9620 15E18.69470 20:09:11 9620 20
20:13:54 S34.05926 20:13:54 8750 0E18.77881 20:13:55 8750 0
20:22:30 S34.06867 20:23:54 8900 8E18.82262 20:23:55 9210 20
20:23:57 9530 1820:23:59 9820 720:24:01 9860 2720:24:03 10210 2920:24:05 10570 1020:24:07 8900 5
20:28:21 S34.06894 20:28:24 8750 0E18.82266 20:28:25 8750 0
20:33:47 S34.01931 20:33:54 8750 0E18.82036 20:33:55 8750 0
20:43:58 S33.93213 20:43:59 8780 3E18.85971 20:44:01 9090 20
20:44:02 9210 520:44:04 9260 1720:44:06 9410 2320:44:08 9530 420:44:09 9740 2220:44:11 9860 920:44:13 10090 2420:44:14 10210 1020:44:16 10360 2520:44:18 10450 2020:44:19 8780 14
50
51
Appendix F
Source code and libraries
Project source code — https://www.dropbox.com/sh/e7yg88wl0kxbgn8/Y-qa3OIm_8
Arduino Si4735 Library developed by Jon Carrier — https://github.com/jjcarrier/
Si4735
Arduino FHT Library developed by Open Music Labs — http://wiki.openmusiclabs.
com/wiki/ArduinoFHT?action=AttachFile&do=get&target=ArduinoFHT.zip
51