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


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.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


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


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


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


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


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.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


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.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


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


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.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.


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


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.


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







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

smart.trintel.co.za

platform.trintel.co.za

platform.trintel.co.za

5.5 Testing the dashboard and execution of commands

5.4.2 Test design







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.


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.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. (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



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.


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



1. The system is set up in a car powered with 12V DC from the cigarette lighter socket

of the vehicle.

35


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.


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.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



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

https://www.sparkfun.com/products/10342

https://www.sparkfun.com/products/10342

http://wiki.openmusiclabs.com/wiki/ArduinoFHT

http://wiki.openmusiclabs.com/wiki/ArduinoFHT

http://arduino.cc/en/

http://arduino.cc/en/Main/ArduinoBoardUno/

http://www.sierrawireless.com/en/productsandservices/AirLink/Programmable_Modems/GL6100_GL6110.aspx



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

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

https://www.dropbox.com/sh/e7yg88wl0kxbgn8/Y-qa3OIm_8

https://github.com/jjcarrier/Si4735

https://github.com/jjcarrier/Si4735

http://wiki.openmusiclabs.com/wiki/ArduinoFHT?action=AttachFile&do=get&target=ArduinoFHT.zip

http://wiki.openmusiclabs.com/wiki/ArduinoFHT?action=AttachFile&do=get&target=ArduinoFHT.zip

Radio Station Monitor - Stellenbosch University

Documents

Transcript of Radio Station Monitor - Stellenbosch University