Cell Phone Based Remote Home Control System
May-06-13
Final Report
Client:
ECpE Department
Advisor:
Prof. Ahmed Kamal
Team:
Adam Mohling (CprE)
Chau Nguyen (EE)
Issa Drame (EE)
Arturo Palau (EE) (1st semester only)
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 student-
prepared 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
October 22, 2011
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. FUNCTIONAL REQUIREMENTS............................................................................................. 6
2.2. DESIGN CONSTRAINTS ........................................................................................................ 7
2.3. APPROACHES CONSIDERED AND ONE USED .................................................................... 8
2.3.1 CONSIDERED CELLULAR MODULES................................................................................. 8
2.3.2 CONSIDERED AC/DC INTERFACES ............................................................................... 11
2.3.3 CONSIDERED MICROCONTROLLERS .............................................................................. 12
2.4. DETAILED DESIGN ............................................................................................................. 28
2.5. IMPLEMENTATION PROCESS DESCRIPTION ..................................................................... 39
2.6. TESTING OF THE END PRODUCT AND RESULTS .............................................................. 42
2.7. END RESULTS OF THE PROJECT ...................................................................................... 47
3. RESOURCES AND SCHEDULE ..................................................................................... 48
3.1. ESTIMATED RESOURCE REQUIREMENTS ......................................................................... 48
3.1.1. PERSONNEL RESOURCES .............................................................................................. 48
3.1.2. FINANCIAL REQUIREMENTS ........................................................................................... 51
3.2. SCHEDULES ....................................................................................................................... 54
4. CLOSURE MATERIALS ................................................................................................... 60
4.1 PROJECT EVALUATION....................................................................................................... 60
4.2 COMMERCIALIZATION ......................................................................................................... 63
4.3 ADDITIONAL WORK ............................................................................................................ 63
4.4 LESSONS LEARNED ............................................................................................................ 64
4.5 RISK AND MANAGEMENT ................................................................................................... 65
4.6 PROJECT TEAM INFORMATION .......................................................................................... 68
4.7 CLOSING SUMMARY ........................................................................................................... 69
4.8 REFERENCE: ....................................................................................................................... 69
4.9 APPENDIX ............................................................................................................................ 69
May-06-13
Senior Design Page i 10/22/2011
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 ..........................................................................................32
Figure 6 - Thermostat Application Module Schematic Diagram ...................................................33
Figure 7 –Fan Control Schematic .........................................................................................................36
Figure 8 – Fan Status Signal Circuit Schematic ...............................................................................37
Figure 9 – Light Schematic ....................................................................................................................38
Figure 10 – Decode LCD Display Matrix .............................................................................................41
Figure 11 – Original Project Schedule Summary .............................................................................54
Figure 12 – Current Project Schedule Summary ..............................................................................54
Figure 13 – Original Project Reporting Schedule .............................................................................55
Figure 14 – Design Report Project Reporting Schedule.................................................................56
Figure 15 – Final Project Reporting Schedule ..................................................................................57
Figure 16 – Project Development Schedule.......................................................................................58
Figure 17 – Final Project Development Schedule ............................................................................59
May-06-13
Senior Design Page ii 10/22/2011
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 – Personal Effort in Hours ......................................................................................................49
Table 6 – Financial Requirements .......................................................................................................52
Table 7 – Detailed Circuit Financial Requirements ..........................................................................53
May-06-13
Senior Design Page iii 10/22/2011
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.
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.
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).
GCC Compiler – C language compiler that is used to compiling C language
source code.
May-06-13
Senior Design Page iv 10/22/2011
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 May06-13 senior design team‘s plan for designing
and developing a cell phone based remote home control system.
The system allows 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, a light and the microcontroller programming
will be done in C programming language.
The team has spent a total of 741 hours and at a rate of $10.30 per hour the
labor cost is $7632.30. With a cost of $148.91 on parts and materials, the
total cost for the project is $7881.21 including labor. The team ended up
under budgeting the project by $1184.50. In terms of parts, the team‘s
microcontroller starter kit and the cellular module were donated by their
respective manufacturers. This kept the actual total cost at approximately half
what it would have ended up costing.
The entire flow of data throughout the system is shown in figure 1.
May-06-13
Senior Design Page 1 10/22/2011
•Send message
Cell Phone •Receive status message
GSM Network •Provides communication
GM28
•Communicate with network
GSM Module •Transfer data to microcontroller
RS232 serial connection
Board Features
STK300 Microcontroller Starter Kit
•Decode incoming messages
•Send instructions to controlled appliances
•Monitor & return status signals to users
Port A Port B Port C
Pins 0, 1, 2: Pin3: Pins 2, 3, 4: Pins 0, 1, 2, 3,
Control Status Control 4, 5, 6: Status
Pins 0: Pin1:
Control Status
Fan Thermostat
Light
Figure 1 – Overall System Flow Diagram
May-06-13
Senior Design Page 2 10/22/2011
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 was to develop a device that allowed for a
user to remotely control and monitor multiple home appliances using a
cellular phone. This system is a powerful and flexible tool that‘s service
is always available, and from any location 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 approach used for designing this system was to implement a
microcontroller-based control module that receives 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 10/22/2011
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:
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 phone‘s 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
A pre-paid cell phone and sim card will be used for connectivity
to a GSM network
The ability to send and receive messages is possible through C
programming and the use of the gcc compiler.
Through the use of C programming, the microcontroller should
be able to send messages and decode received messages
The thermostat‘s driver is always properly functioning, as it is
essential to decoding the display.
May-06-13
Senior Design Page 4 10/22/2011
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
System will be installed in a household climate
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.
If the microcontroller is not able to send or receive messages,
the functionality of the system will be greatly compromised
The thermostat‘s data bus is internal to its CPU and unavailable
to be decoded.
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 the technical
requirements and system‘s functionalities
Final report is required for documentation on the overall project,
including; end results, success, failures, etc.
May-06-13
Senior Design Page 5 10/22/2011
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 project‘s successful completion and the detailed explanation of
the different project execution phases.
2.1. Functional Requirements
The following defines exactly what the 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 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.
May-06-13
Senior Design Page 6 10/22/2011
2.2. Design Constraints
This section outlines the design constraints of the product. This section is
derived from the assumptions and limitations list, functional requirements
and other decisions made by the team members.
1. The control module will need to be shielded against electrostatic
discharges. This will increase reliability of the system.
2. The user must have connectivity to the GSM network and any
communication with the system will be in the form of text messaging. If
the user does not have a useable sim card to place into the GM28
cellular module, then the system will not be able to receive user data.
Without connectivity to the GSM network the system will be inoperable.
3. Only devices that can be controlled or monitored via electrical (non-
mechanical) means are possible candidates for use in this system.
There are no moving parts associated with this system. All moving
parts are to be incorporated with our system and interfaced via
electrical I/O pins.
4. The system will not provide power to the controlled devices. The
controlled devices must be connected to a 120V power source along
with the GM28 and the microcontroller.
May-06-13
Senior Design Page 7 10/22/2011
2.3. Approaches Considered and One Used
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.3.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
Pros: The following are the attributes that are desirable about this
cellular module
850/1900 MHZ operating frequencies
Low power usage 5V+-10% at 250mA voice and 350mA data
C source code libraries available
Controlled via AT commands
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 10/22/2011
Part number: GM28/29
Pros: The following are the attributes that are desirable about this
cellular module
850/1900 MHZ operating frequencies
Integrated SIM card holder
RS232 via DB9 connector
Easily programmable in C language
Cons: The only attribute that makes this product less desirable in
comparison to other products is the higher voltage usage 5-32V.
Current value specifications of this module are not available but
presumed comparable to other modules.
Part Number: GR47/GR48
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
Controlled via AT commands
Universal Developers‘ kit available
Cons: The only attribute that makes this product 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: EE54 Edge
Pros: The following are the attributes that are desirable about this
cellular module
850/1900 MHZ operating frequencies
USB 2.0 connection
Controllable via AT commands
Universal Developers‘ kit available
On board SIM card holder
Cons: The only attribute that makes this product less desirable in
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 10/22/2011
Part Number: CM52
Pros: The following are the attributes that are desirable about this
Cellular module
850/1900 MHZ operating frequencies
40 pin DIP Connector
Controllable via AT commands
Universal Developers‘ kit available
Cons: The only attribute that makes this product less desirable in
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
developer‘s kit is not necessary for this entirely enclosed device.
May-06-13
Senior Design Page 10 10/22/2011
2.3.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 light‘s power supply circuitry and
the microcontroller‘s 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 microcontroller‘s logic
voltage levels and 120 VAC circuitry is not available with CMOS gates.
May-06-13
Senior Design Page 11 10/22/2011
2.3.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 10/22/2011
Table 1 – STK200 Starter Kit
STK200 Starter Kit by Kanda
Compatible Microcontroller
ATtiny12 AT90S1200 ATmega48
ATtiny13 AT90SS2313 ATmega8
ATtiny15 AT90S2343 ATmega88
ATtiny22 AT90S2333 ATmega8515
ATtiny2313 AT90S4414 ATmega8538
ATtiny26 AT90S4433 ATmega16
AT90S8515**(8K
bytes in-system
programmable Flash) ATmega161
AT90S8535 ATmega162
ATmega163
ATmega168
ATmega32
ATmega323
Board Features
Cable/Connection ISP and RS232
Power Consumption 9-15VDC or 7-12VAC
I/O 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 (minimum requirement)
Software Application Builder
AVR Studio 3 and 4
AVREdit and AVRGCC
Price $66
May-06-13
Senior Design Page 13 10/22/2011
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 10/22/2011
Table 2 – STK300 Starter Kit
STK300 Starter Kit by Kanda
Compatible Microcontroller
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
Accompanied Development Software
Minimum hardware and 80386 Processor or Above
software requirements
1 MB Ram
1 MB Free Hard Disk Space
Windows 3.1 or Windows 95 (minimum requirement)
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 10/22/2011
Application Builder is also included with the kit. Also included in the kit
is AVR ISP software that supports programming via PC‘s parallel port.
Programming through PC‘s 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
Compatible Microcontroller
MC68HC11E9 (12K Flash/EPROM; 512 RAM; 512 EEPROM; 38 I/O)
Board Features
Cable/Connection PC COM port
Power Consumption 7-18VDC
I/O 38-pins
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
Accompanied Development Software
Minimum hardware and
software requirements 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 10/22/2011
Cons:
The main disadvantage of Freescale (Motorola) MC68HC11E9 Starter
is its price is considerably higher then the previous 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.
Table 4 – Philips 51 Plus Starter Kit
8051 Starter Kit Philips XA/RD/66x
Compatible Microcontroller
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
Accompanied Development Software
Minimum hardware and
software requirements 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:
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.
May-06-13
Senior Design Page 17 10/22/2011
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
Reason for Selection
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 10/22/2011
2.3.4 Programming Language Considerations
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 microcontroller‘s
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 language‘s 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 10/22/2011
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 object-oriented 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.
Reason for Selection
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 team‘s selected microcontroller.
May-06-13
Senior Design Page 20 10/22/2011
2.3.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.
Reason for Selection
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 10/22/2011
2.3.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” 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
user’s home:
The cell phone message commands will have to be setup by the user.
The entire list of acceptable messages can be found in Appendix C.
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.
May-06-13
Senior Design Page 31 10/22/2011
Thermostat Control:
Figure 5 –Thermostat Control Schematic
May-06-13
Senior Design Page 32 10/22/2011
Digital Thermostat Operation
Figure 6 - Thermostat Application Module Schematic Diagram
Important components of digital thermostat:
MAX6625 – 9-Bit/12-Bit temperature sensors with I2C-
compatible serial interface.
AT24C128 – Two-wire serial EEPROM
74HCT4052 – Dual 4-channel analog multiplexer, demultiplexer
HEADER – Microcontroller
In Figure 6 the digital thermostat operates by 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 A/C(cool down) or turn
on the heater(warm up).
May-06-13
Senior Design Page 33 10/22/2011
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
system‘s 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 34 10/22/2011
How the Thermostat will Work
The control for the thermostat will work by having these messages
and how they work:
―thermo status‖ – this instruction will send the user the room
temperature so the user can decide what he wants to do with
that information. From this, the user will decide what action to
take.
―set thermo temp to XX‖ (desired temperature will go here) –
this instruction will tell the microcontroller to change the desired
temperature of the room to the new desired temperature.
―thermo off‖ – 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 kit‘s 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 35 10/22/2011
STK300
port A, bits STK300
0,1,2 port A, bit 3
0 1 2 3
Control
relays
R0
R1
R2 Manual/Remote
select
Node A Node B
R3
Power from 120VAC Fan Switch
outlet M
Fan Motor
Figure 7 –Fan Control Schematic
Speed control:
The fan‘s manufactured speed control circuitry consists of a 4
position switch—of which 3 positions correspond to fan speeds
and the 4th corresponds to the off position—and 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 switch‘s winding
connection and the manual/remote select switch. R0-R2 is
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 36 10/22/2011
Device operating status detection:
The operating status of a device is determined by measuring a
voltage drop across a very small resistor in series with the device
load. The series resistor only decrease the normal power delivered
to the device by 0.8%. The voltage across the series resistor is
measured by an instrumentation amplifier corresponding on figure 8
to the first three operational amplifiers on the left. The signal is then
rectified by a diode bridge and sent to an active op-amp based
filter. The result is a dc signal with voltage level of 5 when the
device is running and 0 when it is off. This signal is read at one off
the control unit‘s microcontroller I/O ports as a binary input.
Figure 8 – Fan Status Signal Circuit Schematic
May-06-13
Senior Design Page 37 10/22/2011
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.
STK300 STK300
port B, bit 0 port B bit 1
Control
relay
Manual/Remote
select
Light Switch
Power from
120VAC
outlet
Figure 9 – Light Schematic
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 developer‘s kit. See
appendix A and B at the end of this document for the GSM and
microcontroller images.
May-06-13
Senior Design Page 38 10/22/2011
2.5. Implementation Process Description
The implementation process and materials used shall be described in
this section. There were two main components to this project: hardware
and software. Each of these components will be discussed separately.
Upon completing discussion on both the hardware and software aspects,
the integration of both parts shall be discussed and any problems
encountered.
SOFTWARE
For the software, initial development was to be performed on a Microsoft
Windows operating system. It was easier to perform the serial
programming on a Unix-based system. There were several serial drivers
available for download from the Internet. It was easier for the team do
develop with Unix, so the development continued in the Unix
environment.
The software ran into a problem when trying to send messages to the
remote user. When using Microsoft Window‘s hyper-terminal, it was
possible to send the AT command ‗at+cmgs=‖remoteUserNumber‖‘ then
the system would prompt back with a prompt. At the prompt, the text
message should be entered in and then submitted with ―CTRL+Z‖.
During the coding implementation, the message
‗at+cmgs=‖remoteUserNumber‖‘ was again sent. The system would
again respond with the prompt but would however continue to prompt
until eventually a PDU error resulted. The exact definition of the error is:
+CME 304 error: “invalid PDU format”
HARDWARE
The Implementation of the status detection was modified to
accommodate the fact that successful application of power supply
across a controlled devices does not ensure that the device is running.
Current detection was chosen as the preferred means of verifying that a
device is actually running. The initial design only measured the voltage
applied across a controlled device as an indicator of the success of a
control command, whereas the design included in this document
measures the potential difference across a resistor which can only be
due to running current in the controlled device.
The utilization of the STK300 microcontroller has been through the IDE
that was included with the microcontroller kit. Code development took
place in the C language and has been in developed in Notepad. After
such, the code is then compiled into hex format using the avr-gcc.exe,
which then can be loaded into the microcontroller. Debugging and
May-06-13
Senior Design Page 39 10/22/2011
simulation of the developed codes was in the AVR Studio 4 IDE
environment. AVR Studio 4 also has the capability to do real-time in-
circuit debugging which has made code development very efficient.
The difficulty the team encountered while working with the STK300 has
been figuring out the configuration necessary so that the software can
compile C languages. This problem was resolved after seeking help from
Doug Oschner, a Senior Engineer at Maytag Corp. The team resolved
this issue and was able to fully utilize C code on the microcontroller.
INTEGRATION
The software that was discussed previously was loaded onto the
microcontroller and compiled. There had to be changes made to the
software in order to function properly in the new environment. Utilization
of the UART registers was necessary for transmitting and receiving data
over the serial port. This meant that instead of writing to a file as is the
case in a Unix environment, the team had to make this change. In
addition, reading from the serial port required the team to check if the
receive bit was high. This meant that the incoming buffer had data
waiting. Instead of reading a line from the serial port, it was now
necessary for the team to read and add to the string in 8-byte increments
(this was the size of the I/O buffer).
The STK300 integration into the system is required for execution of
various essential system functions. By utilizing the I/O pins of the
STK300, the team can control various relays that would determine the
different settings of controlled devices. The I/O pins are also used to
detect the rectified voltages from the voltage status circuit to sense the
status of the controlled device.
The STK300 also included a serial communication port that could send
instructions and receive information from the GM28. To send instructions
to the GM28, the STK300 sent out a string of predefined AT command
that interfaced with the GM28. The receive information from the GM28 is
stored into the buffer of the STK300, where it was parsed for
authentication and command string. The command string initializes the
proper function to be executed by the STK300 to either control devices
or sense the status of a device.
To interface with the thermostat, a different approach will be utilized that
differs from just controlling the relays. The team identified that the LCD
for the thermostat has nine output pins. From these nine output pins, the
team decoded the combination required to control each segment on the
LCD‘s display, see Figure 10.
May-06-13
Senior Design Page 40 10/22/2011
Green/Gray
Yellow/Blue
Black/Blue
W
Br
Bl W hit
Bl o Bl
k/ hit e/
k/ w ue
Gr e/ Gr
G n/ /G
ee Bl ee
ol Gr re
n ue n
d ey y
Figure 10 – Decode LCD Display Matrix
The signal from these output pins will go through a rectified circuit and
the resulting rectified signal will be read from the I/O pins. After receiving
the signal from the I/O pins, the microcontroller runs a function that
decodes the signals and the LCD display from the thermostat can now
be read. Reading the LCD display is crucial in controlling and monitoring
the thermostat because the current temperature and temperature setting
of the thermostat can now be received by the microcontroller. After
gathering the necessary information from the thermostat, the
microcontroller then controls the buttons of the thermostat via I/O pins to
execute of the user‘s command.
May-06-13
Senior Design Page 41 10/22/2011
2.6. Testing of the End Product and Results
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 newly-added 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.
May-06-13
Senior Design Page 42 10/22/2011
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 mostly 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 microcontroller‘s corresponding communication port.
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 user‘s 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.
May-06-13
Senior Design Page 43 10/22/2011
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 microcontroller‘s
required input value. The test will be considered a failure otherwise.
I/O Port Manipulation and Detection
The ability of I/O to detect an input voltage and store a value in the
microcontroller‘s 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.
Power Surge Performance
The circuit‘s power surge protection will be tested for acceptable
performance by EE team members using the following procedure:
The circuit‘s 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 chip‘s manufacturers. The
test will be considered a failure if the measured characteristics of the
power supply‘s output do not meet the manufacturers‘ requirements.
May-06-13
Senior Design Page 44 10/22/2011
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.
Success/failure criteria: The testing will be considered successful 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:
A simulated device status will be written to the I/O in debug mode.
The simulated status will trigger the execution of the
microcontroller‘s 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.
Success/failure criteria: The testing will be considered successful 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.
May-06-13
Senior Design Page 45 10/22/2011
End Product Testing
The end-product functionalities will be tested by team members and non-
team 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-product‘s 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.
May-06-13
Senior Design Page 46 10/22/2011
2.7. End Results of the Project
The end result for each major components of the product will be summarized
in this section. This will include expected to actual operation comparison of
each system component and component satisfactory. Any significant
accomplishments or research activities not covered elsewhere and major
failures will also be documented in this section.
GM28:
The overall operation of the GM28 module matched the team expectation.
The module was able established communication with the GSM network,
receive SMS messages, and relay the received messages via serial port.
The team is still in the process of researching how to utilize the sent
message function on the GM28. Once this is established, the GM28 will
then match all of the required criteria outlined in the Section 2.4.
Team members are satisfied for having chosen this module because it
was compact, enclosed, and easy to interface.
STK300:
The STK300 has all the functionality outlined in Section 2.4. This includes
I/O pins interface and serial communication capability. The AVR Studio 4
included allows the team to simulate the program before loading it onto
the microcontroller and the JTAG kit included allows the team to do in-
circuit debugging. These features will allow the team to code very
efficiently. The team did not anticipate the amount of time required to set
up the IDE software included with the kit to be compatible with C. This
issue is now resolved.
Team members are satisfied for having chosen the STK300 because it is
a versatile kit that has functionality far exceeds what was outlined by the
design report. The kit also allows efficient programming because it has a
simulation and in-circuit debugging capabilities.
Control Appliances:
The circuit designed for controlling the fan and the light in Section 2.4 was
successfully implemented in lab work. The thermostat temperature was
also successfully read by looking from the LCD output pins. The circuit for
controlling the temperature setting of the thermostat still needs to be
implemented. The major problem that the team encountered is in
redesigning voltage detector circuit to a current detector circuit to be use
as a status signal. This problem is due to having same ground for both AC
and DC voltages and were resolved.
May-06-13
Senior Design Page 47 10/22/2011
3. 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 three parts to each of these components: the original
estimate, a combination of actual personnel hours to date and revised future
personnel hours, and the actual 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 48 10/22/2011
Table 5 – Personal Effort in Hours
Implementation
Documentation
Demonstration
Consideration
and Selection
Definition
End-Product
End-Product
End-Product
End-Product
End-Product
Problem
Technology
Reporting
Total
Testing
Project
Design
Original Projected Effort
Adam Mohling 5 12 15 50 25 25 10 42 184
Chau Nguyen 5 10 20 35 35 20 10 35 170
Issa Drame 5 12 20 35 30 15 10 45 172
Arturo Palau 5 10 25 0 0 0 0 30 70
Other
0 0 0 0 8 0 0 0 8
Resources
Total 20 44 80 120 98 60 30 152 604
Adjusted Projected Total Effort
Adam Mohling 6 13 5 50 25 25 10 56 190
Chau Nguyen 5 18 5 35 35 20 10 50 178
Issa Drame 6 28 5 35 30 15 10 55 184
Arturo Palau 6 11 5 0 0 0 0 52 74
Other
0 0 0 0 8 0 0 0 8
Resources
Total 23 70 20 120 98 60 30 213 634
Final Total Effort
Adam Mohling 6 13 5 95 25 45 5 67 261
Chau Nguyen 5 18 5 90 35 20 5 56 234
Issa Drame 6 28 5 97 30 20 5 57 248
Arturo Palau 6 11 5 0 0 0 0 52 74
Other
0 0 0 5 2 0 0 0 7
Resources
Total 23 70 20 287 92 85 15 232 820
May-06-13
Senior Design Page 49 10/22/2011
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.
The team also greatly underestimated the amount of time that would
go into the development stage of the project. There were many
unforeseen errors that arose during development. Some of the tasks
(such as current detection) that did not sound very difficult ended up
requiring a large amount of hours to resolve.
For other resources, the team contacted a former manager of one of
the team members for help setting up the microcontroller. This
manager helped get a C compiler installed and working and helped the
team understand how to manipulate the I/O connections.
May-06-13
Senior Design Page 50 10/22/2011
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 51 10/22/2011
Table 6 – Financial Requirements
Without
Item With Labor
Labor
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 $0.00
Labor (at $10.30/hr)
Adam Mohling $1895.20
Chau Nguyen $1751.00
Issa Drame $1771.60
Arturo Palau $721.00
Subtotal $0.00 $6138.80
Total $6339.80
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 $1957.00
Chau Nguyen $1833.40
Issa Drame $1895.20
Arturo Palau $762.20
Subtotal $6447.80
Total $6876.80
May-06-13
Senior Design Page 52 10/22/2011
Final Total Cost
Parts and Materials
GM28 GSM Cellular module $0.00
GM28 Power Supply $0.00
GM28 Antenna $0.00
Microcontroller Starter Kit $0.00
Prepaid Cellular Phone $20.00
Fan $30.00
Thermostat $15.16
Cable $5.95
Misc. Electronic Components $20.22
Poster $17.50
** Additional circuit
components (Table 7 below) $40.08
Subtotal $148.91
Labor (at $10.30/hr)
Adam Mohling $2688.30
Chau Nguyen $2410.20
Issa Drame $2554.40
Arturo Palau $762.20
Subtotal $8415.10
Total $8564.01
Table 7 – Detailed Circuit Financial Requirements
Part Number Description Unit price Qty Subtotal
588-12FR080 .8 ohm res 1.56 4 $6.24
511-UA741CN op amp 0.25 16 $4.00
512-1N3595 diodes 0.08 12 $0.96
660-RC1/4TT52R104J 100k res. 0.13 5 $0.65
588-43F-4K 4k res. 1.91 3 $5.73
293-2K/REEL 2k res. 0.1 3 $0.03
294-1K-RC 1k res. 0.14 6 $0.84
140-MLNP50V.22 220nf cap. 0.3 5 $1.50
SPST-NO
655-T77S1D10-05 relay 1.56 5 $7.80
655-T73S5D15-05 SPDT relay 2.03 3 $6.09
backup
PIC18LF452-I/P microcontroller 5.97 1 $5.97
Total $40.08
May-06-13
Senior Design Page 53 10/22/2011
3.2. Schedules
To date, the team has managed to stay close to the projected schedule. The
only major difference between the previous and current Gantt chart is that the
team‘s project poster has been moved to the 2 nd semester of the course. The
rest of the scheduling issues will be addressed in their related sub-sections.
Figure 11 – Original Project Schedule Summary
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 12 – Final Project Schedule Summary
May-06-13
Senior Design Page 54 10/22/2011
Scheduling for the team was separated into the two main section of the
project, project reporting and project development. The project development
followed very closely to the projected hours, however the development did
not. The development took a little longer to begin due to delays from Kanda in
sending the team‘s microcontroller. The following Gantt charts shows the
hours spent on each portion of the project.
Figure 13 – Original Project Reporting Schedule
May-06-13
Senior Design Page 55 10/22/2011
Figure 14 – Design Report Project Reporting Schedule
** Notice the project poster is the only change from the previous to the
current schedule.
May-06-13
Senior Design Page 56 10/22/2011
Figure 15 – Final Project Reporting Schedule
For the final project reporting schedule, there is not much of a change to
report because a majority of the reporting was completed the previous
semester. The only major change to be reported is that the team did not
start work on the final report as planned. Instead, work began
approximately one week later than expected. The reason for this is the
team was busy working on the development portion of the project.
May-06-13
Senior Design Page 57 10/22/2011
Figure 16 – Project Development Schedule
Since the team had not reached the development stage by the time of the
design report, there was never a proposed change to the project
development schedule. This being the case, there is only an original and
an actual project development schedule to report.
May-06-13
Senior Design Page 58 10/22/2011
Figure 17 – Final Project Development Schedule
This schedules shows what the team was able to complete over the
course of the two semester of enrollment in the senior design course.
May-06-13
Senior Design Page 59 10/22/2011
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 Evaluation
There are many factors to take into consideration while evaluating the
overall success / failure of this team project. The most logical way of
evaluating the project is to follow the Gantt charts created at the beginning
of the project and referenced in the previous section.
The reporting for the entire project went very well. The team showed
improvement on all documents as the semester progressed. All
documents were completed on time with minimal ―crunch time‖ every
required by the team members. The only exception to this was for the final
report. The team was very busying working on the development stage that
the documentation was pushed back and started one week later then what
was planned.
The poster was originally presumed to be due during the first semester, so
the team had this nearly completed before the end of the first half of the
semester. This is why the Gantt chart shows work on the poster spanning
over such a great deal of time. There was too much information to place
onto the poster in order to completely meet all the poster criteria and the
main complaint about the team‘s poster was that the type was too small.
Development for the team was much more difficult than originally
expected. There was not enough support on the team to complete this
project with just three members. The team often caught themselves
working 10 hour days during the week and sometimes more on the
weekends. Most of this time was spent researching how to manipulate the
components of the system. Although a great deal of knowledge was
obtained during this time, some obstacles still remained uncompleted.
May-06-13
Senior Design Page 60 10/22/2011
In order to complete the project on time, some tasks were dropped from
the team‘s proposed development task set. A majority of these were not
required, just were thought to be convenient to the system. These tasks
are as follows:
Implement surge protection
Battery backup implementation
Test battery backup operation
Test battery backup lifetime
Functionality menu interface
Other features were met during the development of the system. These
tasks are as follows:
Test security protocols
Test user message integrity
All of the proposed controlled devices have been simulated by the team
and can be controlled by applying voltages to the correct I/O pins. The
team was able to also decode the LCD display of the thermostat and
manipulate the values sent to the LCD. This was very impressive because
the team was not sure if this could be done. The problem with this is that it
required many more I/O pins to read and decode the value of the LCD.
Fortunately, the team accounted for the need for additional I/O pins and
this was therefore not a problem.
Compiling code on the STK microcontroller was a success. This allowed
the team to be able to read I/O pins that were connected to the controlled
devices. This was also viewed as a success by the team.
Connectivity to the GM28 was established. Software was created that was
able to receive messages sent by remote users and the data was parsed
and made available for processing. Settings on the GM28 were also able
to be set and manipulated providing for additional functionality. A major
obstacle for this portion of the project was sending a message to the
remote users resulted in the GM28 returning a +CME 304 error: ―invalid
PDU format‖. This error means that the message to be sent was not of a
valid PDU format, however the team was not sending messages in the
PDU format (the team was using text format). Even after changing to the
PDU format and changing the modem to accept PDU format messages,
the problem still persisted. Upon running the software on the STK, the
problem resolved itself.
May-06-13
Senior Design Page 61 10/22/2011
Status detection for the team proved to be quite an obstacle. What
seemed to be a simple task became a length task. The team was finally
able to answer this problem and a current detection circuit is shown in
figure 8.
Taking all of these factors into consideration, the project was seen to be
almost as a success. Users were able to control devices from a remote
location. The status of a device was able to be acquired. The users
interacting with the system could be properly authenticated. Users were
able to receive notification of the resultant outcome of their request. The
only problems that arose during the project were that there was not
enough time to do full system testing. All the testing had to be done along
the way.
May-06-13
Senior Design Page 62 10/22/2011
4.2 Commercialization
This system can be used to utilize M2M connectivity and provide a great
deal of efficiency to a business environment. Primary candidates for
remote monitoring include but are not limited devices such as:
Monitoring a vending machine and reporting back when a particular
product is running low. This would increase sales if a product was
always available to the customer.
Remotely monitoring the use of appliances in a building
Creating a log of the actions within a building such as when a door
was opened, light turned on/off, etc.
This product would be feasible for commercialization to a typical
household due to the amount of effort that goes into interfacing the system
with target controlled devices. A company could profit from and save man
hours by using this system. This system could replace sending an
employee to a remote site for simple monitoring of an event.
If an entity wanted to be signaled when an event took place, they could
use this system. The cost of having a security guard, for example, would
be much more expensive than installing this system. A message could be
sent stating that a door has been opened and proper actions could then
be deployed.
All printing was performed from the Coover labs and was taken from team
member‘s print quotas. These costs were ignored due to the fact that the
team did not incur any additional financial burdens from printing in this
manner.
4.3 Additional Work
Since this project is not an ongoing project, there will not be any work to
be done after the end of this semester. If this project was to be handed on
to another team, the documentation and current circuit designs would be
made available to the incoming team. An informative session lasting
approximately one hour would also be necessary to guarantee any special
instructions were included.
May-06-13
Senior Design Page 63 10/22/2011
4.4 Lessons Learned
The following is a list of the experiences gained by this group in the
processes of developing this project. The experiences are classified in two
groups: Project experience and new technical knowledge gained.
New Technical knowledge
The mechanics of and LCD matrices
The details of AC/DC signal conversion
The SMS text message
Serial programming
Furthered C programming skills
Development of code for a microcontroller
The use of relays, and optocouplers for control applications
FTP and shared storage resources for files and other information
Project Experience
Professional project planning, scheduling, conducting and
management.
Personal time management required to efficiently contribute to this
type of project
Use of outside resources when the team was not able to figure out
the complicated issues
Including ‗slack time‘ is very important in a project and is necessary
to handle unforeseen events.
The need for an individual to facilitate the project also exists.
Someone to make sure that tasks start on time and are being
completed in a reasonable amount of time.
Time management
May-06-13
Senior Design Page 64 10/22/2011
4.5 Risk and Management
The anticipated potential risks and planned management for the project
are as follows:
1. Loss of team member(s)
There will be always at least two team members that are involved with
designing of every subsystem. This will ensure that at least two team
members who are familiar with every subsystem. So in the event of losing
a team member, there will be a secondary team member who can take
over the responsibilities.
2. Lack of expertise in team members
Adequate time to research the technology will be required after selecting
the technology to be used in the project. Team member are also
responsible to seek out help where ever it applies. Frequent meeting and
project update with faculty advisor will ensure correct approaches are
utilized in the completion of the project. In the even that the team is not
able to perform the necessary development on their own, outside sources
will be consulted.
3. Legal risk of product failure/defect
Appropriate warnings will accompany the product.
4. Electric shock
Proper electric device practices will be included in the product manual and
warnings will be posted in a highly visible spot on the product.
5. Delay in receiving components
In the even that one of the system components happens to be delayed,
the team will work on other portions of the product. This will ensure that
the project will not fall behind schedule and create slack later in the
project‘s life.
May-06-13
Senior Design Page 65 10/22/2011
The anticipated risks actually encountered and the success in
management of the risks will now be discussed.
1. Loss of a team member
The team found out rather early on in the project that one of the team
members would only be working on the project for half of the semester.
For this reason, this team member was assigned to mostly documentation
and other tasks that would not necessarily be followed. This way this team
member would not cause such an impact on the team after they left.
2. Lack of expertise amongst team members
For this risk, the team consulted a former employee of one of the team
members that was proficient with microcontroller programming. This
individual was able to help the team compile C code on the microcontroller
and perform initial serial communication.
3. Delay in receiving components
The team members focused on other aspects of the project such as circuit
design and testing.
May-06-13
Senior Design Page 66 10/22/2011
The unanticipated risks encountered will now be discussed. The attempts
to manage these risks and the success and/or failures of which will now
be discussed.
1. Failure of a system component
The team happened to break the fan component of the system. The initial
decision to use this fan was because one of the team members owned
this same fan and had performed the initial design development at home.
The decision was made to then use this fan, and if this fan is also
damaged, the team will purchase another fan for this member. The team
knows what happened to cause the fan to be damaged and can therefore
prevent this from happening again.
2. Failure of the Pre-Paid cell phone sim card
The team purchased a Pre-Paid cell phone from Wal-Mart and had
planned to use this sim card in the GM28 to bed used in the system.
When activating the sim card, the team had to register a phone serial
number as well as a serial number for the sim card. The sim card was
then placed in the GM28 and the GM28 returned a ―No GSM service
available‖ or ―No sim card detected‖. Upon placing another sim card in the
GM28 from a team member‘s phone, the GM28 performed as projected.
The team realized that the registered sim card only worked in the
matching cell phone. Both sim cards used the same GSM network and
should have at least been classified as ―roaming‖ if they did not use the
same carrier. The team decided to continue using the team member‘s sim
card.
3. Failure of the C code to perform message sending
By writing to the serial port in a UNIX environment, the GM28 would cause
a ―+CME 304 error: ‗invalid PDU format‘‖. The team then decided to send
sms messages the GM28 would have to toggle between text and PDU
format in order to send messages. This however, also produced the same
response.
The resultant changes made to the risk management because of the
encountered unanticipated risks are that these risks were added to the risk
section of the documentation.
May-06-13
Senior Design Page 67 10/22/2011
4.6 Project Team Information
Client Information
Senior Design, Iowa State University
Dr. John W. Lamont Prof. Ralph Patterson III
324 Town Engineering 326 Town Engineering
Ames, IA 50012 Ames, IA 50012
(515) 294-3600 (515) 294-2428
jwlamont@ee.iastate.edu repiii@iastate.edu
www.ece.iastate.edu
Faculty Advisor Information
Prof. Ahmed E. Kamal, Professor
Iowa State University
Ames, IA 50011-3060
(515) 294-3580
FAX 515 294-8432
kamal@iastate.edu
www.public.iastate.edu/~kamal
Department of Electrical and Computer Engineering
3222 Coover Hall
Ames, Iowa 50011
Student Team Information
Arturo Palau – EE Chau Nguyen – EE
80 Linden Devitt 137 S. Franklin Ave.
Ames, IA 50011 Ames, IA 50014
(515)708-3812(Cell) (319)321-8619
apalau@iastate.edu chayman@iastate.edu
Issa Drame – EE Adam Mohling – CprE
4335 Frederickson Court 2635 Knapp St.
Ames, IA 50010 Ames, IA 50014
(515)572-7820 (515)292-2161(Cell)
issad@iastate.edu mohbandy@iastate.edu
May-06-13
Senior Design Page 68 10/22/2011
4.7 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.8 Reference:
Senior Design Course Notes – Iowa State University
Available at http://seniord.ee.iastate.edu/notes/
4.9 Appendix
May-06-13
Senior Design Page 69 10/22/2011
Appendix A
GM28 GSM Module Images
May-06-13
Senior Design Page 70 10/22/2011
Appendix B
STK300 Microcontroller Developers Kit Images
May-06-13
Senior Design Page 71 10/22/2011
Appendix C
List of approved commands for the
Cell Phone Based Remote Home Control System
LIGHT:
LIGHT ON
LIGHT OFF
LIGHT STATUS
FAN:
FAN STATUS
FAN OFF
FAN LO
FAN MED
FAN HI
THERMOSTAT:
THERMO STATUS
ALERT THERMO ABOVE XX
ALERT THERMO BELOW XX
INCREASE THERMO TEMP BY XX
DECREASE THERMO TEMP BY XX
SET THERMO TEMP TO XX
SYSTEM COMMANDS
CHANGE PASS
SYSTEM SHUTDOWN
May-06-13
Senior Design Page 72 10/22/2011