cell phone based remote home control...

Cell Phone Based Remote Home Control SystemMay-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 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

November 3, 2005

Table of Contents

1. INTRODUCTORY MATERIALS .......................................................................................... 1

1.1. EXECUTIVE SUMMARY...........................................................................................................11.2. ACKNOWLEDGEMENTS..........................................................................................................31.3. PROBLEM STATEMENT..........................................................................................................31.3.1. GENERAL PROBLEM STATEMENT.....................................................................................31.3.2. GENERAL SOLUTION APPROACH......................................................................................31.4. OPERATING ENVIRONMENT..................................................................................................31.5. INTENDED USERS AND INTENDED USES..............................................................................41.6. ASSUMPTIONS AND LIMITATIONS.........................................................................................41.6.1. ASSUMPTIONS LIST...........................................................................................................41.6.2. LIMITATIONS LIST...............................................................................................................51.7. EXPECTED END PRODUCT AND OTHER DELIVERABLES....................................................5

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

2.1. APPROACH USED..................................................................................................................62.1.1. DESIGN OBJECTIVES.........................................................................................................62.1.2. FUNCTIONAL REQUIREMENTS...........................................................................................72.1.3. DESIGN CONSTRAINTS......................................................................................................72.1.4. TECHNOLOGY CONSIDERATIONS......................................................................................82.1.4.1. CONSIDERED CELLULAR MODULES..............................................................................82.1.4.2. CONSIDERED AC / DC INTERFACES...........................................................................112.1.4.3. CONSIDERED MICROCONTROLLERS............................................................................122.1.4.4. PROGRAMMING LANGUAGE CONSIDERATION.............................................................192.1.4.5. DEVELOPMENT ENVIRONMENTS CONSIDERED...........................................................212.1.4.6. CONSIDERED CODING STYLES....................................................................................222.1.5. TESTING............................................................................................................................232.1.6. PROJECT CONTINUATION................................................................................................262.2. DETAILED DESIGN...............................................................................................................272.2.1 CODING DETAILS..............................................................................................................272.2.2 MICROCONTROLLER DETAILS..........................................................................................312.2.3 GSM MODULE DETAILS...................................................................................................37

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

3.1. ESTIMATED RESOURCE REQUIREMENTS...........................................................................383.1.1. PERSONNEL RESOURCES................................................................................................383.1.2. FINANCIAL REQUIREMENTS.............................................................................................403.2. SCHEDULES.........................................................................................................................42

May-06-13Senior Design Page i 5/8/2023

TABLE OF CONTENT CONTINUED

4. CLOSURE MATERIALS ..................................................................................................... 46

4.1 PROJECT TEAM INFORMATION............................................................................................464.2 CLOSING SUMMARY.............................................................................................................474.3 REFERENCE:.........................................................................................................................474.4 Appendix..............................................................................................................................47

May-06-13Senior Design Page ii 5/8/2023

List of Figures

Figure 1 – Overall System Flow Diagram..............................................................................................2Figure 2 – GM28 Cellular Module..........................................................................................................10Figure 3 – STK300 Starter Kit.................................................................................................................18Figure 4 – Bracket Coding Standard....................................................................................................22Figure 5 –Thermostat Control Schematic...........................................................................................31Figure 6 - Thermostat Application Module Schematic Diagram...................................................32Figure 7 –Fan Control Schematic..........................................................................................................35Figure 8 – Fan Status Signal Circuit Schematic................................................................................36Figure 9 – Light Schematic.....................................................................................................................37Figure 10 – Original Project Schedule.................................................................................................42Figure 11 – Current Project Schedule..................................................................................................42Figure 12 – Original Project Reporting Schedule.............................................................................43Figure 13 – Current Project Reporting Schedule..............................................................................44Figure 14 – Project Development Schedule............................................................................................45

May-06-13Senior Design Page iii 5/8/2023

List of Tables

Table 1 – STK200 Starter Kit.....................................................................................................13Table 2 – STK300 Starter Kit.....................................................................................................15Table 3 – Freescale MC68HC11E9 Starter Kit...........................................................................16Table 4 – Philips 51 Plus Starter Kit..........................................................................................17Table 5 - Personnel Effort in Hours...........................................................................................39Table 6 - Financial Requirements.................................................................................................41

May-06-13Senior Design Page iv 5/8/2023

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 java-based 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 Developer’s 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-13Senior Design Page v 5/8/2023

1. Introductory MaterialsThis 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 SummaryThis document outlines the May0613 senior design team’s 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-13Senior Design Page 1 5/8/2023

Figure 1 – Overall System Flow Diagram


1.2. AcknowledgementsSpecial thanks are extended to Professor Ahmed Kamal for his support and mentorship towards the development and success of this project.

1.3. Problem StatementThe 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 StatementThe 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 ApproachThe 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 EnvironmentThe 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.


1.5. Intended Users and Intended UsesThis 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 LimitationsThis section lays out the assumptions and limitations of the project.

1.6.1. Assumptions ListFollowing 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


1.6.2. Limitations ListListed 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 DeliverablesThe 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 networko Monitor a device status from an electronic interfaceo 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 system’s functionalities Final report is required for documentation on the overall project,

including; end results, success, failures, etc


2. Approach and Product Design ResultsThe 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. 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 two-semester period.

2.1.1. Design ObjectivesIncluded 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


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


2.1.4. Technology ConsiderationsThis 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 ModulesPart Number: GM47/48Pros: 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/42Pros: 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.


Part number: GM28/29Pros: 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 power usage 5-32V. Current value specifications of this module are not available but presumed comparable to other modules.

Part Number: GR47/GR48Pros: 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 availableCons: 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 EdgePros: 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.


Part Number: CM52Pros: 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.


2.1.4.2. Considered AC / DC InterfacesTwo 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 gatesPros: Fast switching No static power dissipation Voltage levels are compatible with that of a microcontroller InexpensiveCons:Low voltage levels of operation make the CMOS incompatible with 120Volts AC

RelaysPros:Control high voltage circuitry using low voltages; therefore compatible both with the fan and light’s power supply circuitry and the microcontroller’s circuitryCons: 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.


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:


Table 1 – STK200 Starter Kit

STK200 Starter Kit by KandaCompatible MicrocontrollerATtiny12 AT90S1200 ATmega48ATtiny13 AT90SS2313 ATmega8ATtiny15 AT90S2343 ATmega88ATtiny22 AT90S2333 ATmega8515ATtiny2313 AT90S4414 ATmega8538ATtiny26 AT90S4433 ATmega16

AT90S8515**(8K bytes in-system programmable Flash) ATmega161

AT90S8535 ATmega162 ATmega163 ATmega168 ATmega32 ATmega323Board FeaturesCable/Connection ISP and RS232Power Consumption 9-15VDC or 7-12VACI/O 64-pins

HighlightsSockets for various devices 1x8,2x20, 1x28, 2x40 pin 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 SoftwareMinimum hardware and software requirements 80386 Processor (486 Recommended) 1 MB Ram 1 MB Free Hard Disk Space Windows 3.1 or Windows 95Software Application Builder AVR Studio 3 and 4 AVREdit and AVRGCCPrice $66


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.


Table 2 – STK300 Starter Kit

STK300 Starter Kit by KandaCompatible MicrocontrollerATmega103ATmega603ATmega128**(128K bytes of in-system programmable Flash, 4K bytes of in-system programmable EEPROM and 4K bytes of SRAM)Board FeaturesCable/Connection ISP and RS232; opt. USBPower Consumption

9-15VDC or 7-12VAC

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 circuitry8-way bar LED , 8 Switches 3.3V/5V voltage selectionBrownout (2.9V or 4.5V level)LCD's connectorsDrop-in external RAM, with sockets for Address Latch chip and RAM plus dip headerInclude daughter board with Atmega128 microcontroller

Accompanied Development SoftwareMinimum hardware and software requirements

80386 Processor or Above

1 MB Ram1 MB Free Hard Disk SpaceWindows 3.1 or Windows 95

Software STK300 Application BuilderAVR 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.


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 KitCompatible MicrocontrollerMC68HC11E9 (12K Flash/EPROM; 512 RAM; 512 EEPROM; 38 I/O)Board FeaturesCable/Connection PC COM portPower Consumption 7-18VDCI/O NONEHighlights 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 programAccompanied Development SoftwareMinimum hardware and software requirements DOS or Win 3.1Software AXIDE free Assembler, C compiler and example source codePrice $99

Pros:The main advantage of Freescale (Motorola) MC68HC11E9 Starter KitIs 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.


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/66xCompatible MicrocontrollerP89C51RB2(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 SoftwareMinimum hardware and software requirements Win 95Software Application Builder WINISP and Flash Magic Programming Tools C-compiler Demos (4K max) and SimulatorPrice $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.

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.


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


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.


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.


2.1.4.5. Development Environments ConsideredThis 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.


2.1.4.6. Considered Coding StylesThis 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.

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.


for(i=0; i<10; i++){

if(sampleFunction()) return ans;}

2.1.5.TestingTesting 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 CommunicationThe 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 CommunicationThe 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 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 DecodingProper 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.

Voltage Converter Circuit OperationThe 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.

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.

User AuthenticationThe 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 CorrectnessThe 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.

End Product TestingThe 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.

TestersEach 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 ContinuationCurrently 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 user’s home and the other module will reside on the user’s cell phone (*). Initialization Check & Read Messages Decode Messages Application Control Status Monitoring Send Status Message Text Message Command Templates (*)


INITIALIZATION:The initialization portion will require the following libraries in the project directory:

deftypes.h – Loads type definitions for StringRS232.h – Loads RS232 serial driversSerComm.h – Loads Serial Communication typesATCommand.h – Loads AT Commands for use

Include the entire EWMSDK library in the project:AT CommandsPDU (Protocol Data Unit) FormattingSerial Communication & RS232

AT_InitializeDataThis 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_EstablishChannelThis 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. Don’t 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 module’s Integrator manual.


CHECK & READ MESSAGES:The check and read messages coding module will use the following functions (descriptions of each are provided):

AT+CMGR=1This 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, sender’s 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.


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 belowat+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 user’s 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”


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


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


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


How the Thermostat will WorkThe 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 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.


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


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 fan’s 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 STK300’s ports. The desired voltage is 5 Volts DC. The conversion circuit is implemented at nodes A and B on the fan control’s 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


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 developer’s kit. See appendix A and B at the end of this document for the GSM and microcontroller images.


3. Estimated Resources and ScheduleThis 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.


Table 5 - Personnel Effort in Hours

Prob

lem

D

efin

ition

Tech

nolo

gy

Con

side

ratio

n an

d Se

lect

ion

End-

Prod

uct

Des

ign

End-

Prod

uct

Impl

emen

tatio

n

End-

Prod

uct

Test

ing

End-

Prod

uct

Doc

umen

tatio

n

End-

Prod

uct

Dem

onst

ratio

n

Proj

ect

Rep

ortin

g Total

Original Projected EffortAdam 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 70Other Resources 0 0 0 0 8 0 0 0 8

Total 20 44 80 120 98 60 30 152 604Adjusted 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 74Other Resources 0 0 0 0 8 0 0 0 8

Total 23 70 20 120 98 60 30 213 634


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.


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.


Table 6 - Financial Requirements

Item Without Labor With Labor

Original ProjectionParts and MaterialsComputer Hardware & Software

$0.00

Final Project Enclosure $3.00M2M GSM Controller $140.00Misc. Electronic Components $8.00Poster $50.00

Subtotal $201.00 $0.00

Labor (at $10.30/hr)Adam Mohling $1895.20Chau Nguyen $1751.00Issa Drame $1771.60Arturo Palau $721.00

Subtotal $0.00 $6138.80Total $6339.80Projected Total Cost

Parts and MaterialsMisc. Electronic Components $8.00GM28 GSM Cellular module $231.00GM28 Power Supply $33.00GM28 Antenna $22.00Microcontroller Starter Kit $85.00Poster $50.00

Subtotal $429.00

Labor (at $10.30/hr)Adam Mohling $1957.00Chau Nguyen $1833.40Issa Drame $1895.20Arturo Palau $762.20

Subtotal $6447.80Total $6876.80


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 team’s project poster has been moved to the 2nd 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


Figure 12 – Original Project Reporting Schedule


Figure 13 – Current Project Reporting Schedule

** Notice the project poster is the only change from the previous to the current schedule.


Figure 14 – Project Development Schedule

Since the team has not reached the development stage, there are no comparisons to be made to the team’s projected development schedule. The team is still planning on beginning development of the project during January of 2006.


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 UniversityDr. John W. Lamont Prof. Ralph Patterson III324 Town Engineering 326 Town EngineeringAmes, IA 50012 Ames, IA 50012(515) 294-3600 (515) [email protected] [email protected]

Faculty Advisor Information

Prof. Ahmed E. Kamal, Professor Iowa State UniversityAmes, IA 50011-3060(515) [email protected]

Student Team Information

Arturo Palau – EE80 Linden DevittAmes, IA 50011(515)708-3812(Cell)[email protected]

Issa Drame – EE4335 Frederickson CourtAmes, IA 50010(515)[email protected]


Chau Nguyen – EE 137 S. Franklin Ave.Ames, IA 50014(319)[email protected]

Adam Mohling – CprE 2635 Knapp St.Ames, IA 50014(515)292-2161(Cell)[email protected]

mailto:[email protected]

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 UniversityAvailable at http://seniord.ee.iastate.edu/notes/

4.4 Appendix


http://seniord.ee.iastate.edu/notes/

Appendix AGM28 GSM Module Images


Appendix BSTK300 Microcontroller Developers Kit Images


Appendix C120V AC--5VDC Fan Status Signal Circuit Simulation Results


cell phone based remote home control...

Documents