Design Document

Cell Phone Based Remote Home Control System
May-06-13
Design Document
Client:
ECpE Department
Advisor:
Prof. Ahmed Kamal
Team:
Arturo Palau (EE)
Chau Nguyen (EE)
Issa Drame (EE)
Adam Mohling (CprE)
REPORT DISCLAIMER NOTICE
DISCLAIMER: This document was developed as a part of the requirements of an
electrical and computer engineering course at Iowa State University, Ames, Iowa.
This document does not constitute a professional engineering design or a
professional land surveying document. Although the information is intended to be
accurate, the associated students, faculty, and Iowa State University make no
claims, promises, or guarantees about the accuracy, completeness, quality, or
adequacy of the information. The user of this document shall ensure that any
such use does not violate any laws with regard to professional licensing and
certification requirements. This use includes any work resulting from this studentprepared document that is required to be under the responsible charge of a
licensed engineer or surveyor. This document is copyrighted by the students who
produced this document and the associated faculty advisors. No part may be
reproduced without the written permission of the senior design course
coordinator.
Submission Date
November 3, 2005
Table of Contents
1.
INTRODUCTORY MATERIALS......................................................................................... 1
1.1. EXECUTIVE SUMMARY.........................................................................................................1

1.2. ACKNOWLEDGEMENTS..........................................................................................................3
1.3. PROBLEM STATEMENT..........................................................................................................3
1.3.1. GENERAL PROBLEM STATEMENT....................................................................................3
1.3.2. GENERAL SOLUTION APPROACH......................................................................................3
1.4. OPERATING ENVIRONMENT...................................................................................................3
1.5. INTENDED USERS AND INTENDED USES..............................................................................4
1.6. ASSUMPTIONS AND LIMITATIONS..........................................................................................4
1.6.1. ASSUMPTIONS LIST..........................................................................................................4
1.6.2. LIMITATIONS LIST...............................................................................................................5
1.7. EXPECTED END PRODUCT AND OTHER DELIVERABLES....................................................5
2.
APPROACH AND PRODUCT DESIGN RESULTS........................................................ 6
2.1. APPROACH USED..................................................................................................................6

2.1.1. DESIGN OBJECTIVES.......................................................................................................6
2.1.2. FUNCTIONAL REQUIREMENTS...........................................................................................7
2.1.3. DESIGN CONSTRAINTS......................................................................................................7
2.1.4. TECHNOLOGY CONSIDERATIONS.......................................................................................8
2.1.4.1. CONSIDERED CELLULAR MODULES..............................................................................8
2.1.4.2. CONSIDERED AC / DC INTERFACES...........................................................................11
2.1.4.3. CONSIDERED MICROCONTROLLERS............................................................................12
2.1.4.4. PROGRAMMING LANGUAGE CONSIDERATION.............................................................19
2.1.4.5. DEVELOPMENT ENVIRONMENTS CONSIDERED...........................................................21
2.1.4.6. CONSIDERED CODING STYLES....................................................................................22
2.1.5. TESTING............................................................................................................................23
2.1.6. PROJECT CONTINUATION................................................................................................26
2.2. DETAILED DESIGN.............................................................................................................27
2.2.1 CODING DETAILS...............................................................................................................27
2.2.2 MICROCONTROLLER DETAILS..........................................................................................31
2.2.3 GSM MODULE DETAILS...................................................................................................37
3.
ESTIMATED RESOURCES AND SCHEDULE.............................................................. 38
3.1. ESTIMATED RESOURCE REQUIREMENTS...........................................................................38

3.1.1. PERSONNEL RESOURCES................................................................................................38
3.1.2. FINANCIAL REQUIREMENTS...........................................................................................40
3.2. SCHEDULES.......................................................................................................................42
May-06-13
Senior Design
Page i
2/9/2016
TABLE OF CONTENT CONTINUED

4.
CLOSURE MATERIALS................................................................................................... 46
4.1
4.2
4.3
4.4
PROJECT TEAM INFORMATION...........................................................................................46

CLOSING SUMMARY.............................................................................................................47
REFERENCE:.........................................................................................................................47
APPENDIX..............................................................................................................................47
May-06-13
Senior Design
Page ii
2/9/2016
List of Figures
Figure 1 Overall System Flow Diagram..............................................................................................2
Figure 2 GM28 Cellular Module..........................................................................................................10
Figure 3 STK300 Starter Kit.................................................................................................................18
Figure 4 Bracket Coding Standard....................................................................................................22
Figure 5 Thermostat Control Schematic...........................................................................................31
Figure 6 - Thermostat Application Module Schematic Diagram...................................................32
Figure 7 Fan Control Schematic..........................................................................................................35
Figure 8 Fan Status Signal Circuit Schematic................................................................................36
Figure 9 Light Schematic.....................................................................................................................37
Figure 10 Original Project Schedule.................................................................................................42
Figure 11 Current Project Schedule..................................................................................................42
Figure 12 Original Project Reporting Schedule.............................................................................43
Figure 13 Current Project Reporting Schedule..............................................................................44
Figure 14 Project Development Schedule.......................................................................................45
May-06-13
Senior Design
Page iii
2/9/2016
List of Tables
Table 1 STK200 Starter Kit..................................................................................................... 13
Table 2 STK300 Starter Kit..................................................................................................... 15
Table 3 Freescale MC68HC11E9 Starter Kit...........................................................................16
Table 4 Philips 51 Plus Starter Kit..........................................................................................17
Table 5 - Personnel Effort in Hours........................................................................................... 39
Table 6 - Financial Requirements..............................................................................................41
May-06-13
Senior Design
Page iv
2/9/2016
List of Definitions
DTMF (Dual-Tone Multi-Frequency) used for telephone signaling over the line
in the voice frequency band to the call switching center.
GSM (Global System for Mobile Communications) a cellular communication
network standard.
GPRS (General Packet Radio Service) a mobile data service offered to GSM
mobile users.
JVM (Java Virtual Machine) a necessary tool that will allow execution of javabased applications on a system.
M2M (Machine to Machine) concept of communications between a device
containing some amount of data and another device that requires the use of that
data.
MSDNAA (Microsoft Developers Network Academic Alliance) a source of
software that is free to all Iowa State University students that are enrolled in the
Department of Electrical and Computer Engineering.
SMS (Short Message Service) a service available on most digital mobile
phones that permit the sending of short messages (also known as text
messaging service).
SPDT (Single Pole, Double Throw) a relay with two contacts and one switch.
This switch selects one contact by default. When energized, the switch will select
the opposite contact.
SPST (Single Pole, Single Throw) a relay with one contact and one switch. This
switch has an open circuit default position. When energized, the will assume a
closed-circuit position.
May-06-13
Senior Design
Page v
2/9/2016
1. Introductory Materials
This section is intended to give an overview of the project. Some of the questions
answered in this section include what the project is about, what problems it will
address, what solutions it will implement to resolve those problems, and who the
intended users are.
1.1. Executive Summary

This document outlines the May0613 senior design teams plan for designing
and developing a cell phone based remote home control system.
The system will allow a user to control selected devices from a cellular phone
and will be broken down in three main parts: The cellular phone (serving as a
platform for instructions and as a device status interface), the control unit
(receiving, interpreting and issuing commands), and the controlled devices.
The control unit will comprise a cellular module and a microcontroller.
The basic device control scenario will start at the cellular phone, where the
user will input a command in the form of an SMS text message. At the control
unit, the cellular module will receive the command and transmit it to the
microcontroller. The microcontroller will then interpret the command and issue
the appropriate control signal to the device to be operated. After the
command is executed, the control unit will send a completion status message
back to the cellular phone.
The main components of the control unit will be the Sony Ericsson GM28 for
the cellular module and the Atmel STK300 Starter Kit for the microcontroller.
The three controlled devices will be the Zilog Thermostat Application Module
kit, a Honeywell HT-800-19 fan and a lamp and the microcontroller
programming will be done in C programming language.
The team is projected to spend a total of 634 hours and at a rate of $10.30
per hour the labor cost is projected to be $6447.80. With a projected cost of
$429.00 on parts and materials, the total project cost is anticipated to be
$6876.80 including labor. In terms of parts, the team in working to have the
microcontroller starter kit and the cellular module donated by their respective
manufacturers, therefore the actual total cost is expected to be revised to
reflect the cost due to the donated parts.
The entire flow of data throughout the system is shown in figure 1.
May-06-13
Senior Design
Page 1
2/9/2016
Figure 1 Overall System Flow Diagram
May-06-13
Senior Design
Page 2
2/9/2016
1.2. Acknowledgements
Special thanks are extended to Professor Ahmed Kamal for his support and
mentorship towards the development and success of this project.
1.3. Problem Statement

The problem statement is broken into two sections: a general problem
statement and a general solution approach. This section will define in general
what some of the problems this project will attempt to solve using general
solution approached.
1.3.1. General Problem Statement

The objective of this project is to develop a device that allows for a user
to remotely control and monitor multiple home appliances using a
cellular phone. This system will be a powerful and flexible tool that will
offer this service at any time, and from anywhere with the constraints of
the technologies being applied. Possible target appliances include (but
are not limited to) climate control systems, security systems, lights, and
any appliance that can be controlled through an electrical interface.
1.3.2. General Solution Approach

The proposed approach for designing this system is to implement a
microcontroller-based control module that receives its instructions and
commands from a cellular phone over the GSM network. The
microcontroller then carries out the issued commands and sends the
status of a given appliance or device back to the cellular phone. For
security purposes, a means of identification and user authentication will
be implemented, and will combine caller identification with a password
authorization.
1.4. Operating Environment

The control system will include two separate units: the cellular phone, and the
control unit. There will therefore be two operating environments. The cellular
phone will operate indoors and outdoors whereas the control unit will operate
indoors within the temperature and humidity limits for proper operation of the
hardware.
May-06-13
Senior Design
Page 3
2/9/2016
1.5. Intended Users and Intended Uses

This product is aimed toward average consumers who wish to control
household appliances remotely from their cell phones provided that the
appliances are electrically controllable. Example of feasible appliances and
applications under consideration include; enable/disable security systems,
fans, lights, kitchen appliances, and adjusting the temperatures settings of a
heating/ventilation/air conditioning system.
1.6. Assumptions and Limitations

This section lays out the assumptions and limitations of the project.
1.6.1. Assumptions List

Following are the assumptions made by the team:
May-06-13
Senior Design
The user and control unit will establish communication via GSM
The cell phone and service provider chosen will support text
messaging service
The user is familiar with text messaging on their cell phone
The cell phone will support storing text message templates
within the cell phones memory
All service charges from service provider apply
The controlled appliances will have to have an electrical
interface in order to be controlled by microcontroller
The audience reading this document will have a familiarity with
engineering terms
All measurements for temperature will be on Fahrenheit scale
Page 4
2/9/2016
1.6.2. Limitations List

Listed below are client-specified limitations:
The receiver must reside in a location where a signal with

sufficient strength can be received from a GSM network
The only person who can communicate with the control module
is the person who will be successfully authenticated
Only devices with electrical controlling input ports will be

possible targets for control
The controlled devices will have I/O ports that will make
communication with the receiver possible
The receiver must have a power source (120V) attached at all

times
Operation of the control unit is only possible through a cell

phone with SMS messaging capabilities
The control unit must be able to receive and decode SMS

messages.
1.7. Expected End Product and Other Deliverables

The following is a list of expected end products and other deliverables:
A single M2M controller module that can perform the following:

o Receive and parse command instructions from a
messaging device on a communication network
o Monitor a device status from an electronic interface
o Control target devices through an electrical interface
A list of approved message input commands that the device is

capable of executing
Develop a user manual for reference by the end user
A project plan and this design document will be written to

defined and outline project approaches and deliverables
Project poster is required to showcase the project to students

and faculty members
Design document is required to outline our technical

requirements and systems functionalities
Final report is required for documentation on the overall project,

including; end results, success, failures, etc
May-06-13
Senior Design
Page 5
2/9/2016
2.
Approach and Product Design Results
The approach that will be taken by the team and the step-by-step process of the
design of the end-product are described in this section. Some of the major
portions of this project and course include the various requirements defined by
the team for this projects successful completion and the detailed explanation of
the different project execution phases.
2.1. Approach Used

The proposed approach section describes some of the constraints the team
will work with in order to ensure the successful completion of the project.
Included are the functions that the software will or will not provide, the
security measures taken to safeguard the project while it is being developed,
and the safety impacts of the end product. In addition, criteria have been
defined in order to evaluate the success of the project at the end of the twosemester period.
2.1.1. Design Objectives

Included in this section are some objectives of the team for the end
product.
Product must have a simple design
Product must be low or no maintenance for end user
Product must be visibly appealing
Product must be reliable for end users
Product must not cause damage or harm to surroundings or

controlled appliances
Product must be easily operable by end users
May-06-13
Senior Design
Page 6
2/9/2016
2.1.2. Functional Requirements

The following defines exactly what the proposed product should and
should not do:
The control unit will have the ability to connect to the cellular
network automatically.
The control unit will be able to receive text messages and will be
able to parse and interpret (ASCII) text messages for password
identification and instructions to be sent to the microcontroller.
The microcontroller within the control unit will issue commands to

the electrical appliances through a simple control circuit.
The control unit will control the electrical appliances and detect the
status of the appliances to be relayed back to the microcontroller.
The microcontroller within the control unit should be able to send

status messages back to the cellular phone through the cellular
network.
The system should provide user authentication through cell phone

number identification and/or password verification contained within
the (SMS) text message.
2.1.3. Design Constraints

This section outlines the design constraints of the product.
The controlled appliances will need an electrical control interface.

This simple system is only capable of controlling electrical devices.
The control module will need to be shielded against electrostatic

discharges. This will increase reliability of the system.
May-06-13
Senior Design
Page 7
2/9/2016
2.1.4. Technology Considerations

This section discusses the various software technologies and the technical
approaches that the team has researched in the process of deciding which
tools and methods to adopt prior to the implementation phase.
2.1.4.1. Considered Cellular Modules

Part Number: GM47/48
Pros: The following are the attributes that are desirable about this
cellular module
850/1900 MHZ operating frequencies
Low power usage 3.4-4V at 250mA voice and 350mA data.
RS232 connection available
Universal developers kit available
Interface with SIM detection module
Controlled via AT commands
Cons: The only product attribute that makes it less desirable in
comparison to other products is that the RS232 connection is through
a 60 pin board on board connection, making it necessary to solder.
Heat from soldering with a mere iron instead of industrial means may
damage circuitry on the module.
Part Number: GM41/42
cellular module
Low power usage 5V+-10% at 250mA voice and 350mA data
C source code libraries available
40 pin DIP connection
Cons: The only attribute that makes this product less desirable in
comparison to other products is the higher power usage. The same
current is drawn, but at a higher voltage level than that of other
modules.
May-06-13
Senior Design
Page 8
2/9/2016
Part number: GM28/29

cellular module
Integrated SIM card holder
RS232 via DB9 connector
Easily programmable in C language
comparison to other products is the higher power usage 5-32V. Current
value specifications of this module are not available but presumed
comparable to other modules.
Part Number: GR47/GR48
cellular module
Low power usage 3.4-4V at 250mA voice and 350mA data
Universal Developers kit available
comparison to other products is that the RS232 connection is through
a 60 pin board on board connection, making it necessary to solder.
Heat from soldering with a mere iron instead of industrial means may
damage circuitry on the module.
Part Number: EE54 Edge
cellular module
USB 2.0 connection
Controllable via AT commands
On board SIM card holder
comparison to other products is the higher power usage compared to
other products at 5.5-20V and 250mA voice and 350ma data.
May-06-13
Senior Design
Page 9
2/9/2016
Part Number: CM52

Cellular module
40 pin DIP Connector
Controllable via AT commands
comparison to other products is the higher power usage compared to
other products at 5.5-13.8V and 1A.
Final selection: GM28 Cellular Module
Figure 2 GM28 Cellular Module
Reason for Selection

The GM28 cellular module was chosen for several reasons. For one, it
comes with an internal SIM card reader and has a DB9 RS232 serial
connection making communication more reliable and eliminating the
need for soldering connections directly to the module. The $600
developers kit is not necessary for this entirely enclosed device.
May-06-13
Senior Design
Page 10
2/9/2016
2.1.4.2. Considered AC / DC Interfaces

Two technologies were considered for the implementation of fan and
light controls: CMOS based gates and relays. Their pros and cons
were evaluated and a decision was made based on the evaluation.
CMOS based logic gates
Pros:
Fast switching
No static power dissipation
Voltage levels are compatible with that of a microcontroller
Inexpensive
Cons:
Low voltage levels of operation make the CMOS incompatible with
120Volts AC
Relays
Pros:
Control high voltage circuitry using low voltages; therefore
compatible both with the fan and lights power supply circuitry and
the microcontrollers circuitry
Cons:
Higher cost than CMOS integrated circuits
Some types or relays dissipate static power
Selected Technology:
Relays were chosen in this case due to the sole fact that their main
advantage of being compatible with both the microcontrollers logic
voltage levels and 120 VAC circuitry is not available with CMOS gates.
May-06-13
Senior Design
Page 11
2/9/2016
2.1.4.3.
Considered Microcontrollers
Functionality requirements for microcontroller include; the ability to

receive and parse text messages from GSM module, carry out the
required commands, monitor appliance status information, and send
status back to the GSM module. Since a microcontroller alone would not
be sufficient, considerations of microcontrollers will be done through a
microcontroller starter kit. The implementation of the microcontroller into
the project design should be done economically and as efficiently as
possible. The following is the list of microcontroller starter kits under
consideration:
May-06-13
Senior Design
Page 12
2/9/2016
Table 1 STK200 Starter Kit
STK200 Starter Kit by Kanda

Compatible Microcontroller
ATtiny12
AT90S1200
ATtiny13
AT90SS2313
ATtiny15
AT90S2343
ATtiny22
AT90S2333
ATtiny2313 AT90S4414
ATtiny26
AT90S4433
AT90S8515**(8K
bytes in-system
programmable Flash)
AT90S8535
ATmega48
ATmega8
ATmega88
ATmega8515
ATmega8538
ATmega16
ATmega161
ATmega162
ATmega163
ATmega168
ATmega32
ATmega323
Board Features
Cable/Connection
Power Consumption
I/O
ISP and RS232

9-15VDC or 7-12VAC
64-pins
Sockets for various devices 1x8,2x20, 1x28, 2x40 pin
Highlights
socket device to support all device pin-outs
Port Headers includes Vcc and Ground for powering
external circuitry
8-way bar LED , 8 Switches
3.3V/5V voltage selection
Brownout (2.9V or 4.5V level)
ADC circuitry
External Memory for 74HC573 address latch and
Flash RAM sockets
EEPROM socket for 24C
Includes AT90S8515-8PC microprocessor
Accompanied Development Software
Minimum hardware and
software requirements
80386 Processor (486 Recommended)
1 MB Ram
1 MB Free Hard Disk Space
Windows 3.1 or Windows 95
Software
Application Builder
AVR Studio 3 and 4
AVREdit and AVRGCC
Price
$66
May-06-13
Senior Design
Page 13
2/9/2016
Pros:
The advantage of using the STK200 starter kit is that the kit is
compatible with a variety of 8-bit, 16-bit, and 32-bit Atmel AVR
microprocessors. The kit also makes it easily interchangeable between
devices with 1x8, 2x20, 1x28, 2x40 pins digital sockets. Port B-E
headers of the development board contain Vcc and Ground pins which
can be utilized to drive external circuitries and contain 8 I/O pins each.
Programming should be very unproblematic because the Application
Builder software included with the kit will allow the user to efficiently
setup code for ports, timers, UART, ADC, SPI, watchdog and
interrupts. AVR Studio 4 is a full editor, assembler and simulator of all
AVR devices and AvrEdit and AVRGCC allow the utilization of C
programming language in the development process. Other highlights of
the kit include communication via RS232, brownout circuitries,
sufficient I/O ports, and expandability with external RAM, Flash, and
EEPROM sockets.
Cons:
The main disadvantage is that the AT90S8515-8PC microcontroller
included with the kit is an 8-bit microcontroller with 8K bytes in-system
programmable flash memory, which might be insufficient memory
allocation for project feasibility. Another disadvantage is that the clock
speed runs by default at 8MHz, given a 2.7V power supply and is
advertised to run at 16MHz at 5V, but that fact is not guaranteed by
Atmel.
May-06-13
Senior Design
Page 14
2/9/2016
Table 2 STK300 Starter Kit
STK300 Starter Kit by Kanda

ATmega103
ATmega603
ATmega128**(128K bytes of in-system programmable Flash, 4K bytes of in-system
programmable EEPROM and 4K bytes of SRAM)
Board Features
Cable/Connection ISP and RS232; opt. USB
Power
9-15VDC or 7-12VAC
Consumption
I/O
Port A-E (8-pins I/O; Vcc and Gnd); Analog Port F(8 analog
pins; analog Gnd and Ref); Misc. Header; 66-pins total
Highlights
Port Headers includes Vcc and Ground for powering external
circuitry
8-way bar LED , 8 Switches
3.3V/5V voltage selection
Brownout (2.9V or 4.5V level)
LCD's connectors
Drop-in external RAM, with sockets for Address Latch chip and
RAM plus dip header
Include daughter board with Atmega128 microcontroller
Minimum hardware and 80386 Processor or Above
1 MB Ram
1 MB Free Hard Disk Space
Windows 3.1 or Windows 95
Software
STK300 Application Builder
AVR ISP (C-complier)
AVR and IAR Studio are available for download at Atmel
website
Price
$85
Pros:
The development board for this kit contains the same features and
functionalities as the STK200 development board, but has been
modified so it is compatible with AVR Mega microcontrollers. The main
advantage of this implementation is that larger projects are now
feasible with the incorporation of AVR Mega microcontrollers. Included
with the kit is ATmega128L-8AI microcontroller containing 128K bytes
of in-system programmable Flash, 4K bytes of in-system
programmable EEPROM and 4K bytes of SRAM. This is sufficient
memory allocation for project feasibility. Since the microcontroller chips
are surface mounted on a daughter board, problems with surface
mounting the device can be avoided. Other advantages and highlights
with STK300 are similar to advantages and highlights with STK200.
May-06-13
Senior Design
Page 15
2/9/2016
Application Builder is also included with the kit. Also included in the kit
is AVR ISP software that supports programming via PCs parallel port.
Programming through PCs serial port is still possible with this kit. AVR
and IAR Studio are available to be downloaded from Atmel websites.
AVR Studio allows easy development and debugging with its built in
assembler and simulator.
Cons:
The main disadvantage of this kit is the microcontroller is not as easily
interchangeable as SKT200 because the new device has to be
soldered on the daughter boards first. Another disadvantage is that the
STK200 supports more microcontrollers than the STK300.
Table 3 Freescale MC68HC11E9 Starter Kit
Freescale (Motorola) MC68HC11E9 Starter Kit
MC68HC11E9 (12K Flash/EPROM; 512 RAM; 512 EEPROM; 38 I/O)
Board Features
Cable/Connection
PC COM port
Power Consumption
7-18VDC
I/O
NONE
Highlights
3"x1.5" Solderless Breadboard
Prototype Area
8MHz crystal
LCD's connectors
Keypad connectors
U5: 32Kbytes RAM installed
U7: 8Kbytes EEPROM installed
U6: expandable slot for RAM, EPROM, and EEPROM
Buffalo Monitor utility for debug and test program
DOS or Win 3.1
Software
AXIDE
free Assembler, C compiler and example source code
Price
$99
Pros:
The main advantage of Freescale (Motorola) MC68HC11E9 Starter Kit
Is that it has a solderless breadboard area and prototype area that can
be easily utilized for prototyping circuits as well as driving different
circuit components. The MC68HC11E9 microcontrollers with the
installed 32K bytes external RAM and 8K bytes external EEPROM will
provide sufficient memory allocation for project feasibility. Program will
be stored in 32K bytes RAM to be tested and debugged by Buffalo
Monitor utility. Other advantages include program in assembler and C,
sufficient I/O ports, and expandable slots.
May-06-13
Senior Design
Page 16
2/9/2016
Cons:
The main disadvantage of Freescale (Motorola) MC68HC11E9 Starter
Kit is that the development board does not contain any I/O port
headers. This can be an issue to the project feasibility because one of
the microcontroller functions is to drive and monitor electrical
appliances. An I/O port header may be implemented on the prototype
and solderless breadboard area, but this is an unnecessary use of
resources compared to the other starter kits. Another disadvantage
with this starter kit is that it does not allow interchangeability among
different microcontroller since the MC68HC11E9 microcontroller is
surface mounted onto the development board. The last disadvantages
for this starter kit is its price is considerably higher then the previous
starter kits.
Table 4 Philips 51 Plus Starter Kit
8051 Starter Kit Philips XA/RD/66x
P89C51RB2(H)
P89C660
XA-G49** (64K bytes Flash; 2K RAM)
P89C51RC2(H)
P89C662
P89C51RD2(H)
P89C664
P89C668
Board Features
Cable/Connection
Serial
Power Consumption
9-15V AC or DC
I/O
32 I/O ports
Highlights
40-pin DIP
44-pin PLCC
sockets
External RAM
circuitry
LCD connection
switches and
10-way Bar LED
Win 95
Software
Application Builder
WINISP and Flash Magic Programming Tools
C-compiler Demos (4K max) and Simulator
Price
$94.80
Pros:
The main advantage of this kit is that the XA-G49 microcontroller chip
that is included with match project feasibility. This will mean more
functionality and expandability for the project. Other highlights of the kit
include sufficient I/O ports for project feasibility and external RAM
circuitry.
Cons:
May-06-13
Senior Design
Page 17
2/9/2016
The main concern with this kit is it the XA-G49 does not contain any
EEPROM memory and could be problematic if the project functionality
requires the use of EEPROM. The other concern is the C-compiler
included in the kit is only a demo version, with coding limited to 4K
bytes. This will limit the utilization of C programming language and the
efficiency of the coding process.
Microcontroller selected: STK300 Starter Kit
After reviewing all of the microcontroller starter kits under
consideration, the team selected STK300 Starter Kit to be the optimal
choice.
Figure 3 STK300 Starter Kit

The team decided to proceed with the STK300 Starter Kit because it
has all functionalities of other microcontroller starter kits and it is the
most economical. The STK300 Starter Kit allows larger projects
compared to other starter kits to be implemented with the ATmega128
microcontroller included with the kit. It also allows flexibility with an
interchangeable microcontroller design. It has a sufficient number of
I/O ports for the project and it has a unique feature that allows the port
headers to drive external circuitry with Vcc and Gnd pins. Coding
process with this board will be efficient because it allows coding in
higher level programming languages C and Application Builder allows
wizards to set up ports, timers, UART, ADC, SPI, watchdog and
interrupts. It is the most economical because the list price is less than
the Freescale (Motorola) MC68HC11E9 Starter Kit and Philips 51 Plus
Starter Kit.
May-06-13
Senior Design
Page 18
2/9/2016
2.1.4.4. Programming Language Consideration

There are many available software technologies that can be used to
develop this project. In order to ensure that the team will create the
best product to their abilities, all software solutions will be considered
and evaluated by the team.
The files that will be developed in the selected development
environment will then be ported over to the complier supported by
selected microcontroller.
Programming in Assembly Language
Assembly language programming is very low level and will allow for
more control of the source code. By using the assembly language, the
complied code will take up less space when stored into the
microcontrollers memory. A majority of the team has programmed in
assembly before in other courses taken at Iowa State University and is
familiar with the language. Assembly also has a very quick response
time.
Assembly language programming could prove to be more complex to
implement. Many of the team members whom have taken it before will
need to re-learn the language. There has yet to be an example of SMS
assembly language code or any programming libraries discovered by
the team from available resources that can be used to assist in
developing knowledge for this project. The team would have to
interface the assembly program code with some other languages
already defined libraries.
Programming in C Language
There are many examples available that the team has already located.
The C programming language is a universally reliable language with
many resources available for coding and debugging purposes. There
are C libraries already written and available for interfacing with the
GSM network and serial communication channel. All team members
are familiar with C++ which is similar to this programming language,
shortening the learning curve.
May-06-13
Senior Design
Page 19
2/9/2016
Programming in C++ Language

A definite advantage of programming in C++ is that all the group
members have programmed with it before. C++ is also an objectoriented language, making development easier and allowing for
multiple developers to create code and import changes into the final
program. The response time of C++ will be at least as fast as
interpreted languages.
The only disadvantage to using C++ is that GSM and serial
communication libraries are more difficult to locate compared to the C
programming language.
Programming in JAVA Language
Java is a very high-level programming language with many online and
learning resources available to the team. Java also has a lot of built-in
functions available to the developer. There are a number of
disadvantage associated with this programming language. One is that
a majority of the team members have never developed in Java. This
would create a problem of not being able to utilize all team members
for debugging, developing, or testing the Java code. Another
disadvantage is that the final compiled code will take up more memory
than other lower-level languages stated above. Finally, response time
of the Java programming language is poor and would cause a lag in
real-time execution.
Selected Programming Language: C
The team has decided to use the C programming language to develop
this project.
The main reason for this selection is due to the number of online
resources available to the team. Team members all have a good basis
in developing in C++ so the main hurdle will be identifying the
differences between using C instead of C++. This programming
language is also supported by the teams selected microcontroller.
May-06-13
Senior Design
Page 20
2/9/2016
2.1.4.5. Development Environments Considered

This section discusses the various coding development environments
the team discussed for the coding phase of the project.
Eclipse
The Eclipse software is a very powerful java-based open-source
development environment. Its original intent is to be used as a java
developing environment, but there is a C/C++ plug in that can be
installed making it work with these languages.
The Eclipse software allows a developer to view the value of variables
on-the-fly and step through code line-by-line. This is very valuable
when it comes to debugging and troubleshooting.
The performance of this software can sometimes be very poor due to
the nature of the Java virtual machine (JVM). However, since it is
programmed in java, the tool can be used on any machine that can
support a JVM.
Visual Studio .NET 2003
This tool is developed and supported by the Microsoft Corporation.
Similar to Eclipse, this software is free to the team through MSDNAA.
This software also includes a complete range of capabilities from
modelers that aid in visually composing the most complex of
enterprise-class applications to deploying an application on the
smallest of devices. Visual Studio .NET 2003 is widely used across the
world.
Selected Developing Environment: Visual Studio.NET 2003
The team has decided to use the Visual Studio .NET 2003 developing
environment to develop this project.
The main reason for this selection is that this resource can be obtained
by all team members for free and is ready to start development without
any additional work spent on setup by the team members.
May-06-13
Senior Design
Page 21
2/9/2016
2.1.4.6. Considered Coding Styles

This section discusses the various coding styles the team has
discussed for the coding phase of the project.
Use of Brackets
All brackets will take up an entire line of code. The opening and closing
of a bracket pairing will vertically line up in the same column of text at a
tabbed position. Following an opening bracket, the preceding line of
code shall be tabbed in to the next level. This coding style is apparent
in Figure 4.
for(i=0;i<10;i++)
{
if(sampleFunction())returnans;
}
Figure 4 Bracket Coding Standard
Variable Declaration
Since the decision of programming in the C language was chosen, all
variables must be declared at the beginning of any and all functions.
The variables shall be grouped together with similar variable types. For
example, all integers shall be grouped together separate from all char,
char*, etc.
Line Length
The number of characters per line shall be limited to 80 characters per
line. The reason for this is for proper printing of all source code.
Function Declarations and Operations
The convention this team will use will be to not include any spacing
between comparison operators or function elements. An example of
this is shown in figure 4.
May-06-13
Senior Design
Page 22
2/9/2016
2.1.5.Testing
Testing is separated into two major types: Unit and integration. Unit
testing is used to determine that a single component is functioning
correctly while integration testing is used to determine that a newlyadded component is functioning correctly within the context of the rest of
the program.
The following unit testing requirements will be indicators that the system
can successfully be implemented:
GSM Network Communication
The GSM receiver will be tested for successful communication with
network. This will test include automation and consistency of the
connection and will be conducted by a team member in the following
way:
The cellular phone will dial the GSM receivers number
Once the connection is established a stream of data will be send

to the GSM receiver.
The GSM receiver will be given data to be transmitted to the

cellular phone.
Success/Failure criteria: The data received will be observed on

both ends to verify its consistency. The test will be considered
successful if the integrity of the sent and received data is maintained
up/downstream. It will be considered a failure otherwise.
GSM to Microcontroller Communication
The GSM to microcontroller driver will be tested by verifying the integrity
of command strings sent from the remote user. The following procedure
will be performed in majority by a CprE team member:
The remote user will send a command to the control module.
The contents of the data stream will be observed at the GSM

communication port.
These contents will be compared with those received and stored

at the microcontrollers corresponding communication port.
May-06-13
Senior Design
Page 23
2/9/2016
The procedure will be repeated in reverse with the microcontroller

sending a data steam to the GSM receiver.
Success/Failure criteria: The test will be considered successful if

the integrity of the data sent up/downstream is maintained. It will be
considered a failure otherwise.
GSM Message Decoding
Proper decoding of the remote users commands and issuance of the
equivalent commands to the controlled device will be performed by team
members using the following procedure:
A simulated instruction will be fed to the microcontroller

communication port.
The output command at the I/O interface with the corresponding

controlled device will be observed.
Success/Failure criteria: The test will be considered a success if

the resulting command issued from the microcontroller is sent to the
right I/O address for the desired controlled device and if that
command is consistent with the command which is expected. The
test will be considered a failure otherwise.
Voltage Converter Circuit Operation
The scaling circuit from the controlled devices to the I/O will be tested for
proper operation. This will be tested by EE team members:
The controlled devices will be manually triggered to force the

desired voltage.
The output of the scaling circuit will be measured.
Success/Failure criteria:
The testing will be considered
successful if the measured output voltage is properly scaled to the
microcontrollers required input value. The test will be considered
a failure otherwise.
The ability of I/O to detect an input voltage and store a value in

the microcontrollers memory will be tested by team members:
Test voltages to the input of the I/O will be applied.
The contents of the memory shall be checked for validity.
Success/Failure criteria: The testing will be considered successful

if the values of the memory are as expected. The test will be
considered a failure otherwise.
May-06-13
Senior Design
Page 24
2/9/2016
Power Surge Performance

The circuits power surge protection will be tested for acceptable
performance by EE team members using the following procedure:
The circuits power supply will be removed from the circuit and
connected to a dummy load.
A simulated voltage spike will be inputted by using a step signal

from a signal generator.
The output voltage and current will be measured at the load.
Success/Failure criteria: The success of the test will be determined

by verifying that the output signal to the dummy load falls with the
tolerance indicated by the microcontroller and the GSM chips
manufacturers. The test will be considered a failure if the measured
characteristics of the power supplys output do not meet the
manufacturers requirements.
User Authentication
The password authentication will be tested for proper operation. The
following procedure will be performed by team members:
The password protection of the code will be run in debug mode.
A simulated mix of correct and incorrect passwords will be sent to

the microcontroller
The response of the microcontroller will be observed for each of

the inputted passwords.

if the microcontroller grants access to all the right passwords and
none of the wrong passwords. The test will be considered a failure
otherwise.
I/O Status Trigger Correctness
The ability of an I/O status to trigger the execution of status messaging
subroutine will be tested as well as the ability to send the resulting status
to the remote user. The following procedure will be performed by team
members:
May-06-13
Senior Design
A simulated device status will be written to the I/O in debug mode.
Page 25
2/9/2016
The simulated status will trigger the execution

microcontrollers device status notification subroutine
The subroutine output will be checked prior to being sent to the

GSM chip.
Verification that the status message was received by the user cell
phone will be performed.
of
the

if the simulated I/O triggers execution of the subroutine and if the
correct status message is sent to the GSM chip and that status
message is received by the cell phone. The test will be considered a
failure otherwise.
End Product Testing
The end-product functionalities will be tested by team members and nonteam members in the following way:
Team members will ensure that all subsystems function properly

together from remote user command to execution and back to
completion status notification.
Non-team members from the general public will be allowed to

access and use the control unit for a frame of time.
Afterward, the non-team member testing subjects will fill out a

survey on the end-products functionalities, ease of use,
difficulties, etc.
Success/Failure criteria: The testing will be considered a success if

the testing subjects find the end-product user friendly, and easy to
figure out.
Testers
Each team member is responsible for being the primary black box tester
of a given member's code. Black box testers are to test code without
examining the code itself in order to avoid having any assumptions
outside of those specified by the conditions of the code.
Non-team members will be brought in to use the system and will be
monitored by team members. If the non-team members cause an error in
the system, the team members will document the nature of the error and
address the issue as soon as possible.
2.1.6.Project Continuation
May-06-13
Senior Design
Page 26
2/9/2016
Currently the team is keeping an archive of all applicable project

components (documentation & research so far) in the online web space
storage area provided by Iowa State University engineering department.
The team has been on schedule and does not see any reason to put
further effort into preparing to hand this project to another team.
2.2.Detailed Design
This section discusses the features and the design of the end product in
depth. The discussion is based on the following sections:
2.2.1 Coding Details

There will be six main coding modules to the entire system. Five reside
on the control unit located in the users home and the other module will
reside on the users cell phone (*).
Initialization
Check & Read Messages
Decode Messages
Application Control
Status Monitoring
Send Status Message
Text Message Command Templates (*)
May-06-13
Senior Design
Page 27
2/9/2016
INITIALIZATION:
The initialization portion will require the following libraries in the project
directory:
deftypes.h Loads type definitions for String
RS232.h Loads RS232 serial drivers
SerComm.h Loads Serial Communication types
ATCommand.h Loads AT Commands for use
Include the entire EWMSDK library in the project:
AT Commands
PDU (Protocol Data Unit) Formatting
Serial Communication & RS232
AT_InitializeData
This is necessary when dealing with embedded systems in order
to initialize memory upon startup. This function is used before initializing
channels or registering events.
AT_CheckEvents / or Call AT_SetTimer (in Windows)
This will periodically search for events and will call
AT_CheckEvents
MS_EstablishChannel
This function call will open the serial channel that will be used to
communicate with the GSM chip. When communication with the GSM
chip is complete, MS_ReleaseChannel will be called in order to keep the
channel available for other applications.
CFG_SetCommandEcho (value parameter = 0)
EWMSDK will not work if ATE is set to 1.
VM_SetATResponseFormat (value parameter = 1)
This will enable verbose mode. The library requires ATV to be set to
value 1 (ATV1) which is the usual state of modems. Dont work in ATV0
mode.
CFG_SetReportEquipmentError (value parameter = 1)
This will allow the library to offer specific error code results returned
by the module. There are 3 modes available: 0 and 2 will not interpret
error codes, 1 will return error codes that can be referenced by the GSM
modules Integrator manual.
May-06-13
Senior Design
Page 28
2/9/2016
CHECK & READ MESSAGES:

The check and read messages coding module will use the following
functions (descriptions of each are provided):
AT+CMGR=1
This will read only message #1 stored in the memory of the M2M
module. If there is an incoming message, the message will be stored as
a String. Messages can be deleted from the M2M module using the
command AT+CMDG=1.
DECODE:
SMS messages contain information such as date, time, senders number
and message. The program must perform simple String manipulations to
decode this message and store all relevant data. If the decoded
message is equal to a pre-stored message, then the function will be
called for that particular command, otherwise it will be deleted.
Application Control:
The application control coding module will be used for sending
commands to the microcontroller that will drive the I/O ports located on
the microcontroller. These I/O ports will cause the controlled unit to
perform the requested action.
Every application that is to be controlled will have its own separate
function. When the function is called, it will drive the I/O ports on the
microcontroller to perform the command requested.
Status Check:
The status check of all the devices will be slightly different for every
device.
Every application that is to be controlled will also be monitored and will
have its own separate function. The device is not required to be solely
under the control of the system. This means that the system can not
simply check the status of the I/O values to determine whether a device
is in the state the system is applying. Additional hardware will need to be
connected in order to determine the state of the device.
May-06-13
Senior Design
Page 29
2/9/2016
Send Status Message:

The send status message coding module will use the following function
(description provided):
SMS messages will need to be sent back to sender with status of
operation.
#Send message to phone number below
at+cmgs="destination phone number"
#Write your message at the > prompt. Hit Control-Z to send (do not hit
enter to send)
>Test Message 1
Text Message Command Templates:
These text messages will be sent to the controlling unit located in the
users home:
The cell phone message commands will have to be setup by the user. A
sample listing of acceptable messages would be as follows:
light on
light off
fan high
fan medium
fan low
fan off
temperature status
ac set 72
system off
May-06-13
Senior Design
Page 30
2/9/2016
2.2.2 Microcontroller Details

The microcontroller will be the device controlling all the appliances.
There will have to be special wiring for all devices connected to the
microcontroller. The following section will show in detail how the team
has discussed connecting the various devices to the microcontroller.
Thermostat Control:
Figure 5 Thermostat Control Schematic
May-06-13
Senior Design
Page 31
2/9/2016
Digital Thermostat Operation
Figure 6 - Thermostat Application Module Schematic Diagram
Important Components of Digital Thermostat:

MAX6625 9-Bit/12-Bit Temperature Sensors with I2CCompatible Serial Interface.
AT24C128 Two-wire Serial EEPROM
74HCT4052 Dual 4-channel analog multiplexer, demultiplexer
HEADER Microcontroller
In Figure 6 we can see how the digital thermostat works. The
MAX6625 is constantly reading the room temperature and is
connected to the multiplexer and the multiplexer is connected to the
microcontroller. This means that the temperature sensor is sending
the recorded temperature and the multiplexer then makes the
signal more readable for the microcontroller. The microcontroller
will decide, depending on the desired temperature, whether to turn
on the fan (cool down) or turn on the light (warm up).
May-06-13
Senior Design
Page 32
2/9/2016
The thermostat also has three switches (S1, S2, S3) these are
used to program different modes of operation or to change
temperature set point. The controller is connected to an LCD that
will either display the room temperature and the desired
temperature and whether the fan is turned on or off. The EEPROM
is used to store the temperature read by the temperature sensor.
The operation of this thermostat is as follows:
1. The temperature sensor checks the room temperature every
x seconds and sends the information to the microcontroller.
2. The microcontroller uses this information by comparing the
room temperature to the desired temperature. There are two
possible scenarios that will result heat or cool the room.
If the room temperature is under the desired temperature,
the light bulb will turn on. This will heat up the
temperature sensor until the temperatures are the same.
If the room temperature is above the desired temperature
the fan will turn on. This will cool the temperature sensor
until the desired and room temperatures are equal.
Interface between Microcontroller and Thermostat
The microcontroller will use 3 pins from port A as outputs that will
be connected to an XOR gate. The inputs to the XOR gate are one
from the microcontroller and one from the pushbutton or the switch.
These were selected so that the system can choose which signal
are going to be use: either the one from the button or the one from
the microcontroller. The XOR gate gives a 1 output only when the
two inputs are different. Using this setup, only one will be controlling
the input for the thermostat. The multiplexer from the thermostat,
which sends the temperature, will be connected to both the
microcontroller of the thermostat and the remote controlling
systems microcontroller. The thermometer will be sending the room
temperature and the remote controlling system will both get it and
use it to send to the user and other applications. This will also be
connected to the output of the thermostat microcontroller that goes
to the LCD so the desired temperature can be read and then
determine how much the user wants to change the temperature
(see the schematic in Figure 5).
May-06-13
Senior Design
Page 33
2/9/2016
How the Thermostat will Work

The control for the thermostat will work by having these messages
and how they work:
Room Temperature this instruction will send the user the
room temperature so the user can decide what he wants to do
with that information.
Temperature Status this instruction will send the user the
desired temperature programmed into the thermostat. From this,
the user will decide what action to take.
Change temperature to ___ (desired temperature will go here)
this instruction will tell the microcontroller to change the
desired temperature of the room to the new desired
temperature.
Turn off A/C this instruction will turn the A/C and the heater
off, the fan (cooler) and the light bulb (heater) will be
disconnected regardless of previous state.
Fan Control:
The control of the fan takes place at bits 0-3 of the STK300 kits port A.
The main features of the fan control are the following:
Manual/remote control
Speed control
Fan operating status detection.
The outlined features are implemented in the following way:
Manual/remote control select:
This part assumes that the microcontroller is powered on. Relay R3
is a Single Pole Double Throw relay. Its control signal comes from
port A bit 3 of the STK300. This relay selects the output of either the
fan switch or the control relays R1-R3 to be connected to ground.
Its de-energized position is on the fan switch contact and its
energized position is on the control relay contact. Therefore a logic
signal of 0 corresponds to the default manual control and a logic
signal of 1 corresponds to a remote control selection. In the case of
loss of power or accidental reboot of the control module, the control
returns to its default manual setting.
May-06-13
Senior Design
Page 34
2/9/2016
Figure 7 Fan Control Schematic
Speed control:
The fans manufactured speed control circuitry consists of a 4
position switchof which 3 positions correspond to fan speeds
and the 4th corresponds to the off positionand of three different
size windings sharing a metal core with the rotor. The windings all
share a common 120VAC voltage source and the switch selects
either winding, allowing it to conduct to ground. The implemented
speed control mimics this control system by connecting Single Pole
Single Throw relays R0-R2 in parallel with each switchs winding
connection and the manual/remote select switch. R0-R2 are
controlled by signals from bits 0-2 of port A of the STK300. For
each switch the default/de-energized position is open circuit, and
the energized position is closed circuit. Effectively the asserted bit
selects the speed of the fan.
May-06-13
Senior Design
Page 35
2/9/2016
Operating status detection:

The principle that is applied in this part of the circuit is that
depending on whether or not the fan is running. There will be a
current traveling between the terminals of the fans 120V AC power
supply. The challenge in this part is to scale the applied 120Volts to
a level that is safe to deliver to the STK300s ports. The desired
voltage is 5 Volts DC. The conversion circuit is implemented at
nodes A and B on the fan controls schematic.
The voltage is first stepped down through a voltage divider
implemented through R1 and R2. Next a buffer takes the scaled
voltage at the voltage divider circuit and repeats it at the input of a
full wave rectifier circuit implemented by D1-D4 and R9. In the last
stage, the rectified wave is sent to a first order low-pass
Butterworth filter (also known as a low pass RC filter) with cutoff
frequency of 10Hz. The output is a jagged, nearly DC signal with
lower bound value of 5.7 Volts. This voltage is only present when
the fan is running, in which case the 120Volt supply at nodes A and
B is conducting through R1 and R2. Otherwise the output here is
0V. This output is sent to port A bit 4 of the STK300.
Figure 8 Fan Status Signal Circuit Schematic
May-06-13
Senior Design
Page 36
2/9/2016
Light Control:
The implemented control of a lamp essentially follows a similar design as
the control of the fan. There is a Single Pole Double Throw relay
controlling the selection of remote/manual operation and there is a
Single Pole Single Throw relay in parallel with the light switch mimicking
its function. The remote/manual selection relay is controlled by port B bit
1 of the STK300 and the on/off control relay is controlled by bit 0 of the
same port.
Figure 9 Light Schematic
2.2.3 GSM Module Details

The GM28 cellular module is used to send and receive information over
the GSM cellular network. There will not be any modifications to the
GM28. The GM28 will be connected via RS232 serial communication
port to the serial port on the STK300 microcontroller developers kit. See
appendix A and B at the end of this document for the GSM and
microcontroller images.
May-06-13
Senior Design
Page 37
2/9/2016
3.
Estimated Resources and Schedule
This section includes an estimate of the resources required for the project.
Resources defined include the number of hours each team member will spend on
different project areas, any equipment that will be necessary for the project, and
the total dollar amount that the team will need for successful project completion.
3.1. Estimated Resource Requirements

Personal hours and material costs make up the estimated resource
requirements. There are two parts to each of these components: the original
estimate and a combination of actual personnel hours to date and revised
future personnel hours. The original case shall be compared to the revised
case and the reason(s) for the difference shall be explained.
3.1.1. Personnel Resources

Following is an update to the material presented in the same section of
the Project Plan. This table outlines the projected and current hours
spent by team members on the project as well as other resources hours
to be spent on the project. Other resources are members of the general
public that will be asked to use the system. The team is planning to use
outside sources for testing in order to see if persons unfamiliar with the
project will try to perform operations not accounted for by the team. The
problem definition and technology considerations are complete, so the
times reflected will not change.
May-06-13
Senior Design
Page 38
2/9/2016
15
25
25
10
42
184
Chau Nguyen
10
20
35
20
10
35
170
Issa Drame
12
20
30
15
10
45
172
Arturo Palau
10
25
30
70
Other
Resources
20
44
80
98
60
30
152
604
Total
Project Reporting
DemonstrationEnd-Product
12
End-Product Testing
DesignEnd-Product
Adam Mohling
Problem Definition
DocumentationEnd-Product
ImplementationEnd-Product
SelectionTechnology Consideration and
Table 5 - Personnel Effort in Hours
Total
Original Projected Effort
Adjusted Projected Total Effort

Adam Mohling
13
25
25
10
56
190
Chau Nguyen
18
35
20
10
50
178
Issa Drame
28
30
15
10
55
184
Arturo Palau
11
52
74
Other
Resources
23
70
20
98
60
30
213
634
Total
Note that the end-product demonstration is equally distributed among

the members since this will be a team effort for both the preparation
and the actual presentation. The project reporting column will also
increase in value because the team is required to continue reporting
and create a Final Report.
Overall, the team underestimated measurements for hours spent on
the tasks. There was much more research that needed to be done in
order to accommodate all the possible solutions to the project.
May-06-13
Senior Design
Page 39
2/9/2016
3.1.2. Financial Requirements

This section discusses the expected costs of the project, both revised,
current, and total projected. Tables 7, 8 and 9 below represent the
approximate estimates for the project with and without labor costs of
the team members. The items have been separated into two sections:
parts and materials expenses, and labor costs.
Labor costs include the amount each team member would have
earned based on their hours and a $10.30/hour wage. The wage was
selected based on what appeared to be an average amount from other
senior design groups. As the table shows, the amount earned is
proportional to the total individual hours spent on the project.
May-06-13
Senior Design
Page 40
2/9/2016
Table 6 - Financial Requirements
Without
Labor
Item
Original Projection
Parts and Materials
Computer Hardware &
$0.00
Software
Final Project Enclosure
$3.00
M2M GSM Controller
$140.00
Misc. Electronic Components
$8.00
Poster
$50.00
Subtotal
$201.00
Labor (at $10.30/hr)
Adam Mohling
Chau Nguyen
Issa Drame
Arturo Palau
Subtotal
$0.00
Total
Projected Total Cost
Parts and Materials
Misc. Electronic Components
$8.00
GM28 GSM Cellular module
$231.00
GM28 Power Supply
$33.00
GM28 Antenna
$22.00
Microcontroller Starter Kit
$85.00
Poster
$50.00
Subtotal
$429.00
Labor (at $10.30/hr)
Adam Mohling
Chau Nguyen
Issa Drame
Arturo Palau
Subtotal
Total
May-06-13
Senior Design
Page 41
With Labor
$0.00
$1895.20
$1751.00
$1771.60
$721.00
$6138.80
$6339.80
$1957.00
$1833.40
$1895.20
$762.20
$6447.80
$6876.80
2/9/2016
3.2. Schedules
To date, the team has managed to stay remarkably on schedule. The only
major difference between the previous and current Gantt chart is that the
teams project poster has been moved to the 2 nd semester of the course.
Figure 10 Original Project Schedule
The only difference between the original project schedule and the current
project schedule is that the poster has been moved to the next semester. This
is also reflected in the detailed project reporting schedule
Figure 11 Current Project Schedule
May-06-13
Senior Design
Page 42
2/9/2016
Figure 12 Original Project Reporting Schedule
May-06-13
Senior Design
Page 43
2/9/2016
Figure 13 Current Project Reporting Schedule
** Notice the project poster is the only change from the previous to the
current schedule.
May-06-13
Senior Design
Page 44
2/9/2016
Figure 14 Project Development Schedule
Since the team has not reached the development stage, there are no
comparisons to be made to the teams projected development schedule. The
team is still planning on beginning development of the project during January
of 2006.
May-06-13
Senior Design
Page 45
2/9/2016
4. Closure Materials
This section provides contact information for all significant parties involved in the
project. Also included are a closing summary intended to give the reader a final
perspective on the whole project and a list of references the team will be using
during the course of the project.
4.1 Project Team Information

Client Information
Senior Design, Iowa State University
Dr. John W. Lamont
324 Town Engineering
Ames, IA 50012
(515) 294-3600
jwlamont@ee.iastate.edu
Prof. Ralph Patterson III

326 Town Engineering
Ames, IA 50012
(515) 294-2428
repiii@iastate.edu
Faculty Advisor Information

Prof. Ahmed E. Kamal, Professor
Iowa State University
Ames, IA 50011-3060
(515) 294-3580
kamal@iastate.edu
Student Team Information
Arturo Palau EE
80 Linden Devitt
Ames, IA 50011
(515)708-3812(Cell)
apalau@iastate.edu
Chau Nguyen EE
137 S. Franklin Ave.
Ames, IA 50014
(319)321-8619
chayman@iastate.edu
Issa Drame EE
4335 Frederickson Court
Ames, IA 50010
(515)572-7820
issad@iastate.edu
Adam Mohling CprE

2635 Knapp St.
Ames, IA 50014
(515)292-2161(Cell)
mohbandy@iastate.edu
May-06-13
Senior Design
Page 46
2/9/2016
4.2 Closing Summary

Although this cell phone based remote home control system is applied to a
limited number of devices in this project, its basic building blocks would
remain the same, should one implement the remote control of any other
electronically controllable device. Programming and hardware additions
would make such an undertaking possible. Moreover, given the successful
bid to integrate functionalities into cell phones, cellular companies may find
the idea of the remote home control system to be an attractive option,
therefore such a system has a potential for success in commercial
applications.
4.3 Reference:
Senior Design Course Notes Iowa State University
Available at http://seniord.ee.iastate.edu/notes/
4.4 Appendix
May-06-13
Senior Design
Page 47
2/9/2016
Appendix A
GM28 GSM Module Images
May-06-13
Senior Design
Page 48
2/9/2016
Appendix B
STK300 Microcontroller Developers Kit Images
May-06-13
Senior Design
Page 49
2/9/2016
Appendix C
120V AC--5VDC Fan Status Signal Circuit Simulation Results
May-06-13
Senior Design
Page 50
2/9/2016

Design Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design Document

Uploaded by

Copyright:

Available Formats

Cell Phone Based Remote Home Control System

1.1. EXECUTIVE SUMMARY.........................................................................................................1

APPROACH AND PRODUCT DESIGN RESULTS........................................................ 6

2.1. APPROACH USED..................................................................................................................6

ESTIMATED RESOURCES AND SCHEDULE.............................................................. 38

3.1. ESTIMATED RESOURCE REQUIREMENTS...........................................................................38

TABLE OF CONTENT CONTINUED

PROJECT TEAM INFORMATION...........................................................................................46

1.1. Executive Summary

Figure 1 Overall System Flow Diagram

1.3. Problem Statement

1.3.1. General Problem Statement

1.3.2. General Solution Approach

1.4. Operating Environment

1.5. Intended Users and Intended Uses

1.6. Assumptions and Limitations

1.6.1. Assumptions List

1.6.2. Limitations List

The receiver must reside in a location where a signal with

Only devices with electrical controlling input ports will be

The receiver must have a power source (120V) attached at all

Operation of the control unit is only possible through a cell

The control unit must be able to receive and decode SMS

1.7. Expected End Product and Other Deliverables

A single M2M controller module that can perform the following:

A list of approved message input commands that the device is

Develop a user manual for reference by the end user

A project plan and this design document will be written to

Project poster is required to showcase the project to students

Design document is required to outline our technical

Final report is required for documentation on the overall project,

Approach and Product Design Results

2.1. Approach Used

2.1.1. Design Objectives

Product must have a simple design

Product must be low or no maintenance for end user

Product must be visibly appealing

Product must be reliable for end users

Product must not cause damage or harm to surroundings or

Product must be easily operable by end users

2.1.2. Functional Requirements

The microcontroller within the control unit will issue commands to

The microcontroller within the control unit should be able to send

The system should provide user authentication through cell phone

2.1.3. Design Constraints

The controlled appliances will need an electrical control interface.

The control module will need to be shielded against electrostatic

2.1.4. Technology Considerations

2.1.4.1. Considered Cellular Modules

Part number: GM28/29

Part Number: CM52

Figure 2 GM28 Cellular Module

Reason for Selection

2.1.4.2. Considered AC / DC Interfaces

Functionality requirements for microcontroller include; the ability to

Table 1 STK200 Starter Kit

STK200 Starter Kit by Kanda

ISP and RS232

Table 2 STK300 Starter Kit

STK300 Starter Kit by Kanda

Figure 3 STK300 Starter Kit

Reason for Selection

2.1.4.4. Programming Language Consideration

Programming in C++ Language