Device Control via SMS

DEVICE CONTROL USING SMS
AMJAD ANWAR
FA06-BC(CE)-004
MUHAMMAD SHAKEEL
FA07-BS(CE)-143
June 2011
Department of Computer Engineering
COMSATS INSTITUTE OF INFORMATION TECHNOLOGY
WAH CANTT – PAKISTAN

Submission Form for Final-Year
PROJECT REPORT
CIIT-WAH-CE-DP-54F (revision 1.1)
COMSATS Institute of Information Technology, Wah Campus Computer Engineering Department
54F
PROJECT ID DB11-DP-06
NUMBER OF
MEMBERS
2
TITLE DEVICE CONTROL USING SMS
SUPERVISOR NAME HABIB ULLAHAL / EXTERNAL
MEMBER NAME REG. NO. EMAIL ADDRESS
AMJAD ANWAR FA06-BC(CE)-004 amjadanwar004@yahoo.com
M SHAKEEL FA07-BS(CE)-143 mshakeel89@yahoo.com
CHECKLIST:
Number of pages attached with this form
I/We have attached a complete Project Timeline
using the form CE-DP-35A
YES / NO
I/We have enclosed the soft-copy of this document along-with the
codes and scripts created by myself/ourselves
YES / NO
My/Our supervisor has attested the attached document YES / NO
I/We confirm to state that this project is free from any type of
plagiarism and misuse of copyrighted material
YES / NO
MEMBERS’ SIGNATURES
Supervisor‟s Signature
Note 1: This paper must be signed by your supervisor
Note 2: The soft-copies of your project report, source codes, schematics, and executables should be delivered in a CD
Note 3: Submit the report and software to the Degree Projects Coordinator, Computer Engineering Department

Declaration
“No portion of the work referred to in the dissertation has been submitted in support of an
application for another degree or qualification of this or any other university/institute or
other institution of learning”.
MEMBERS’ SIGNATURES

ii
Abstract
The theme of the project is the hardware implementation of a system that is capable of
controlling electric appliances on reception of SMS. Short Messaging Service (SMS) are a
reliable and less costly mean of information delivery. This project utilizes this service with the
final product being a microcontroller-GSM based system which can switch on/off several
devices attached to it, as and when required by the operator. This document summarizes all the
design issues confronted and the steps followed by the project members to complete this project.

iii
Acknowledgement
All the praise to all mighty ALLAH, for bestowing us with the courage, knowledge, health and
wisdom to carry out this project. We are greatly indebted to our parents, without there endless
financial, moral support, patience and prayers the very idea f this project was impossible. We
would like to pay our humble gratitude to our project supervisor Mr. Habib Ullah. His
encouragement was the main source and strength to stimulate us to complete the project. We
are also grateful to all faculty members of COMSATS Institute of Information Technology for
the facilities provided. Without them we would have never been able to run our extensive
computational analysis.

iv
Dedication:
We dedicated this project to all those humble beings who have aided us in any way to become
what we are today. Whose scarifies seeded our success; especially our parents who have felt
our pain beyond us and showered us win never ending prayers and support. We deem them as a
divine source of inspiration.

v
Table of contents
1 INTRODUCTION .............................................................................................................................1
2 LITERATURE REVIEW .................................................................................................................3
3 REQUIREMENTS SPECIFICATION..........................................................................................10
3.1 NON-FUNCTIONAL REQUIREMENTS ...........................................................................................10
3.1.1 Product requirements ...........................................................................................................10
3.1.2 Organisational requirements................................................................................................10
3.1.3 External requirements ..........................................................................................................10
3.2 FUNCTIONAL REQUIREMENTS....................................................................................................11
3.2.1 Category 1 ............................................................................................................................11
4 PROJECT DESIGN ........................................................................................................................12
4.1 METHODOLOGY.........................................................................................................................12
4.2 ARCHITECTURE OVERVIEW .......................................................................................................13
4.3 DESIGN DESCRIPTION ................................................................................................................13
4.3.1 Module 1...............................................................................................................................13
4.3.2 Module 2...............................................................................................................................14
4.3.3 Module 3...............................................................................................................................14
5 IMPLEMENTATION.....................................................................................................................15
5.1 DEVELOPMENT STAGES .............................................................................................................15
5.1.1 Microcontroller GSM interfacing.........................................................................................15
5.1.2 IO interfacing with controller...............................................................................................15
5.1.3 Enabling smarter control......................................................................................................16
5.1.4 System Integration................................................................................................................16
5.2 USER INTERFACE .......................................................................................................................17
6 EVALUATION................................................................................................................................18
6.1 UNIT TESTING............................................................................................................................18
6.2 FUNCTION TESTING ...................................................................................................................18
7 CONCLUSIONS & FUTURE WORK ..........................................................................................19
REFERENCES.........................................................................................................................................20
APPENDIX B: HARDWARE SCHEMATICS .....................................................................................21
APPENDIX C: LIST OF COMPONENTS............................................................................................22

vi
Table of Figures
FIGURE 2-1 INSTALLING THE GSM MODEM...................................................................................................4
FIGURE 2-2 RESPONSE OF GSM MODEM ON AT COMMAND..........................................................................5
FIGURE 2-3 RESPONSE OF MODEM ON AT + CMGS ......................................................................................6
FIGURE 2-4 RESPONSE OF MODEM ON AT + CMGL .....................................................................................7
FIGURE 2-5 MAX INTERFACE ........................................................................................................................8
FIGURE 2-6 OUTPUT DRIVE CIRCUITRY .........................................................................................................9
FIGURE 4-1 EXAMPLE FIGURE FOR PROTOTYPE APPLICATION ....................................................................12
FIGURE 4-2 ARCHITECTURE OVERVIEW DIAGRAM .....................................................................................13

1
1 Introduction
The main goal of the project is to provide a technically and financially feasible solution for
controlling electric/electronic appliances remotely. Remote control has always been a field of
interest, however possesses few limitations. Most common method of controlling devices
remotely is the usage of Radio Frequency which works by modulating message signal and
transmitting it to the remote location where a receiver‟s circuitry performs an intended task.
This type of receiver requires high power transmissions to control very distant devices.
However, this project makes use of the reliable RF communication (SMS), instead of
developing a new system possessing a shorter range and higher susceptibility to noise.
The project includes development of hardware which includes the interface of microcontroller
with the GSM (Global System for Mobiles) equipment and few electric appliances. This
hardware is a standalone system and requires only reception of SMS to start its work.
Responding to any received SMS would definitely be a bad idea, therefore this project
implements software techniques (through microcontroller programming) that require the user to
send message in a specific format and also a password is needed to proceed. This system is also
capable of being used as a security system that can intimate the valid user (operator) about any
security breach e.g. intrusion of a person through a door or window at the remote station (far
from operator) will be quickly communicated to the operator through SMS.
The project includes development of software to achieve a successful interface between the
microcontroller and the GSM-equipment. The microcontroller has been programmed using C
language which ultimately has resulted in efficiently achieving objectives set by the project. The
software issues and techniques will be discussed in the following chapters.
Chapter 2 covers the background material and literature reviewed to understand the intricacies
of SMS, usage of GSM equipment and interfacing of microcontroller to various devices.
Chapter 0 then specifies the lists of extracted requirements for the project development. These
requirements are categorized into several groups on the basis of their functionality.
Requirements are also prioritized to explain their importance and enable the user to sift them
according to his needs.

2
Chapter 4 describes the design formulated for the successful execution of the suggested
techniques. The design explains the architecture of the device control system. In the end, this
chapter gives detailed information for each block, explaining their critical methods and
properties required for successful execution.
Chapter 5 explains the approach taken and issues confronted while implementing the intended
goals. It explains the temporal stages experienced while implementing the design, and also the
key functions that needs special consideration from the viewpoint of implementation. In the end,
the author has explained the user-interface of the implemented program, and the details of each
command how it is handled and used.
The testing and evaluation of the developed hardware and software is discussed in Chapter 6. It
explains the testing procedure followed and then the various types of tests executed on the
application to confirm its proper functioning and meeting the acceptance criteria. The results of
these tests are summarized in the end, with possible results concluded from these tests.
In the end, we briefly present the conclusions from this project and also the possible future
improvements and additions for better design/implementation and investigation of DEVICE
CONTROL USING SMS.

3
2 Literature Review
The objectives of the project indicate that the intricacies of the GSM modem should be known
and therefore, this chapter provides required details about the working of the GSM modem.
Also, this chapter focuses on the interfacing of microcontroller with GSM phone and electric
appliances. Unnecessary details have been avoided to keep the document readable and
understandable.
2.1 The GSM modem
GSM (Global System for Mobile Communications, originally Groupe Spécial Mobile), is a
standard set developed by the European Telecommunications Standards Institute (ETSI) to
describe technologies for second generation (or "2G") digital cellular networks. Developed as a
replacement for first generation analog cellular networks, the GSM standard originally
described a digital, circuit switched network optimized for full duplex voice telephony [1]
. GSM
modems are standard devices that operate within the GSM network. To simplify the concept it
is stated that the GSM modem is like a mobile phone which indeed it is, because the core of a
mobile phone is a GSM modem interfaced with some processor circuitry and few input output
devices like keypad, LCD etc. When we make a call using a mobile phone we actually punch in
a number which is sent to the GSM modem as an argument to one of its commands. So, in the
end the process is to feed a command to the GSM modem. The commands on which the GSM
phones/modems work are called AT commands or Hayes command set.
Most modems require a data suite or some other software to be installed in the computer before
you can connect them to PC. Once the right software is installed you can connect your modem
to the computer with any supported method. For example, few modems allow connection with
the PC using a Bluetooth, infrared and serial port or at least any one of them. Connection
through serial port is an easy method, provided by most of the sonyericsson phones.
2.2 AT commands
The Hayes command set is a specific command-language originally developed for the Hayes
Smartmodem 300 baud modem in 1977. The command set consists of a series of short text
strings which combine together to produce complete commands for operations such as dialing,
hanging up, and changing the parameters of the connection [2]
. So, if you have a GSM phone all

4
you need is to feed it the right AT command. This is virtually true; you can check it by
connecting your GSM modem to a computer and type in a command to check its working.
To explain working of AT commands with the GSM phones, here are few AT commands tested
on a GSM phone connected to the PC using its serial port. After installing modem drivers (some
phones and modems may not require it), you need to open HyperTerminal, which is a software
provided within the windows used for serial communication between the PC and any other
device. Since, the modem we used connected through the serial port of computer we selected
COM1 in the „connect using‟ dialog box of Hyper Terminal. A baud rate is required to be set
before communication can happen; most modems support a 9600 baud rate as was the case with
ours. Once the GSM phone is connected type in the proper AT commands.
Figure 2-1 installing the GSM modem
(http://wiki.forum.nokia.com/index.php/AT_Commands)
2.2.1 AT
AT is often abbreviated as “Attention Telephone” or “Attention Terminal” and is the most basic
command. If this command returns OK this means that the phone is capable of and is ready
using AT commands. Most other commands are extended versions of this AT command. You
can type AT* to list all the commands available for use with your specific modem.

5
Figure 2-2 Response of GSM phone on AT command
2.2.2 AT + CMGF=1
This command is used to set the text mode of the phone. A GSM phone can operate in either of
the two modes; one is the text mode which enables sending message as characters of 7 or 8-bits,
while the second is known as PDU mode which is used when binary data is to be transmitted as
message contents. Text mode is relatively simpler to handle. A phone may support only PDU
mode which can be tested by typing the command AT+CMGF=?
2.2.3 AT+CMGS
This command sends message to the Subscriber Identification Module (SIM) number specified
in its argument along with the message typed in. To send message text mode of the phone
should be set. The format of the command is as follows:
AT+CMGS=”03xx-xxxxxxx”,
Message body
Ctrl+z

6
Figure 2-3 Response of GSM phone on AT+CMGS command
2.2.4 AT+CPMS
The AT command +CPMS (command name in text: Preferred Message Storage) serves several
purposes. It can be used to:
1. Select the message storage area that will be used when sending, receiving, reading, writing or
deleting SMS messages.
2. Find the number of messages that are currently stored in the message storage area.
3. Find the maximum number of messages that can be stored in the message storage area [3]
.
2.2.5 AT+CMGL
The AT command +CMGL (command name in text: List Messages) is used to list messages of a
certain status (for example, "received unread" and "received read") from a message storage area.

7
In SMS text mode, you can retrieve the following information about an SMS message with the
AT command +CMGL:
The index specifying the location of the SMS message in the message storage area.
Status of the SMS message ("received unread", "received read", "stored unsent", "stored
sent", etc).
Originator/recipient phone number stored in the SMS message header and the type of
the phone number.
Text associated to the originator/recipient phone number in the phonebook.
Time and date at which the SMS message arrived at the SMSC (available to incoming
SMS messages only).
Body of the SMS message and its length [4]
.
Figure 2-4 Response of GSM phone on AT+CMGL command
2.3 Microcontroller Serial Interface
One of the 8051s many powerful features is its integrated UART, otherwise known as a serial
port. The fact that the 8051 has an integrated serial port means that you may very easily read
and write values to the serial port. If it were not for the integrated serial port, writing a byte to a

8
serial line would be a rather tedious process requiring turning on and off one of the I/O lines in
rapid succession to properly "clock out" each individual bit, including start bits, stop bits, and
parity bits [5]
.
So, to simplify all the DLD we have used a microcontroller instead that has a built-in UART
(Universal Asynchronous Receiver and Transmitter). All it requires is programming that sets the
baud rate for communication. One important hardware issue is that most microcontrollers are
TTL/CMOS logic and are not compatible with modern computers; therefore a logic translation
is required to perform a successful communication. One such translator is MAX232.
The MAX232 is an integrated circuit that converts signals from an RS-232 serial port to signals
suitable for use in TTL compatible digital logic circuits. The MAX232 is a dual driver/receiver
and typically converts the RX, TX, CTS and RTS signals [6]
.
Figure 2-5 Max interface
2.4 Interfacing devices to microcontroller
It is matter to ponder that the drive current required to switch ON an electric appliance is large
enough for a microcontroller to provide. Microcontroller operates on +5V supply with a
maximum current output of few 100mA whereas electric appliances require much larger power
then this. When control of high power devices is required a relay can be used with a separate

9
supply whose purpose is to connect the high power appliance to appropriate supply when its
terminals are excited (powered by a DC source). To preserve the dependence of the appliance
on an input signal from microcontroller, we connect the relay to the controller using a transistor.
When logic 1 appears at the microcontroller‟s pin it turns ON the transistor attached to it which
excites the relay terminals resulting in switching of device. A protective diode is also required
to limit the current passing the transistor when the relay gets OFF. This is because relay is one
of the inductive devices that posses the property that they oppose a change in their field by
inducing an opposite polarity current. This current appears as a high voltage spike that can
easily damage the transistor, so a reverse biased diode is connected in parallel to the relay to
save the transistor.
Figure 2-6 Interface circuitry for microcontroller
(http://www.scribd.com/doc/4287031/Interfacing-With-Microcontrollers)

10
3 Requirements Specification
3.1 Non-functional Requirements
3.1.1 Product requirements
ID Priority Details
NR-01-001 1 Platform:
NR-01-002 1 Language: C++
NR-01-003 1 Compiler: C compiler
NR-01-004 1 Usability:
NR-01-005 2 Portability: The final product is a standalone portable system
NR-01-006 2 Space: No strict space requirements are imposed
NR-01-007 1 Machine: No strict machine requirements are imposed.
3.1.2 Organisational requirements
ID Priority Details
NR-02-001 1 Delivery: The system development process and deliverable documents
shall conform to the process and deliverables defined in the document
“CIIT-CE-02H Degree Project Student‟s Handbook”.
NR-02-002 1 Standard: The standard of the final product shall be of undergraduate
level or above.
3.1.3 External requirements
ID Priority Details
NR-03-001 3 Security: This is a degree project having no strict security
requirements.
NR-03-002 1 Ethical: The application will not use any type of un-ethical electronic
material while project development and execution.
NR-03-003 1 Legislative: The application shall not use any private or confidential
data, or network information that may infringe copyrights and/or
confidentiality of any personnel not directly involved in this product.
NR-03-004 3 Safety: The implementation and operation of product should be safe.

11
3.2 Functional Requirements
3.2.1 Category 1
The application is intended to achieve following objectives which are categorized as
performance objectives.
ID Priority Details
FR-01-001 1 Switching on/off electric appliances through SMS commands.
FR-01-002 1 Reporting device status back to the operator.
FR-01-003 1 Implementing a SMS based security system.
FR-01-004 1 Allowing a password protected operation.
FR-01-005 2 Controlling a DC motor and/or 7-segment display by SMS commands.

12
4 Project Design
4.1 Methodology
To achieve the above stated objectives we need to devise a suitable methodology. The very first
step was the interface of the microcontroller with the serial port of computer. Since AT
commands are serially fed to the GSM modem, we need to understand the intricacies of a serial
interface. The idea behind this was to replace the computer (that communicates serially with the
GSM modem) with a microcontroller to allow an independent standalone operation. So, it was
necessary to ensure that the microcontroller can communicate serially to any device; therefore
as a prototype we wrote C code that was able to communicate a text message to PC.
Figure 4-1 Example Figure for Prototype Application
The prototype was helpful in enabling a serial communication between controller and GSM
modem. All it needs is to feed the appropriate AT command to the GSM phone serially and it
will perform its task. Software techniques have been adopted to invoke the right AT command
at the right time. Receiving serial data from GSM modem was also important, as GSM modem
responds to each AT command by some string e.g. OK. This was necessary to get informed
whether the specific AT command has done its job successfully or not.

13
4.2 Architecture Overview
The design of the intended product is explained graphically with the help of a diagram shown in
Figure 4-2. The diagram explains the overall interactions of the modules and their placements.
Figure 4-2 Architecture Overview Diagram
4.3 Design Description
Following are the modules constituting the product to be developed. Please note that we are
documenting only the salient properties and methods of each module to keep the description
simple and more readable.
4.3.1 Module 1: Serial Interface
Description: This module circles the hardware and software serial procedures.
Command selection routines
User authentication routines
Serial Interface Circuitry
GSM modem

14
Details:
Hardware and software solutions for connecting a microcontroller to any device
serially are defined by this module. It interacts with the command selection
routines to take input command from it and forward it to the GSM modem.
Also, it has a relation with the user authentication routine that identifies the
password embedded in the message.
4.3.2 Module 2: User Authentication routines
Description: This includes software solutions to identify password in the received message.
Details:
The purpose of this module is to authenticate that the received message is sent
by a valid user or not. If the user is valid it performs further actions as
instructed in the message. For example: sending a status message is required
then it will forward the request to the command selection module.
4.3.3 Module 3: Command Selection routines
Description: This module defines the input for the serial interface.
Details:
Commands to be sent serially to the GSM modem are selected by this module.

15
5 Implementation
We have implemented the suggested design by dividing the development process in different
stages. These stages have proven to be helpful in achieving objectives in a systematic and
smooth way.
5.1 Development Stages
Following were the discrete phases we have experienced incrementally to realize our product in
the given time:
5.1.1 Microcontroller-GSM interfacing
We started the project by creating an interface between the microcontroller and the GSM
modem. Since, it was the basic step of implementation; therefore it was placed first.
Microcontrollers have a serial port (UART) that enables them to communicate to any device
serially. Most GSM modems communicate with the computers through serial port. Since the
very basic objective of the project was to read SMS, this required an interface between the
microcontroller and GSM modem. C code was written that made the controller able to feed
proper AT command to the GSM phone serially. As stated earlier, reception of a new message
is indicated by the mobile through AT+CMGL command; we communicated this command to
the GSM phone and read its response. Further, processing was based on this response i.e. the
controller reads the new message and concludes which interfaced device the user wants to
switch.
5.1.2 IO interfacing with microcontroller
The next step followed was to interface a microcontroller with both input and output devices.
As stated earlier, one objective of the project was to read a sensor change on its port which
might be a sensor placed near a door to intimate a passage through it. This objective needs the
interface of a transistor switch with the microcontroller; the controller continuously polls for a
change in the sensor status, soon it happens it communicates appropriate AT command to the
GSM modem. Moreover, electric appliances were required to be connected as output devices
which may require to be switched. Microcontrollers provide small amount of current which is
too less to drive an electric appliances; therefore following the standard procedure electric
appliances were interfaced with the controller using a relay circuit. A relay is an inductive
switching device; soon it is energized by a few DC volts it mechanically switches the contact

16
points enabling a device to get on/off. Using a transistor is a good idea to drive the relay through
microcontroller‟s port. After completion of this stage all the operator needs is to write an SMS
in proper format which follows as:
Received Message System Response
[blank message] This sends a message to the operator reporting
the status of interfaced devices.
[Device number]-[new state] e.g. 2-1 This assigns the new state (on/off) to the
device attached to a specific port of controller.
E.g. it will on the device 2 attached to say P2.6
5.1.3 Enabling smarter control
Once microcontroller was able to switch devices as instructed in the message received through
the GSM phone serially interfaced to it; it was time to introduce some techniques that make the
system more reliable. It is well known that the SIM inserted in the GSM phone can receive an
SMS anytime and from any other SIM. So, it is believably possible that a blank message is
received by the system from an invalid user. Therefore, it was time to secure the control
mechanism. The third stage of implementation referred to this security by introducing software
technique that requires a password before proceeding to device control. So, the new SMS
format is shown below in the table.
Received Message System Response
Pw***** This reports the status of interfaced devices,
provided the password matches with the one
saved in the controller.
Pw*****[Device number]-[new state] e.g. 2-1 This assigns the new state (on/off) to the
device attached to a specific port of controller
but only if the password is correct.
5.1.4 System Integration
After the completion of all stages each and every separate module was integrated into a single
system. The final system was a standalone hardware that included microcontroller interfaced to
a GSM phone and IO devices and ready to receive instructions to work accordingly.

17
5.2 User Interface
User Interface is an extremely important consideration for any project that requires human-
machine interaction. However, the machine does not offer a direct human machine interface.
The only input it requires from user is an SMS which is definitely sent from a distant area. So,
there is no direct interface of this product with the user.

18
6 Evaluation
We have focussed on thorough testing through-out the design and implementation phase. As
stated earlier an incremental approach was adopted for implementation of this project. Hardware
and software techniques were adopted to possess at least the minimum required capability and
were tested for their correct operation.
6.1 Unit Testing
Each module in the application was tested while being developed to confirm its adherence to the
related requirements. To list a few, microcontroller-serial interface was first tested with the PC
to ensure proper baud rate setting and operation instead of interfacing it directly to the GSM
phone. Similarly, IO interfacing with the controller has been separately tested to avoid any
failure in the control circuitry. Software techniques were tested by implementing a circuit
simulator that providing the system with the proper input. Following figure shows an
intermediate step of software testing.
6.2 Function Testing
After integrating the system, emphasis was laid on the testing of the final product. All possible
inputs were provided to the system and its response was observed. For example, the final
hardware was provided with different SMS to confirm its fool proof operation. Blank message
was fed to the system to which it remained indifferent as required. Message containing proper
control format but incorrect password was sent to the GSM modem, but the system didn‟t
switch any devices which indicated successful operation of system.

19
7 Conclusions & Future Work
In this project we have developed a less costly and reliable method of controlling devices from a
remote location. We have concluded that microcontroller-GSM interface can be helpful in the
implementation of a robust control mechanism without any chance of incorrect operation.
However, it has been observed that a real time control of devices is not possible as messaging
service consumes considerable time in transmitting message which is a considerable issue in
real time control.

20
References
[1] http://en.wikipedia.org/wiki/GSM.
[2] http://en.wikipedia.org/wiki/Hayes_command_set
[3] http://www.developershome.com/sms/cpmsCommand.asp
[4] http://www.developershome.com/sms/cmglCommand.asp
[5] http://www.8052.com/tutser.phtml
[6] http://en.wikipedia.org/wiki/MAX232

21
Appendix B: Hardware Schematics

22
Appendix C: List of Components
Microcontroller ATMEL AT89C52
Max232
BD135 NPN Transistors
6V Relay
DB-9 Male / Female connector
7-Segment Display – Common anode
AN7805 Voltage Regulator
220V-12V step down Transformer
Crystal Oscillator 24MHz
Capacitors 10uF
Diodes 1N4001

Device Control via SMS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Device Control via SMS

Similar to Device Control via SMS (20)

Device Control via SMS