VIGNAN’S UNIVERSITY

VADLAMUDI

A PROJECT REPORT ON

N Submitted in partial fulfillment of the MINI-PROJECT in this

semester in CIVIL Engineering
By
Team Name: 7

S.SAI SUBHASH 131FA03069

S.GOPALA KRISHNA 131FA03074
S.L.BHARGAVI 131FA03067
P.SAMBA SIVA 131FA03061
N.KARTHIK 131FA03059

Under the Guidance of

PROFESSOR
SATISH

6TH Semester B.E, CIVIL Academic Year: 2015 – 2016

Department Of CIVIL Engineering,

 Department of Computer Science Engineering
S.D.M. College of Engineering & Technology
DHARWAD-580 002

CERTIFICATE

Certified that the project work entitled “ GSM BASED E-NOTICE BOARD “
is an original work carried out by Venkatesh Agnihotri, Arjun M Nayak and Aditya
Bharadwaj in partial fulfillment for the award of degree of Bachelor of Engineering in
Computer Science and Engineering of SDM College Of Engineering and
Technology , under the Visvesvaraya Technological University ,Belgaum during
the year 2012 to 2013 .The Project report has been approved as it satisfies the
academic requirements in respect of Project work prescribed for the Bachelor of
Engineering Degree.

Signature of Guide Signature of HOD Signature of Principal

Name and Signature of the examiners with date:

1. Name: Signature: Date:

2. Name: Signature: Date:
 Acknowledgement

We place on record and warmly acknowledge the continuous encouragement,

invaluable supervision, timely suggestions and inspired guidance offered by our guide
Prof. Nita K, professor, Department of Computer science engineering, at S.D.M.
College of engineering and technology, Dharwad in bringing this report to a successful
completion.

We are grateful to Prof. Jayatheerth Vadavi, Head of the Department of

Computer science engineering for permitting us to make use of the facilities available in
the department to carry out the project successfully. Last but not the least we express
our sincere thanks to all of our friends and our parents who have patiently extended all
sorts of help for accomplishing this undertaking.

Venkatesh Agnihotri (2sd10cs006)

Arjun M Nayak (2sd10cs130)

Aditya Bharadwaj (2sd10cs004)

 Abstract

In the last couple of decades, communication technology has developed by leaps

and bounds. It has already established its importance in sharing the information right
from household matters to worldwide phenomena. Apart from sharing information, it is
also used for remote control of machines and electronic appliances. In our day-to-day
life, we use many such appliances at home, office and public places for our comfort and
convenience. Every device requires one or the other kind of operation control for
which it has a HMI (human-machine interface).

Communication technology not only helps us to exchange information with

human beings but also allows us to carry out monitoring and controlling of
machines from remote locations. This remote control of appliances is possible
with wired or wireless communication interfaces embedded in the machines. The use
of “Embedded System in Communication” has given rise to many interesting
applications. One of such applications is public addressing system (PAS). Many
companies are manufacturing audio / video systems like public announcement system,
CCTV, programmable sign boards etc. But all these systems are generally hard-wired,
complex in nature and difficult to expand. So, by adding wireless communication
interface such as GSM to these systems, we can overcome their limitations.
 Table of Contents

Chapter 1 : INTRODUCTION .....................................................................................................1

1.1. Project overview............................................................................................................................. 2
1.2. Informaton transfer....................................................................................................................... 2
1.2.1.Broadcast ................................................................................................................................ 2
1.3. Components overview ................................................................................................................... 3
1.4. System operaton ........................................................................................................................... 5
Chapter 2 : LITERATURE SURVEY ..........................................................................................6
2.1. GSM based display toolkit .............................................................................................................. 7
2.2. GSM based data acquisition system ............................................................................................... 7
2.3. Development of sms based teaching and learning system ............................................................ 8
2.4. Design and development of GSM based energy meter.................................................................. 8
2.5. GSM based automatc meter reading system using ARM .............................................................. 8
2.6. Multple unit GSM controlled devices ........................................................................................... 9
Chapter 3 : PROBLEM DEFINITION .......................................................................................10
Chapter 4 : SYSTEM REQUIREMENT SPECIFICATION ........................................................13
4.1. Hardware requirements .............................................................................................................. 14
4.1.1.GSM modem ......................................................................................................................... 14
4.1.2.LCD display ........................................................................................................................... 15
4.1.3.Microcontroller AT89S52 ...................................................................................................... 19
4.1.4.MAX 232................................................................................................................................ 21
4.2. Sofware requirements ................................................................................................................ 23
4.2.1.Embedded C.......................................................................................................................... 23
4.2.2.Keil software ........................................................................................................................ 25
4.2.3.AT commands ....................................................................................................................... 27
Chapter 5 : SYSTEM MODELLING AND DESIGN ..................................................................35
5.1. The Engineering model ................................................................................................................ 36
5.2. System Model............................................................................................................................... 36
5.2.1.Use case diagram .................................................................................................................. 36
5.2.2.Functonal decompositon .................................................................................................... 38
5.2.3.Data flow diagram ................................................................................................................ 39
 5.2.4.State Transition diagram....................................................................................................... 41
5.2.5.Architecture of the system ................................................................................................... 42
Chapter 6 : IMPLEMENTATION ..............................................................................................43
6.1. Microcontroller – Modem interfacing ........................................................................................ 44
6.1.1.DTE and DCE ......................................................................................................................... 44
6.1.2.RS 232 ................................................................................................................................... 44
6.1.2.1. RS 232 .................................................................................................................. 46
6.2. Microcontroller – LCD interfacing ................................................................................................ 48
6.3. Implementaton at insttute level................................................................................................. 49
6.3.1.Overview ............................................................................................................................... 49
6.3.2.Proposal ................................................................................................................................ 49
Chapter 7 : TESTING ...............................................................................................................50
7.1. Initalizaton .................................................................................................................................. 51
7.2. Serial transfer using T1 and R1 flags ............................................................................................ 51
7.3. Validity, check and display ........................................................................................................... 51
7.4. Results .......................................................................................................................................... 52
Chapter 8 : CONCLUSION ......................................................................................................58
8.1. Conclusion ................................................................................................................................... 59
8.2. Future improvements .................................................................................................................. 59
REFERENCES .........................................................................................................................61
 List of Tables

Table 4.1 : LCD pin symbol I/O description ...............................................................................17

Table 4.2 : LCD command set ..................................................................................................19
Table 4.3 : RS232 signal description ........................................................................................22
Table 4.4 : AT commands ........................................................................................................34
Table 6.1 : RS232 signals, functions DCE DTE ........................................................................46
 List of Figures

Fig 3.1 : Overview Of The System ............................................................................................11

Fig 3.2 : Block Diagram Of The System ...................................................................................12
Fig 4.1 : GSM Modem ...............................................................................................................15
Fig 4.2 : LCD Display ................................................................................................................16
Fig 4.3 : Microcontroller At89s52...............................................................................................20
Fig 4.4 : Max 232 ......................................................................................................................21
Fig 4.5 : Converting C Code To Hex .........................................................................................26
Fig 4.6 : At Commands Classification .......................................................................................28
Fig 5.1 : Use case diagram(contd…) .........................................................................................36
Fig 5.2 : Use case diagram ......................................................................................................37
Fig 5.3 : Functional decomposition diagram ..............................................................................38
Fig 5.4 : Flow chart(contd...)......................................................................................................39
Fig 5.5 : Flow chart ...................................................................................................................40
Fig 5.6 : State transition diagram ..............................................................................................41
Fig 5.7 : Architecture of the system ...........................................................................................42
Fig 6.1 : RS 232 ........................................................................................................................45
Fig 6.2 : Microcontroller - LCD interfacing .................................................................................48
Fig 7.1 : Initializing ...................................................................................................................52
Fig 7.2 : Typing the message in the mobile ..............................................................................52
Fig 7.3 : Enter The Valid Authenticated Phone Number ...........................................................53
Fig 7.4 : Send The Message ....................................................................................................53
Fig 7.5 : Message Is Displayed In The Notice Board ................................................................54
Fig 7.6 : Change The Message ................................................................................................54
Fig 7.7 : Send The New Message ............................................................................................55
Fig 7.8 : Message Sent ............................................................................................................55
Fig 7.9 : Message Displayed ....................................................................................................56
Fig 7.10 : To Clear Notice Board ..............................................................................................56
Fig 7.11 : Send SDMC# ............................................................................................................57
Fig 7.12 : Notice Board Cleared ...............................................................................................57
 Chapter – 1

INTRODUCTION
1.1. Introduction

Flyash is used as a supplementary cementitious material (SCM) in the

production of portland cement concrete. A supplementary cementitious material,
when used in conjunction with portland cement, contributes to the properties of the
hardened concrete through hydraulic or pozzolanic activity, or both. As such, SCM's
include both pozzolans and hydraulic materials
The potential for using fly ash as a supplementary cementitious material in
concrete has been known almost since the start of the last century (Anon
1914),although it wasn't until the mid-1900s that significant utilization of fly ash in
concrete began (for example, USBR 1948) following the pioneering research
conducted at the University of California, Berkeley (Davis 1937).The last 50 years
has seen the use of fly ash in concrete grow dramatically with close to 15 million
tons used in concrete, concrete products and grouts in the U.S.in 2005 (ACAA 2006).

Historically, fly ash has been used in concrete at levels ranging from 15%
to 25% by mass of the cementitious material component. The actual amount used
varies widely depending on the application, the properties of the fly ash specifi
cation limits, and the geographic location and climate. Higher levels (30% to 50%)
have been used in massive structures (for example, foundations and dams) to control
temperature rise. In recent decades, research has demonstrated that high dosage
levels (40% to 60%) can be used in structural applications, producing concrete
with good mechanical properties and durability (Marceau 2002

1.2 .Nature of fly ash

Fly ash is a by-product of burning pulverized coal in an electrical generating station.
Specifically, it is the unburned residue that is carried away from the burning zone in
the boiler by the flue gases and then collected by either mechanical or electrostatic
separators (Figure 2). The heavier unburned material drops to the bottom of the
furnace and is termed bottom ash; this material is not generally suitable for use as a
cementitious material for concrete, but is used in the manufacture of concrete
masonry block.

Figure 3. Micrograph showing spherical fly ash particles

The performance of fly ash in concrete is strongly influenced by itsphysical,
mineralogical and chemical properties. The mineralogical and chemical composition
are dependent to a large extent on the composition of the coal and since a wide range
of domestic andimported coals (anthracite, bituminous, sub-bituminous and lignite
The performance of fly ash in concrete is strongly influenced by itsphysical,
mineralogical and chemical properties. The mineralogical and chemical composition
are dependent to a large extent on the composition of the coal and since a wide range
of domestic andimported coals (anthracite, bituminous, sub-bituminous and lignite

1.4. effect of fly ash on properties

The operation of the system is very simple. Sending message from any of the
remote area to the distant located e-notice board using GSM mobile. For sending
the text message from remote area we need to interface the mobile phone with GSM
Modem. For developing some of GSM based applications we need to have some
commons peripherals including GSM MODEM, SIM, microcontroller, LCD (Liquid crystal
display), power supply and also some connecting wires. Moreover GSM based
applications could be easily developed and enhanced due to easily accessibility of
components in local markets at very pocket friendly prices.
 Chapter – 2

LITERATURE SURVEY
 The word GSM Refers to Global System for Mobile Communications. Nowadays
many people are showing lot of interest to know more about GSM related concepts. So,
here we have surveyed a list of various GSM based projects ideas which are having
more demand and very interesting to learn. The following projects based on GSM
technology we surveyed would give better idea about the GSM technology practically.

4.1. GSM BASED DISPLAY TOOLKIT

Presently, the wireless communication has announced its arrival on big stage
and the world is going mobile. We want to control everything and without moving an
inch. This remote of appliances is possible through Embedded Systems. The main aim
of this project will be to design a SMS driven automatic display toolkit which can replace
the currently used programmable electronic display. It is proposed to design receive
cum display toolkit which can be programmed from an authorized mobile phone. The
message to be displayed is sent through an SMS from an authorized transmitter. The
toolkit receives the SMS, Validates the sending Mobile Identification Number (MIN) and
displays the desired information after necessary code conversions.

4.2. GSM BASED DATA ACQUISITION SYSTEM

GSM based data acquisition is a process control system that enables a site
operator to monitor and control processes that are distributed among various remote
sites. This project is designed to monitor various parameters like humidity, rainfall, wind
direction, temperature, light intensity, etc. This system saves time and money by
eliminating the need for service personnel to visit each site for inspection and data
collection. They are used in all types of industries, from electrical distribution systems,
to food processing, to facility security alarms.
4.3. DEVELOPMENT OF SMS BASED TEACHING AND
LEARNING SYSTEM

The Short Message Service (SMS) technology is one the most stable mobile
technologies around. Most of our tertiary students carry mobile phones with SMS
facilities and can be used for teaching and learning. There are many projects using
SMS technologies in education as outlined in the literature survey, but many
publications do not provide the possible underlying technologies to implement such as
the teaching and learning systems. The system is capable of supporting administrative
teaching and learning activities via the SMS technology.

4.4. DESIGN AND DEVELOPMENT OF GSM BASED ENERY

METER

Traditional metering method for retrieving the energy data is not convenient and
the cost of the data logging systems is high. Automatic Meter Reading (AMR) system is
boom for remote monitoring and control domestic energy meter. AMR system gives the
information of meter reading, power cut, total load used, power disconnect and
tempering on request or regularly in particular interval through SMS. The information is
being sent and received by concerned energy Provider Company with the help of GSM
network. Energy provider receives the meter reading within a second without visiting
person AMR minimize the number of traditional visits required by employs of energy
Provider Company. This system not only reduces the labor cost but also increase meter
reading accuracy and save huge amount of time.

4.5. GSM BASED AUTOMATIC METER READING SYSTEM

USING ARM

Nowadays the automation in every field is becoming necessary. The service

provider for energy still uses conventional methods for getting the energy consumed
by
individual costumer. The proposed system automatically reads the energy consumed
and sends it to the service provider using the existing SMS.

4.6. MULTIPLE UNIT GSM CONTROLLED DEVICES

The human mind always needs information of interest to control systems of

his/her choice. In the age of electronic systems it is important to be able to control and
acquire information from everywhere. Remote management of several home and office
appliances is a subject of growing interest and in recent years we have seen many
systems providing such controls. In this study we have developed an interface which is
a phone based home/office remote controller equipped with power to turn ON/OFF and
receive STATUS of electrical appliances remotely located.
 Chapter – 3

PROBLEM DEFINITION
 As explained in the introduction chapter, the realization of complete potential of
the display boards and the wireless medium in information transfer is the major
issue that the following thesis of the following project deals with.

Fig 3.1 overview of system

As we see in the above figure, there are at least three interfacing circuits, MAX-
232 with Microcontroller, LCD display with microcontroller, and MAX-232 with GSM
MODEM. It is not a hidden fact that interfacing a MODEM with a normal PC is quite
easy with the help of the AT commands sent to it from the Hyper Terminal window. But
we must take into account the fact that the MODEM requires a wired connection at one
end and wireless at the other. Dedicating a general purpose computer at each and
every site of the display boards, although makes the task a lot easier but is too
expensive to be a possibility. Hence we employ Atmel 89S52 microcontroller with 64 Kb
EEROM storage memories.
 Fig 3.2 block diagram of the system
The complexity of coding substantially increases, but once programmed the
module works at its robust best since it is a dedicated embedded system and not a
general purpose computer. The design procedure involves identifying and assembling
all the required hardware and ensuring fail safe interfacing between all the components.
Then we have the coding process which has to take care of the delays between two
successive transmissions and most importantly the validation of the sender‟s number.
The number of valid mobile numbers can be more than one. The limiting constraint is
the RAM of the microcontroller rather than the coding-complexities.
 Chapter – 4

SYSTEM REQUIREMENT
SPECIFICATION
4.1. HARDWARE REQUIREMENTS
4.1.1. GSM MODEM
A GSM modem is a wireless modem that works with a GSM wireless network. A
wireless modem behaves like a dial-up modem. The main difference between them is
that a dial-up modem sends and receives data through a fixed telephone line while a
wireless modem sends and receives data through radio waves. Like a GSM mobile
phone, a GSM modem requires a SIM card from a wireless carrier in order to operate.

GSM sim 300 Modem can accept any GSM network operator SIM card and act
just like a mobile phone with its own unique phone number. Advantage of using this
modem will be that you can use its RS232 port to communicate and develop embedded
applications. Applications like SMS Control, data transfer, remote control and logging
can be developed easily. The modem can either be connected to PC serial port directly
or to any microcontroller. It can be used to send and receive SMS or make/receive
voice calls. It can also be used in GPRS mode to connect to internet and do many
applications for data logging and control. In GPRS mode you can also connect to any
remote FTP server and upload files for data logging. This GSM modem is a highly
flexible plug and play quad band GSM modem for direct and easy integration to RS232
applications. Supports features like Voice, SMS, Data/Fax, GPRS and integrated
TCP/IP stack.

Computers use AT commands to control modems. Both GSM modems and dial-
up modems support a common set of standard AT commands. GSM modem can be
used just like a dial-up modem. In addition to the standard AT commands, GSM
modems support an extended set of AT commands. These extended AT commands
are defined in the GSM standards. With the extended AT commands, various things
can be done:
 Sending SMS messages.
 Monitoring the signal strength.
 Monitoring the charging status and charge level of the battery.
 Reading, writing and searching phone book entries.
  Reading, writing and deleting SMS messages.

The number of SMS messages that can be processed by a GSM modem per
minute is very low -- only about six to ten SMS messages per minute.
 Fig 4.1 GSM modem
4.1.2. LCD display
One of the most common devices attached to an 8051 is an LCD display. Some
of the most common LCDs connected to the 8051 are 16x2 and 20x2 displays. This
means 16 characters per line by 2 lines and 20 characters per line by 2 lines,
respectively. In recent years the LCD is finding widespread use replacing LED‟s.
This is due to the following reasons:
1. Declining prices
2. Ability to display numbers, characters and graphics.
3. Incorporation of a refreshing controller into the LCD.
4. Ease of programming.

Fig 4.2 LCD display

Fortunately, a very popular standard exists which allows us to communicate with the
vast majority of LCDs regardless of their manufacturer. The standard is referred to as
HD44780U, which refers to the controller chip which receives data from an external
source (in this case, the 8051) and communicates directly with the LCD. The 44780
standard requires 3 control lines as well as either 4 or 8 I/O lines for the data bus. The
user may select whether the LCD is to operate with a 4-bit data bus or an 8-bit data
bus. If a 4-bit data bus is used the LCD will require a total of 7 data lines (3 control lines
plus the 4 lines for the data bus). If an 8-bit data bus is used the LCD will require a total
of 11 data lines (3 control lines plus the 8 lines for the data bus).
Pin Symbol I/O Description

Table 4.1 LCD pin symbol I/O description

Important Signals
The following pins are important to LCD‟s while programming

Enable (EN)
The EN line is called "Enable." This control line is used to tell the LCD that you are
sending it data. To send data to the LCD, your program should make sure this line is
low (0) and then set the other two control lines and/or put data on the data bus. When
the other lines are completely ready, bring EN high (1) and wait for the minimum
amount of time required by the LCD datasheet (this varies from LCD to LCD), and
end by bringing it low (0) again.
Register Select (RS)
The RS line is the "Register Select" line. When RS is low (0), the data is to be treated
as a command or special instruction (such as clear screen, position cursor, etc.). When
RS is high (1), the data being sent is text data which should be displayed on the screen.
For example, to display the letter "T" on the screen you would set RS high.

Read/Write (R/W)
The RW line is the "Read/Write" control line. When RW is low (0), the information on
the data bus is being written to the LCD. When RW is high (1), the program is
effectively querying (or reading) the LCD. Only one instruction ("Get LCD status") is a
read command. All others are write commands--so RW will almost always be low.
Finally, the data bus consists of 4 or 8 lines (depending on the mode of operation
selected by the user). In the case of an 8-bit data bus, the lines are referred to as DB0,
DB1, DB2, DB3, DB4, DB5, DB6, and DB7.

Above is the quite simple schematic. The LCD panel's Enable and Register Select is
connected to the Control Port. The Control Port is an open collector / open drain output.
While most Parallel Ports have internal pull-up resistors, there is a few which don't.
Therefore by incorporating the two 10K external pull up resistors, the circuit is more
18 portable for a wider range of computers, some of which may have no internal pull
up resistors.

We make no effort to place the Data bus into reverse direction. Therefore we hard wire
the R/W line of the LCD panel, into write mode. This will cause no bus conflicts on the
data lines. As a result we cannot read back the LCD's internal Busy Flag which tells us if
the LCD has accepted and finished processing the last instruction. This problem is
Overcome by inserting known delays into our program.

The 10k Potentiometer controls the contrast of the LCD panel. Nothing fancy here. As
with all the examples, I've left the power supply out. You can use a bench power
supply
set to 5v or use a onboard +5 regulator. Remember a few de-coupling capacitors,
especially if you have trouble with the circuit working properly.

Table 4.2 LCD command set

4.1.3. Microcontroller AT89S52

Features:
 Compatible with MCS-51® Products
 8K Bytes of In-System Programmable (ISP) Flash Memory
 Endurance: 1000 Write/Erase Cycles
 4.0V to 5.5V Operating Range
 Fully Static Operation: 0 Hz to 33 MHz
 Three-level Program Memory Lock
 256 x 8-bit Internal RAM
 32 Programmable I/O Lines
 Three 16-bit Timer/Counters
 Eight Interrupt Sources
 Full Duplex UART Serial Channel
 Low-power Idle and Power-down Modes
 Interrupt Recovery from Power-down Mode
 Watchdog Timer
 Dual Data Pointer
 Power-off Flag
 Fig 4.3 Microcontroller AT89S52
Description:
The AT89S52 is a low-power, high-performance CMOS 8-bit microcontroller with
8K bytes of in-system programmable Flash memory. The device is manufactured using
Atmel‟s high-density nonvolatile memory technology and is compatible with the
industry standard 8051 instruction set and pin out. The on-chip Flash allows the
program memory to be reprogrammed in-system or by a conventional nonvolatile
memory programmer. By combining a versatile 8-bit CPU with in-system programmable
flash on a monolithic chip, the Atmel AT89S52 is a powerful microcontroller which
provides a
Highly-flexible and cost-effective solution to many embedded control applications.
The
AT89S52 provides the following standard features: 8K bytes of flash, 256 bytes of RAM,
32 I/O lines, Watchdog timer, two data pointers, three 16-bit timer/counters, six-vector
two-level interrupt architecture, a full duplex serial port, on-chip oscillator, and clock
circuitry. In addition, the AT89S52 is designed with static logic for operation down
to zero frequency and supports two software selectable power saving modes. The Idle
Mode stops the CPU while allowing the RAM, timer/counters, serial port, and interrupt
system to continue functioning. The Power-down mode saves the RAM contents but
freezes the oscillator, disabling all other chip functions until the next interrupt or
hardware reset.

4.1.4. MAX 232

The MAX232 is an IC 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. The drivers
provide RS-232 voltage level outputs (approx. ± 7.5 V) from a single + 5 V supply via
on-chip charge pumps and external capacitors. This makes it useful for implementing
RS-232 in devices that otherwise do not need any voltages outside the 0 V to + 5 V
range, as power supply design does not need to be made more complicated just for
driving the RS-232 in this case.

Fig 4.4 MAX232

 The receivers reduce RS-232 inputs (which may be as high as ± 25 V), to
standard 5 V TTL levels. These receivers have a typical threshold of 1.3 V, and
a typical hysteresis of 0.5 V. It is helpful to understand what occurs to the voltage
levels. When a MAX232 IC receives a TTL level to convert, it changes TTL logic 0 to
between
+3 and +15 V, and changes TTL logic 1 to between -3 to -15 V, and vice versa for
converting from RS232 to TTL. This can be confusing when you realize that the RS232
data transmission voltages at a certain logic state are opposite from the RS232 control
line voltages at the same logic state. The MAX232 (A) has two receivers (converts from
RS-232 to TTL voltage levels), and two drivers (converts from TTL logic to RS-232
voltage levels). This means only two of the RS-232 signals can be converted in each
direction. Typically, a pair of a driver/receiver of the MAX232 is used for TX and RX
signals, and the second one for CTS and RTS signals.

Table 4.3 RS232 signal description

There are not enough drivers/receivers in the MAX232 to also connect the DTR,
DSR, and DCD signals. Usually these signals can be omitted when e.g. communicating
with a PC's serial interface. If the DTE really requires these signals, either a second
MAX232 is needed, or some other IC from the MAX232 family can be used. Also, it is
possible to directly wire DTR (DB9 pin #4) to DSR (DB9 pin #6) without going through
any circuitry. This gives automatic (brain dead) DSR acknowledgment of an incoming
DTR signal.

4.2. SOFTWARE REQUIREMENTS

4.2.1. Embedded C
Embedded C is a set of language extensions for the C Programming language by
the C Standards committee to address commonality issues that exist between C
extensions for different embedded systems. Historically, embedded C programming
requires nonstandard extensions to the C language in order to support exotic features
such as fixed-point arithmetic, multiple distinct memory banks, and basic I/O operations.

Difference between C and Embedded C

Though C and embedded C appear different and are used in different

contexts, they have more similarities than the differences. Most of the constructs are
same; the difference lies in their applications.

 C is used for desktop computers, while embedded C is for microcontroller based

applications.
 C takes more resources of a desktop PC like memory, OS, etc. while programming
on desktop systems what embedded C cannot. Embedded C has to use the limited
resources (RAM, ROM, I/Os) on an embedded processor. Thus, program code must
fit into the available program memory. If code exceeds the limit, the system is
likely to crash.
 Compilers for C (ANSI C) typically generate OS dependent executable files.
Embedded C requires compilers to create files to be downloaded to the
microcontrollers/microprocessors where it needs to run. Embedded compilers give
access to all resources which is not provided in compilers for desktop computer
applications.
 Embedded systems often have the real-time constraints, which is usually not there
with desktop computer applications.
 Embedded systems often do not have a console, which is available in case of
desktop applications.

The C programming language is perhaps the most popular programming

language for programming embedded systems. C continues to be a very popular
language for micro-controller developers/programmers due to the code efficiency and
reduced overhead and development time. C offers low-level control and is considered
more readable than assembly language which is a little difficult to understand. Assembly
language requires more code writing, whereas C is easy to understand and requires
less coding. Plus, using C increases portability, since C code can be compiled for
different types of processors. We can program microcontrollers using 8051, AVR or
PIC.

We can develop our programs as per our electronic hardware using 8051 micro
controller. For example we can blink led, increment decrement counters, token displays
etc.

Most C programmers are spoiled because they program in environments where

not only there is a standard library implementation, but there are frequently a number of
other libraries available for use. The cold fact is, that in embedded systems, there rarely
are many of the libraries that programmers have grown used to, but occasionally an
embedded system might not have a complete standard library, if there is a standard
library at all. Few embedded systems have capability for dynamic linking, so if standard
library functions are to be available at all, they often need to be directly linked into the
executable. Oftentimes, because of space concerns, it is not possible to link in an entire
library file, and programmers are often forced to "brew their own" standard c library
implementations if they want to use them at all. While some libraries are bulky and not
well suited for use on microcontrollers, many development systems still include the
standard libraries which are the most common for C programmers.
 C remains a very popular language for micro-controller developers due to the
code efficiency and reduced overhead and development time. C offers low-level control
and is considered more readable than assembly. Many free C compilers are available
for a wide variety of development platforms. The compilers are part of an IDEs with ICD
support, breakpoints, single-stepping and an assembly window. The performance of C
compilers has improved considerably in recent years, and they are claimed to be more
or less as good as assembly, depending on who you ask. Most tools now offer options
for customizing the compiler optimization. Additionally, using C increases portability,
since C code can be compiled for different types of processors.

4.2.2. Keil software

Keil development tools for the 8051 Microcontroller Architecture support every
level of software developer from the professional applications engineer to the
student just learning about embedded software development.

The Keil 8051 Development Tools are designed to solve the complex problems facing
embedded software developers.
 When starting a new project, simply select the microcontroller you use from the
Device Database and the µVision IDE sets all compiler, assembler, linker, and
memory options for you.
 Numerous example programs are included to help you get started with the
most popular embedded 8051 devices.
 The Keil µVision Debugger accurately simulates on-chip peripherals (I²C, CAN,
UART, SPI, Interrupts, I/O Ports, A/D Converter, D/A Converter, and PWM Modules)
of your 8051 device. Simulation helps you understand hardware configurations and
avoids time wasted on setup problems. Additionally, with simulation, you can write
and test applications before target hardware is available.
 When you are ready to begin testing your software application with target
hardware, use the MON51, MON390, MONADI, or FlashMON51 Target Monitors,
the ISD51 In-
 System Debugger, or the ULINK USB-JTAG Adapter to download and test program
code on your target system.

The Atmel AT89S52 is an 8051 based Full Static CMOS controller with Three-
Level Program Memory Lock, 32 I/O lines, 3 Timers/Counters, 8 Interrupts Sources,
Watchdog Timer, 2 DPTRs, 8K Flash Memory, 256 Bytes On-chip RAM

If not simpler, the version of the C programming language used for the
microcontroller environment is not very different than standard C when working on
mathematical operations, or organizing your code. The main difference is all about the
limitations of the processor of the 89S52 microcontroller as compared to modern
computers.

Even if you’re not very familiar with the C language, this tutorial will introduce all
the basic programming techniques that will be used along this tutorial. It will also show
you how to use the KEIL IDE.

Fig 4.5 converting C code to HEX

From the C program to the machine language

The C source code is very high level language, meaning that it is far from
being at the base level of the machine language that can be executed by a processor.
This machine language is basically just zero‟s and one‟s and is written in
Hexadecimal format, that why they are called HEX files. There are several types of
HEX files; we are going to produce machine code in the INTEL HEX-80 format, since
this is the output of the KEIL IDE that we are going to use. Figure shows that to
convert a C program to machine language, it takes several steps depending on the
tool you are using, however, the main idea is to produce a HEX file at the end. This
HEX file will be then used by the
„burner‟ to write every byte of data at the appropriate place in the EEPROM of the
89S52.

4.2.3. AT commands
AT commands are used to control MODEMs. AT is the abbreviation for
Attention. These commands come from Hayes commands that were used by the
Hayes smart modems. The Hayes commands started with AT to indicate the attention
from the MODEM. The dial up and wireless MODEMs (devices that involve machine to
machine communication) need AT commands to interact with a computer. These
include the Hayes command set as a subset, along with other extended AT
commands.

AT commands with a GSM/GPRS MODEM or mobile phone can be used to access

following information and services:

1. Information and configuration pertaining to mobile device or MODEM and SIM card.
2. SMS services.
3. MMS services.
4. Fax services.
5. Data and Voice link over mobile network.
The Hayes subset commands are called the basic commands and the commands
specific to a GSM network are called extended AT commands.

Types of AT Commands:
There are four types of AT commands:

Fig 4.6 AT commands classification

Explanation of commonly used AT commands:

1) AT - This command is used to check communication between the module and

the computer.
For example, AT OK
The command returns a result code OK if the computer (serial port) and module are
connected properly. If any of module or SIM is not working, it would return a result code
ERROR.

2) +CMGF - This command are used to set the SMS mode. Either text or PDU mode
can be selected by assigning 1 or 0 in the command.

SYNTAX: AT+CMGF=<mode>
0: for PDU mode
1: for text mode

The text mode of SMS is easier to operate but it allows limited features of SMS.
The
PDU (protocol data unit) allows more access to SMS services but the operator requires
bit level knowledge of TPDUs. The headers and body of SMS are accessed in hex
format in PDU mode so it allows availing more features.
For example,
AT+CMGF=1
OK

3) +CMGW - This command is used to store message in the SIM.

SYNTAX: AT+CMGW=” Phone number”> Message to be stored

Ctrl+z

As one types AT+CMGW and phone number, „>‟ sign appears on next line where one
can type the message. Multiple line messages can be typed in this case. This is why the
message is terminated by providing a „Ctrl+z‟ combination. As Ctrl+z is pressed, the
following information response is displayed on the screen.
+CMGW: Number on which message has been stored

4) +CMGS - This command is used to send a SMS message to a phone number.

SYNTAX: AT+CMGS= serial number of message to be send.

As the command AT+CMGS and serial number of message are entered, SMS is sent to
the particular SIM.

For example,
AT+CMGS=1
OK

5) ATD - This command is used to dial or call a number.

SYNTAX: ATD<Phone number> (Enter)

For example,
ATD123456789

6) ATA - This command is used to answer a call. An incoming call is indicated by a

message „RING‟ which is repeated for every ring of the call. When the call ends
„NO CARRIER‟ is displayed on the screen.

SYNTAX: ATA (Enter)

As ATA followed by enter key is pressed, incoming call is answered.

For example,
RING
RING
ATA

7) ATH - This command is used to disconnect remote user link with the GSM

module. SYNTAX: ATH (Enter)

List of AT commands:

The AT commands for both, GSM module and the mobile phone, are listed below.
Some of these commands may not be supported by all the GSM modules available.
Also there might be some commands which won‟t be supported by some mobile
handsets.
Table 4.4 AT commands
 Chapter – 5

SYSTEM MODELLING AND

DESIGN
5.1. THE ENGINEERING MODEL

An embedded system is a combination of hardware and software and perhaps

other mechanical parts designed to perform a specific function. Theoretically an SMS
sent form a mobile phone to GSM modem is received by the GSM and stores it through
AT commands. Using microcontroller it is possible to retrieve the stored message in
GSM and display it on a LCD display using embedded programming languages. Short
information can be sent from a mobile phone as SMS and made display until the next
one.
5.2. SYSTEM MODELS

5.2.1. Use case diagram

Fig 5.1 use case diagram (contd...)

 Fig 5.2 use case diagram

The User interacts with the system by sending a message to the system for it to
display. Once the system receives the message it verifies the user identification (MIN)
with his number. If the validation proves to be authentic the message is stored and
proceeds to display the message. Denial of authentication (wrong MIN) results in
discarding the message. Admin is granted with the responsibility of addition to the
authenticated list, deletion of users from the list and also has the ability to change the
access code (MIN).
 5.2.2. Functional decomposition

Fig 5.3 functional decomposition diagram

The constituent parts involved in the process are

 Mobile phone
 GSM (global system for mobile)
 Microcontroller
 LCD display

First block portrays to be gsm which receives, verifies and forwards the message to the
Microcontroller. Micro is the second block. Micro processes the message and sends to
the LCD. LCD behaving as the third constituent part displays the message until it is
invoked by micro to display a new message.
5.2.3. Data flow diagram

Fig 5.4 flow chart (contd…)

 Fig 5.5 flow chart

The flow starts by initializing the ports of components. LCD is enabled and the
baud rate is set. The program module points out the AT commands that has to be
executed by the GSM. When micro reads these AT commands, it is sent to the GSM
module where the commands are processed. At this instance the messages are sent to
the micro so it can be displayed. The updating of messages is checked and if the
sender is valid the messages are stored. Any operation pertaining to the present result
is performed. Once the operations are performed the acknowledgement is sent. In the
worst case scenario if there are no new messages the loop of checking for new
messages continues until the new one arrives.
5.2.4. State transition diagram

Fig 5.6 state transition diagram

The state transition refers to all the finite states the system enters during the
process, pointing out the behavior of the system when the msg is received from
the end user. Just as soon as the msg is received from the user the message is
validated by comparing with the password characters. The message is stored
and sent to display. In the other scenario the invalid user msg is discarded by the
microcontroller and later keeps checking for any new recent messages.
 5.2.5. Architecture of the system

Fig 5.7 architecture of the system

Architecture of the system consists of Microcontroller which involves in the operation

and validation. Regulated supply is to power up the whole circuit components. GSM
modem stores any msg received by the user, any operation performed by the GSM is
due to the AT commands initiated by the microcontroller. Microcontroller forwards the
msg to the LCD. LCD receives the msg and can display only 16*2 characters at a time.
Mobile is the end user that starts the interaction with GSM by sending a message.
 Chapter – 6

IMPLEMENTATION
6.1. MICROCONTROLLER - MODEM INTERFACING
6.1.1. DTE and DCE

The terms DTE and DCE are very common in the data communications
market. DTE is short for Data Terminal Equipment and DCE stands for Data
Communications Equipment.
But what do they really mean?

As the full DTE name indicates this is a piece of device that ends a
communication line, whereas the DCE provides a path for communication.
Let's say we have a computer on which wants to communicate with the Internet
through a modem and a dial•]up connection. To get to the Internet you tell your
modem to dial the number of your provider. After your modems has dialed the
number, the modem of the provider will answer your call and your will hear a lot
of noise. Then it becomes quiet and you see your login prompt or your dialing
program tells you the connection is established. Now you have a connection with
the server from your provider and you can wander the Internet. In this example
you PC is a Data Terminal (DTE). The two modems (Yours and that one of your
provider) are DCEs, they make the communication between you and your
provider possible. But now we have to look at the server of your provider.
Is that a DTE or DCE? The answer is a DTE. It ends the communication line
between you and the server. When you want to go from your provided server to
another place it uses another interface. So DTE and DCE are interfacing
dependent. It is e.g. possible that for your connection to the server, the server is
a DTE, but that that same server is a DCE for the equipment that it is attached to
on the rest of the Net.

6.1.2. RS•232

In telecommunications, RS•232 is a standard for serial binary data

signals connecting between a DTE (Data terminal equipment) and a DCE (Data
Circuit•] terminating Equipment). It is commonly used in computer serial ports. In
RS•] 232, data is sent as a time] series of bits. Both synchronous and
asynchronous transmissions are supported by the standard. In addition to the
data circuits, the standard defines a number of controls circuits used to manage
the connection between the DTE and DCE. Each data or control circuit only
operates in one direction that is, signaling from a DTE to the attached DCE or the
reverse. Since transmit data and receive data are separate circuits, the interface
can operate in a full duplex manner, supporting concurrent data flow in both
directions. The standard does not define character framing within the data
stream, or character encoding.

Fig 6.1 RS232

 Table 6.1 RS232 signals, functions DTE DCE
6.1.2.1. RS‐232 Signals

 Transmitted Data (TxD)

Data sent from DTE to DCE.

 Received Data (RxD)

Data sent from DCE to DTE.
 Request To Send (RTS)
Asserted (set to 0) by DTE to prepare DCE to receive data. This may require
action
on the part of the DCE, e.g. transmitting a carrier or reversing the direction of a

half‐
duplex line.

 Clear To Send (CTS)

Asserted by DCE to acknowledge RTS and allow DTE to transmit.

 Data Terminal Ready (DTR)

Asserted by DTE to indicate that it is ready to be connected. If the DCE is a
modem, it should go "off hook" when it receives this signal. If this signal is
disserted, the modem should respond by immediately hanging up.

 Data Set Ready (DSR)

Asserted by DCE to indicate an active connection. If DCE is not a modem (e.g.
a
null‐modem cable or other equipment), this signal should be permanently

asserted
(set to 0), possibly by a jumper to another signal.

 Carrier Detect (CD)

Asserted by DCE when a connection has been established with remote
equipment.

 Ring Indicator (RI)

Asserted by DCE when it detects a ring signal from the telephone line.
 6.2. MICROCONTROLLER-LCD INTERFACING

Fig 6.2 Microcontroller – LCD interfacing

Above is the quite simple schematic. The LCD panel‟s Enable and Register
Select is connected to the Control Port. The Control Port is an open collector / open
drain output. While most Parallel Ports have internal pull‐up resistors, there is a few
which don‟t. Therefore by incorporating the two 10K external pull up resistors, the circuit
is more portable for a wider range of computers, some of which may have no
internal pull up resistors.

We make no effort to place the Data bus into reverse direction. Therefore we
hard wire the R/W line of the LCD panel, into write mode. This will cause no bus
conflicts on the data lines. As a result we cannot read back the LCD‟s internal Busy Flag
which tells us if the LCD has accepted and finished processing the last instruction. This
problem is overcome by inserting known delays into our program. The 10k
Potentiometer controls the contrast of the LCD panel. Nothing fancy here. As with all the
examples, I‟ve left the power supply out. You can use a bench power supply set to 5v
or use a onboard +5 regulator. The user may select whether the LCD is to operate
with a
4‐bit data bus or an 8‐ bit data bus. If a 4‐bit data bus is used, the LCD will require a
total of 7 data lines.
 If an 8‐bit data bus is used, the LCD will require a total of 11 data lines. The three
controls lines are EN, RS, and RW. Note that the EN line must be raised / lowered
before/after each instruction sent to the LCD regardless of whether that instruction is
read or write text or instruction. In short, you must always manipulate EN when
communicating with the LCD. EN is the LCD‟s way of knowing that you are talking to it.
If you don‟t raise/lower EN, the LCD doesn‟t know you‟re talking to it on the other
lines.

6.3. IMPLEMENTATION AT INSTITUTE LEVEL

6.3.1. Overview

Information sharing holds an important role in the daily work of our institute
LDRP-ITR. The current means of information transfer are notice and circulars. New
notice or circular is only checked at the end of the day. This makes the process very
time consuming and inefficient. Looking into current trend of information transfer in the
campus, it is seen that important notice take time to be displayed in the notice boards.
This latency is not expected in most of the cases and must be avoided.

6.3.2. Proposal

It is proposed to implement this project at the institute level. It is proposed to

place display boards at major access points. These include canteens, entrance gate,
hostel area etc. But, The GSM based display toolkit can be used as a add-on to these
display boards and make it truly wireless. The display board programs itself with the
help of the incoming SMS with proper validation. The valid senders may include the
Director, Deans and Registrars. The centralized system can be placed as the Computer
Center for access by any other valid users with authentications. SMS from these users
is treated to be valid and is displayed. Other SMS from any other mobile phone is
discarded. Thus information from valid sources can be broadcasted easily. Such a
system proves to be helpful for immediate information transfer and can be easily
implemented at the institute level.
Chapter – 7

TESTING
7.1. INITIALIZATION

The baud rate of the modem was set to be 4800 bps using the command
AT+IPR=4800.The ECHO from the modem was turned off using the command ATE/ATE0
at the hyper terminal. For serial transmission and reception to be possible both the DTE and
DCE should have same operational baud rates. Hence to set the microcontroller at a baud
rate of 4800bps, we set terminal count of Timer 1 at 0FFh (clock frequency = 1.8432). The
TCON and SCON registers were set accordingly.

7.2. SERIAL TRANSFER USING TI AND RI FLAGS

After setting the baud rates of the two devices both the devices are now ready to
transmit and receive data in form of characters. Transmission is done when TI flag is set
and similarly data is known to be received when the Rx flag is set. The microcontroller then
sends an AT command to the modem in form of string of characters serially just when the TI
flag is set. After reception of a character in the SBUF register of the microcontroller
(response of MODEM with the read message in its default format or ERROR message or
OK message), the RI flag is set and the received character is moved into the physical
memory of the microcontroller.

7.3. VALIDITY CHECK & DISPLAY

After serially receiving the characters the code then checks for start of the sender‟s
number and then compares the number character by character with the valid number pre
stored in the memory. Since we are employing just one valid number, we are able to do the
validation process dynamically i.e. without storing the new message in another location in
the memory. For more than one valid numbers we would require more memory locations to
first store the complete (valid/invalid) message in the memory and then perform the
comparison procedure. After validity check the control flow goes into the LCD program
module to display the valid message stored in the memory. In case of multiple valid
numbers all invalid stored messages are deleted by proper branching in the code to the
“delete-message” module.
7.4. RESULTS
Snapshots
1. Initializing

Fig 7.1 initialization

2. Typing the message in the mobile

Fig 7.2 typing the message in the mobile

3. Enter the valid authenticated phone number

Fig 7.3 Enter the valid authenticated phone number

4. Send the message

Fig 7.4 Send the message

5. Message is displayed in the notice board

Fig 7.5 Message is displayed in the notice board

6. Change the message

Fig 7.6 Change the message

7. Send the new message

Fig 7.7 Send the new message

8. Message sent

Fig 7.8 message sent

9. Message displayed
 Fig 7.9 message displayed
10. To clear notice board

Fig 7.10 to clear notice board

11. Send sdmc#
 Fig 7.11 send SDMC#
12. Notice board cleared

Fig 7.12 notice board cleared

 Chapter – 8

CONCLUSION
8.1. CONCLUSION

The prototype of the GSM based display toolkit was efficiently designed. This
prototype has facilities to be integrated with a display board thus making it truly
mobile. The toolkit accepts the SMS, stores it, validates it and then displays it in the
LCD module. The SMS is deleted from the SIM each time it is read, thus making
room for the next SMS. The major constraints incorporated are the use of „*‟ as the
termination character of the SMS and the display of one SMS as a time. These
limitations can be removed by the use of higher end microcontrollers and extended
RAM. The prototype can be implemented using commercial display boards. In this
case, it can solve the problem of instant information transfer in the campus.

8.2. FUTURE IMPROVEMENTS

The use of microcontroller in place of a general purpose computer allows us

to theorize on many further improvements on this project prototype. Temperature
display during periods wherein no message buffers are empty is one such
theoretical improvement that is very possible. The ideal state of the microcontroller
is when the indices or storage space in the SIM memory are empty and no new
message is there to display. With proper use of interrupt routines the incoming
message acts as an interrupt, the temperature display is halted and the control flow
jumps over to the specific interrupt service routine which first validates the sender‟s
number and then displays the information field. Another very interesting and
significant improvement would be to accommodate multiple receiver MODEMS at
the different positions in a geographical area carrying duplicate SIM cards. With the
help of principles of TDMA technique, we can choose to simulcast and /or broadcast
important notifications. After a display board receives the valid message through the
MODEM and displays it, it withdraws its identification from the network &
synchronously another nearby MODEM signs itself into the network and starts to
receive the message. The message is broadcast by the mobile switching center for a
continuous time period during which as many possible display board MODEMS
“catch” the message and display it as per the constraint of validation.

Multilingual display can be another added variation of the project. The display
boards are one of the single most important media for information transfer to the
maximum number of end users. This feature can be added by programming the
microcontroller to use different encoding decoding schemes in different areas as per
the local language. This will ensure the increase in the number of informed users.
Graphical display can also be considered as a long term but achievable and target
able output. MMS technology along with relatively high end microcontrollers to carry
on the tasks of graphics encoding and decoding along with a more expansive
bank of usable memory can make this task a walk in the park.
REFERENCES

Websites:
 http://en.wikipedia.org/wiki/Wikipedia
 http://www.atmel.com/
 http://images.google.com
 http://www.8052.com
 http://www.datasheetcatalog.com
 http://www.keil.com/forum/docs

Documents:
 Datasheet: MATRIX SIMADO GDT11 GSM MODEM Manual
 Datasheet: ATMEL 89S52 Microcontroller
 Datasheet: LCD HD44780
 Datasheet: MAX232 from Texas Instruments