Software Requirements:-

1) Java(jdk1.5 or higher)
2) Normal windows os.

Hardware Requirements:-

1) Gsm modem or a mobile.

2) Serial port.
3) A Pentium 4 pc with 256mb ram.

Introduction:-

The mobile sets are now a days used most widely and very commonly. The SMS can be send to
any mobile user of any service provider with no or a minimum charge. This system is designed
using a GSM modem. The GSM modem is configured as a receiver which send the SMS to a
computer after receiving it completely. The SMS sent by the user is written in a particular
format. The computer receive the message and decode it and identify the task to be done.
Accordingly The computer send requset to the sms gateway insisting it to send messgaes to set of
user which satisfies a given condition. In this way the devices connected to the controller is
operated through an SMS.

The advantage of SMS based control is as follows,

1. This is cheaper and the SMS can be retained in the network even though the network is busy
for some time.

2. The SMS can be written through internet with out any cost.

The present scenario of technological advancement and research is stepping forward towards the
high speed and long distance data communication. The Mobile and cellular technology is one of
the reliable and advanced media for the data communication. The information technology makes
mobile communication more popular and economical. The science and technology is moving
with fast pace towards long distance communication and data transmission. The advancement in
long distance communication essentially can create a global village. This project is conceptually
based on long distance data communication and control. In the present scenario the application
of mobiles are very much common, almost every one is using a mobile for their day to day
affairs. The mobile networks are covering globally. The idea to use the mobile as a remote
control device is definitely a innovative and widely accepted concept. The mobile set as a remote
control can cover wide area compare to any other remote control devices. The IR remote
controller and RF remote controllers have its limitation on its range where as the mobile based
remote controllers can have a global range using wireless cellular network. In this project an
attempt is made to //control the electrical appliances globally by using the cellular network//. The
SMS technique is inexpensive and more reliable as the data transfer is in text based. In most of
the network the SMS facility is inexpensive or free. This concept of control system is very much
use full for industrial and consumer application. This type of applications can be used in
industries for controlling devices also the user can get field information and data through GSM
modem in the format of SMS etc. // The SMS based appliance controller is conceptual step
towards realization of Global village.//

Since the introduction of the GSM networks in 1992, SMS has been a service with an increasing
interest. SMS is actually not designed for the success it is having today. The marketing guys
within the standardization group could not see any use of a service, requiring that the user should
press the same key several times to write a character. The only reason for SMS became part of
the standard, was the techical guys wanting it for service messages and testing.

Today, SMS is an extensively used service and almost everyone is able to use it. This has lead to
an increasing number of applications using SMS as the interface to the user. This project
contains an SMS framework, written in Java. The framework is designed for robustness in order
to serve as a gateway between users with their mobile phone, and the application. The
implemented application is an SMS-to-OSC gateway, sending all incomming SMS' to an sms
gateway provider capable host.

It is assumed that the reader is familiar with general Java programming.

Description of SMS

Short Message System (SMS) is a part of the Global System for Mobile Communications (GSM)
specification. GSM is initially specified by European Telecommunications Standards Institute
(ETSI - http://www.etsi.org). The current specification is controlled by 3rd Generation
Partnership Project (3GPP - http://www.3gpp.org), from where the specification can be
downloaded. Note, it is huge!

In the first phase of the GSM networks, SMS reception was mandatory for a mobile phone
(called Mobile Station (MS) in the specification), but sending SMS was an optional feature.
From phase 2 of the GSM networks (1997), sending SMS became mandatory. The current
networks are all phase 2 or later.

SMS is a no-guaranties service. The operator of the GSM network does not give any guaranties
for delivery of SMSs. Because of this, SMS is a costless service for the operator, as messages
can be sent during idle periods of the network.
An SMS is just a single datapacket or Protocol Data Unit (PDU) in the network, but PDUs
cannot be sent without a connection. In order to send an MS originated SMS, the MS creates a
connection to the Base Transceiver Station (BTS), sends the PDU containing the SMS, and
finally closes the connection. Because an SMS is limited to one single PDU, it can only contain
160 characters. Modern MSs are able to send longer SMSs, called Extended Message System
(EMS), which just are several ordinary SMSs displayed as one on the MS.
Serial Communication in Java

In order to use SMS in a computer application, an interface between the computer and the GSM
network is needed. This interface is typically an MS connected to a serial port on the computer.
In this project the serial connection to an MS is the interface.

In Java, serial communication is specified in the package javax.comm, which is a part of the
extended specification (the javax). Because it is part of the extended specification, it it not part of
the reference Java implementation from Sun . Sun has only implemented javax.comm for
Microsoft Windows and Sun's Solaris/SPARC platform . Implementations for other platforms
exist, e.g. the RxTx project , which provides the javax.comm package for Linux, MacOS X, etc.

When an application is communicating through a serial interface, it can basicly do this in two
ways: It can poll the serial port for data (synchronously), and it can receive data events
(something like interrupts) when data is received (asynchronously). The javax.comm allows you
to do both. Synchronous communication is done by using the read methods on the InputStream
of the serial port. If there is no data, the method will wait (block) until data is available or a
timeout occurs. The timeout value can be set by the SerialPort.enableReceiveTimeout(int).
Asynchronously communication is done by implementing the SerialPortEventListener interface.
This requires implementation of the method serialEvent(SerialPortEvent event). It is possible to
specify which kind of serial events the application wants, by using the SerialPort.notifyOn*()
methods.

When using serial ports in Java, it is very important to close the port when the class has finish
using it. If the port is not closed correctly, no other application will be able to use it. In an
environment where the Java Virtual Machine (JVM) is running for a long time, e.g. in an
application server, forgetting to close the serial port might result in the need for a restart of the
JVM (and thereby the application server) in order to release the serial port.

The Java Communications 3.0 API is a Java extension that facilitates developing platform-
independent communications applications for technologies such as Smart Cards, embedded
systems, and point-of-sale devices, financial services devices, fax, modems, display terminals,
and robotic equipment.
The Java Communications API (also known as javax.comm) provides applications access to RS-
232 hardware (serial ports) and limited access to IEEE-1284 (parallel ports), SPP mode.

Implementations of the API are currently available for Solaris SPARC, Solaris x86, and Linux
x86. Each of Sun's available implementations works with the Sun Ray thin client product line,
and include portmapping extensions to allow an administer to specify the locations of ports as
well as their visibility, names, and in some cases annotated reference
API serial features:

• Enumeration of ports (administrator and user configurable port mapping)

• Port configuration (baud rate, speed, stop bits, parity)
• Access to EIA232 standard DTR, CD, CTS, RTS and DSR signals
• Transfer of data over RS-232 ports
• Hardware and software flow-control options
• Receive-buffer threshold control
• Asynchronous event option for notification of:
o Data available on an RS-232 port
o Port hardware line level changes
o Port ownership changes within a single JVM

The Java Communications (a.k.a. javax.comm) API is a proposed standard extension

that enables authors of communications applications to write Java software that
accesses communications ports in a platform-independent way. This API may be
used to write terminal emulation software, fax software, smart-card reader
software, and so on. Developing good software usually means having some clearly
defined interfaces. The high-level diagram of the API interface layers are shown in
this figure.

Unlike classical drivers, which come with their own models of communication of
asynchronous events, the javax.comm API provides an event-style interface based
on the Java event model (java.awt.event package). Let's say we want to know if
there is any new data sitting on the input buffer. We can find that out in two ways --
by polling or listening . With polling, the processor checks the buffer periodically to
see if there is any new data in the buffer. With listening, the processor waits for an
event to occur in the form of new data in the input buffer. As soon as new data
arrives in the buffer, it sends a notification or event to the processor.
Among the various serial interfaces available, two of the most popular are the RS-
232C and RS-422 standards, which define the electrical signal levels and the
meaning of various signal lines. Low-speed serial interfaces typically clock data out
as a square wave, with clock coordination provided by start and stop bits.
RS-232 stands for Recommend Standard 232 ; the C simply refers to the latest
revision of the standard. The serial ports on most computers use a subset of the RS-
232C standard. The full RS-232C standard specifies a 25-pin "D" connector, of which
22 pins are used. Most of these pins are not needed for normal PC communications,
and indeed, most new PCs are equipped with male D-type connectors having only 9
pins.

FEATURES In DETAILS:-

The javax.comm API provides the following functionality to developers:

A complete API specification for serial and parallel communication ports. (In this
article we consider serial ports only.) Without a common API in your development
efforts, workload will increase because you'll have to provide support to serial
devices.
Full control of all serial framing parameters (baud stop bits, parity, bits/frame) as
well as manual or automatic control of the flow control lines. Normally, in RS-232,
there are two signal lines and the rest are intended for control lines. Depending on
the type of communication (synchronous or asynchronous), the number of control
lines selected may vary. This API provides access to the underlying control signals.
A brief diversion here may help you understand something about parity and start
and stop bits. Parity was added to RS-232 because communication lines can be
noisy. Let's say we send ASCII 0 , which in hex equals 0x30 (or 00110000 in binary),
but along the way someone passes by holding a magnet, causing one of the bits to
change. As a result, instead of sending 8 bits as intended, an additional bit is added
to the first string of bits sent, making the sum total of bits sent even or odd. voilà !
You've got parity.
Start and stop bits were added to the serial communication protocol to allow the
receivers to synchronize on the characters being sent. One-bit parity does not allow
error correction -- only detection. Solutions to this problem come from protocols
that are layered on top of the serial APIs. Most serial communication these days
uses block protocols with checksums (a mathematical function that can be
generated on the receiver and compared to the transmitted checksum) that allow
errors to be detected on larger groups of bits. When you are communicating with
your ISP over PPP, packets may be 128 bytes per packet with a checksum. If they
match, you are 99.999% sure the data is okay.
There are cases wherein this scheme doesn't work. For example, when sending
critical commands to devices that are very far out in the solar system, forward
correcting protocols can be used. Forward correcting protocols are needed because
there may be no time for a retransmission, and space has a lot of electromagnetic
noise.
Okay, back to the list of functionalities provided by the javax.comm API!
The basic I/O via a subclass of Java IO streams. For input and output, the
javax.comm API uses streams; the concept of streams should be familiar to all Java
programmers. It is important to reuse Java concepts when building new functionality
or the APIs will become unwieldy.
Streams that can be extended to provide client flow control and threshold controls.
For example, you may want an alert when there are 10 characters in the buffer or
when there are only 10 locations left for characters. Flow control is important when
the two devices connected via an interface cannot keep up with each other. Without
flow control, you can have overruns or underruns . In the overrun condition, you
received data before it was processed so it was lost; in the underrun, you were
ready for data but it was not available. Usually these conditions occur at the USART
(Universal Synchronous Asynchronous Receiver Transmitter), which is hardware
that converts bytes to a serial wave form with timing to match the baud rate.
The javax.comm API uses the Java event model to provide notification of various
signal line changes as well as buffer status. State changes refer to well-defined
signals specified in the RS-232 standard. For example, carrier detect is used by a
modem to signal that it has made a connection with another modem, or it has
detected a carrier tone. Making the connection or detecting a carrier tone is an
event. Event detection and notification of changes is implemented in this API.
What is not provided
The javax.comm API does not provide:
Line discipline type processing, dialer management, or modem management. Line
discipline refers to additional processing of input or output characters. For example,
one common post-processing option is the conversion of CR to CR LF. These terms
have their origins in the early days of teletypes. CR (carriage return) means to
simple-return the carriage to the left margin; in the Arabic world, this would be the
right margin. LF (line feed) advances the printing area up by one. When bitmap
screens and laser printers came along, these terms became less important.
Dialer management and modem management are additional applications that can
be written using the javax.comm API. Dialer management typically provides an
interface to the modem management's AT command interface. Almost all modems
have an AT command interface. This interface is documented in modem manuals.
Perhaps a little example will make this concept clear. Suppose we have a modem on
COM1 and we want to dial a phone number. A Java dialer management application
will query for the phone number and interrogate the modem. These commands are
carried by javax.comm, which does no interpretation. To dial the number
918003210288, for example, the dialer management probably sends an "AT,"
hoping to get back an "OK," followed by ATDT918003210288. One of the most
important tasks of dialer management and modem management is to deal with
errors and timeouts.
GUI for serial port management. Normally, serial ports have a dialog box that
configures the serial ports, allowing users to set parameters such as baud rate,
parity, and so on. The following diagram depicts the objects involved in reading
and/or writing data to a serial port from Java.
Support for X, Y, and Z modem protocols. These protocols provide support error
detection and correction.

The programming basics

Too often, programmers dive right into a project and code interactively with an API
on the screen without giving any thought to the problem they are trying to solve. To
avoid confusion and potential problems, gather the following information before you
start a project. Remember, programming devices usually requires that you consult a
manual.
Get the manual for the device and read the section on the RS-232 interface and RS-
232 protocol. Most devices have a protocol that must be followed. This protocol will
be carried by the javax.comm API and delivered to the device. The device will
decode the protocol, and you will have to pay close attention to sending data back
and forth. Not getting the initial set-up correct can mean your application won't
start, so take the time to test things out with a simple application. In other words,
create an application that can simply write data onto the serial port and then read
data from the serial port using the javax.comm API.

5.2.1. JAVA (FRONT END)

Java is related to C++, which is a direct descendent of C. Much of the

character of Java is inherited from these two languages. From C, Java derives its syntax. Many of
Java’s object-oriented features were influenced by C++. In fact, several of Java’s defining
characteristics come from—or are responses to—its predecessors. Moreover, the creation of Java
was deeply rooted in the process of refinement and adaptation that has been occurring in
computer programming languages for the past three decades. For these reasons, this section
reviews the sequence of events and forces that led up to Java. As you will see, each innovation in
language design was driven by the need to solve a fundamental problem that the preceding
languages could not solve. Java is handles exception.
The Swing Architecture
Swing is a platform-independent, Model-View-Controller GUI framework for Java. It follows a
single-threaded programming model, and possesses the following traits:

Foundations

Platform independence

Swing is platform independent both in terms of its expression (Java) and its implementation
(non-native universal rendering of widgets).

Extensible

Swing is a highly partitioned architecture, which allows for the "plugging" of various custom
implementations of specified framework interfaces: Users can provide their own custom
implementation(s) of these components to override the default implementations. In general,
Swing users can extend the framework by extending existing (framework) classes and/or
providing alternative implementations of core components.

Swing is a component-based framework. The distinction between objects and components is a

fairly subtle point: concisely, a component is a well-behaved object with a known/specified
characteristic pattern of behaviour. Swing objects asynchronously fire events, have "bound"
properties, and respond to a well-known set of commands (specific to the component.)
Specifically, Swing components are Java Beans components, compliant with the Java Beans
Component Architecture specifications.

Customizable

Given the programmatic rendering model of the Swing framework, fine control over the details
of rendering of a component is possible in Swing. As a general pattern, the visual representation
of a Swing component is a composition of a standard set of elements, such as a "border", "inset",
decorations, etc. Typically, users will programmatically customize a standard Swing component
(such as a JTable) by assigning specific Borders, Colors, Backgrounds, opacities, etc., as the
properties of that component. The core component will then use these property (settings) to
determine the appropriate renderers to use in painting its various aspects. However, it is also
completely possible to create unique GUI controls with highly customized visual representation.

Configurable

Swing's heavy reliance on runtime mechanisms and indirect composition patterns allows it to
respond at runtime to fundamental changes in its settings. For example, a Swing-based
application can change its look and feel at runtime. Further, users can provide their own look and
feel implementation, which allows for uniform changes in the look and feel of existing Swing
applications without any programmatic change to the application code.
Lightweight UI

Swing's configurability is a result of a choice not to use the native host OS's GUI controls for
displaying itself. Swing "paints" its controls programmatically through the use of Java 2D APIs,
rather than calling into a native user interface toolkit. Thus, a Swing component does not have a
corresponding native OS GUI component, and is free to render itself in any way that is possible
with the underlying graphics APIs.

However, at its core every Swing component relies on an AWT container, since (Swing's)
JComponent extends (AWT's) Container. This allows Swing to plug into the host OS's GUI
management framework, including the crucial device/screen mappings and user interactions,
such as key presses or mouse movements. Swing simply "transposes" its own (OS agnostic)
semantics over the underlying (OS specific) components. So, for example, every Swing
component paints its rendition on the graphic device in response to a call to component.paint(),
which is defined in (AWT) Container. But unlike AWT components, which delegated the
painting to their OS-native "heavyweight" widget, Swing components are responsible for their
own rendering.

This transposition and decoupling is not merely visual, and extends to Swing's management and
application of its own OS-independent semantics for events fired within its component
containment hierarchies. Generally speaking, the Swing Architecture delegates the task of
mapping the various flavors of OS GUI semantics onto a simple, but generalized, pattern to the
AWT container. Building on that generalized platform, it establishes its own rich and complex
GUI semantics in the form of the JComponent model. A review of the source of Container java
and JComponent java classes is recommended for further insights into the nature of the interface
between Swing's lightweight components and AWT's heavyweight widgets.

Loosely-Coupled and MVC

The Swing library makes heavy use of the Model/View/Controller software design pattern[1],
which conceptually decouples the data being viewed from the user interface controls through
which it is viewed. Because of this, most Swing components have associated models (which are
specified in terms of Java interfaces), and the programmer can use various default
implementations or provide their own. The framework provides default implementations of
model interfaces for all of its concrete components.

Typically, Swing component model objects are responsible for providing a concise interface
defining events fired, and accessible properties for the (conceptual) data model for use by the
associated JComponent. Given that the overall MVC pattern is a loosely-coupled collaborative
object relationship pattern, the model provides the programmatic means for attaching event
listeners to the data model object. Typically, these events are model centric (ex: a "row inserted"
event in a table model) and are mapped by the JComponent specialization into a meaningful
event for the GUI component.
For example, the JTable has a model called TableModel that describes an interface for how a
table would access tabular data. A default implementation of this operates on a two-dimensional
array.

The view component of a Swing JComponent is the object used to graphically "represent" the
conceptual GUI control. A distinction of Swing, as a GUI framework, is in its reliance on
programmatically-rendered GUI controls (as opposed to the use of the native host OS's GUI
controls). Prior to Java 6 Update 10, this distinction was a source of complications when mixing
AWT controls, which use native controls, with Swing controls in a GUI (see Mixing AWT and
Swing components).

Finally, in terms of visual composition and management, Swing favors relative layouts (which
specify the positional relationships between components) as opposed to absolute layouts (which
specify the exact location and size of components). This bias towards "fluid"' visual ordering is
due to its origins in the applet operating environment that framed the design and development of
the original Java GUI toolkit. (Conceptually, this view of the layout management is quite similar
to that which informs the rendering of HTML content in browsers, and addresses the same set of
concerns that motivated the former.)

Relationship to AWT

AWT and Swing class hierarchy

Since early versions of Java, a portion of the Abstract Window Toolkit (AWT) has provided
platform-independent APIs for user interface components. In AWT, each component is rendered
and controlled by a native peer component specific to the underlying windowing system.

By contrast, Swing components are often described as lightweight because they do not require
allocation of native resources in the operating system's windowing toolkit. The AWT
components are referred to as heavyweight components.
Much of the Swing API is generally a complementary extension of the AWT rather than a direct
replacement. In fact, every Swing lightweight interface ultimately exists within an AWT
heavyweight component because all of the top-level components in Swing (JApplet, JDialog,
JFrame, and JWindow) extend an AWT top-level container. However, the use of both lightweight
and heavyweight components within the same window is generally discouraged due to Z-order
incompatibilities.

The core rendering functionality used by Swing to draw its lightweight components is provided
by Java 2D, another part of JFC.

Relationship to SWT

The Standard Widget Toolkit (SWT) is a competing toolkit originally developed by IBM and
now maintained by the Eclipse community. SWT's implementation has more in common with
the heavyweight components of AWT. This confers benefits such as more accurate fidelity with
the underlying native windowing toolkit, at the cost of an increased exposure to the native
platform in the programming model.

The advent of SWT has given rise to a great deal of division among Java desktop developers,
with many strongly favoring either SWT or Swing. Sun's development on Swing continues to
focus on platform look and feel (PLAF) fidelity with each platform's windowing toolkit in the
approaching Java SE 7 release (as of December 2006).

There has been significant debate and speculation about the performance of SWT versus Swing;
some hinted that SWT's heavy dependence on JNI would make it slower when the GUI
component and Java need to communicate data, but faster at rendering when the data model has
been loaded into the GUI, but this has not been confirmed either way A fairly thorough set of
benchmarks concluded that neither Swing nor SWT clearly outperformed the other in the general
case.

SWT serves the Windows platform very well but is considered by some to be less effective as a
technology for cross-platform development. By using the high-level features of each native
windowing toolkit, SWT returns to the issues seen in the mid 90's (with toolkits like zApp, Zinc,
XVT and IBM/Smalltalk) where toolkits attempted to mask differences in focus behaviour, event
triggering and graphical layout. Failure to match behavior on each platform can cause subtle but
difficult-to-resolve bugs that impact user interaction and the appearance of the GUI.

Debugging
Swing application debugging can be difficult because of the toolkit's visual nature. In contrast to
non-visual applications, GUI applications cannot be as easily debugged using step-by-step
debuggers.

The main reason is that Swing normally performs painting into an off-screen buffer (double
buffering) first and then copies the entire result to the screen. This is to not let the user observe
the painting process which would be perceived as flickering. This makes it difficult to observe
the impact of each separate graphical operation on the user interface using a general-purpose
Java debugger. To help with this problem, one can turn off double buffering, and have the
drawing operations visualized using the built-in DebugGraphics object .Also, a free and open
source GUI-based debugging application called Swing Explorer will be of help with drawing
problems: It will locate which component painted every single pixel in a window, where each
component was instantiated, displays the time line for each drawing operation, and will present a
"DOM-like" tree of all Components in the JVM along with visualization of where the selected
component painted. All operations are done through a side GUI which injects itself into the
application, thus making Swing debugging considerably more effective.

There are also some common problems related to the painting thread. Swing uses the AWT event
dispatching thread for painting components. In accordance with Swing standards, all components
must be created and accessed only from the AWT event dispatch thread. If the application
violates this rule, it may cause unpredictable behavior. The third-party, free and open source
pluggable Look and Feel called Substance can help here, as it refuses to handle any components
off of the Event Dispatch Thread, thus pinpointing violations to this rule.

If long-running operations are performed in the AWT event dispatch thread, repainting of the
Swing user interface temporarily becomes impossible causing screen freezes. Such operations
must be moved into a separate thread.

It is worth emphasizing that these problems are not in any way unique to Swing - most GUI
toolkits necessarily have similar problem spaces with threading and buffering.

FLOWCHARTS:-
3.4. BLOCK DIAGRAM

PC with Rf signal
JAVA GSM
Appln MODEM

signals

Radio Frequency
Signals