You are on page 1of 45

ORGANIZATION PROFILE

India, as a country, has been very lucky with regard to the introduction of
telecom products. The first telegraph link was commissioned between
Calcutta and Diamond Harbor in the year 1852, which was invented in 1837.
First telephone exchange came up in 1882 following invention in 1876. First
wireless communication equipment were introduced Indian Army in the year
1909 with the discovery of Radio waves in 1887 by Hertz and demonstration
of first wireless link in the year 1905 by Marconi and Vacuum tube in 1906.
Setting up their radio station for the broadcast and other telecom facilities
almost immediately after their commercial introduction abroad followed this.

Bharat Electronics Limited (BEL) was established in 1954 as a Public


Sector Enterprise under the administrative control of Ministry of Defense as
the fountainhead to manufacture and supply electronics components and
equipment.

Over the years, BEL has grown to a multi-product, multi-unit, and


technology driven company with track record of a profit earning PSU. The
company has a unique position in India of having dealt with all the
generations of electronic component and equipment. Having started with a
HF receiver in collaboration with T-CSF of France, the company's equipment
designs have had a long voyage through the hybrid, solid-state discrete
component to the state of art integrated circuit technology.

BEL has nurtured and built a strong in-house R&D base by


absorbing technologies from more than 50 leading companies worldwide and
DRDO Labs for a wide range of products. A team of more than 800 engineers
is working in R&D.

Each unit has its own R&D Division to bring out new products to the
production lines. Central Research Laboratory (CRL) at Bangalore and
Ghaziabad works as independent agency to undertake contemporary design
work on state-of-art and futuristic technologies. About 70% of BEL's
products are of in-house design. BEL was among the first Indian companies
to manufacture computer parts and peripherals under arrangement with
International Computers India Limited (ICIL) in 1970s.Most of its software
requirements are in real time. EMCCA, software intensive naval ships control
and command system is probably one of the first projects of its nature in
India and Asia.
PRODUCTION UNITS
BEL has production units established at different parts of the country. 
Bangalore (Karnataka):
BEL started its production activities in Bangalore in 1954. Since then 
this unit has grown to specialize in communication and Radar/Sonar Systems 
for the Army, Navy & the Air Force. As an aid to electorate the unit has 
developed Electronic Voting Machines that are produced at its Mass 
Manufacturing Facility (MMF).

Ghaziabad (U.P.):
The second largest unit at Ghaziabad was set up in 1974 to manufacture 
special types of RADARS for the Air Defense Ground Environment Systems 
(Plan ADGES). The units production range includes Static and mobile RADARS, 
professional grade Antennae and microwave components.

Pune (Maharashtra):
This unit was started in 1979 to manufacture Image Converter Tubes. At 
present the unit manufactures Laser Sub­unit for tank fire control systems and 
Laser Range Finders for the Defense Services.

Machilipatnam (Andhra Pradesh):
The Andhra Scientific Co. at Machilipatnam, manufacturing 
optics/Optoelectronic equipments was integrated with BEL in 1983. The unit 
has successfully diversified to making the Surgical Microscope with zoom 
facilities.

Chennai (Tamil Nadu):
In 1985, BEL started another unit at Chennai to facilitate manufacture 
of Gun Control Equipment required for the integration and installation in the 
Vijayantra tanks. It is now manufacturing Stabilizer Systems for T­72 tanks.

Taloja (Maharashtra):
This unit is fully mobilized to manufacture 20’’ glass bulbs.

Hyderabad (Andhra Pradesh):
This unit was established in 1986 to coordinate with major defense R&D 
Laboratories located in Hyderabad. 
BEL, GHAZIABAD UNIT

In the mid 60's, while reviewing the Defense requirement of the country, the
government focused its attention to strengthen the air Defense system, in
particular the ground electronics system support, for the air Defense
network.
At about the same time, Public attention was focused on the report of
the Bhabha Committee on the development and production of electronic
equipment. The ministry of Defense immediately realized the need to
establish production capacity for meeting the electronic equipment
requirements for its Plan ADGES.
In December 1970 the Govt. sanctioned an additional unit for BEL. In
1971, the industrial license for manufacture of radar and microwave
equipment was obtained; 1972 saw the commencement of construction
activities and production was launched in 1974.
Over the years, the Unit has successfully manufactured a wide variety
of equipment needed for Defense and civil use. It has also installed and
commissioned a large number of systems on turnkey basis the operations at
BEL Ghaziabad are headed by General Manager with Additional / Deputy
General Manager heading various divisions - Design & Engineering Divisions,
Development and Engineering-R, Development and Engineering-C and
Development and Engineering-Antenna.
ROTATION
THE FIRST TWO WEEKS IN THE COMPANY WAS THE PERIOD OF ORIENTATION.
IN THIS PERIOD WE WERE TOLD ABOUT VARIOUS DEPARTMENT OF THE
COMPANY.

I AM BRIEFING MY EXPERIENCE AND OBSERVATION ABOUT


VARIOUS DEPARTMENTS OF THE COMPANY IN NEXT PARAGRAPHS.

About various Departments

TEST EQUIPMENT AND AUTOMATION


DEPARTMENT
TEST EQUIPMENT SUPPORT (TES)

Main functions are:


• Develops technical support to other departments.
• Repair of equipment in case of failure.
• Maintenance of equipments.
• Periodic calibration of equipments.
• Provide technical support to other departments. This includes:
1. Handling requests from the other department for
equipments.
2. Storage of rejected equipments.
3. Approval of equipments to be purchased.

This section deals with testing and the calibration of electronic


equipments only the standards of this department are calibrated by
National Physics Laboratory (NPL).

AUTOMATION TEST EQUIPMENT (ATE)


1. Component testing gives faults of various discrete components
of a PCB.
2. Integrated circuits tester tests various IC’s.
3. Functional testing compares output to decide whether the
function is being performed to the desired level of accuracy.
P.C.B. FABRICATION DEPARTMENT
PCB is abbreviated form of printed circuit board. As the name suggests,
in a PCB the electrical circuit is printed on a glass epoxy board. This
reduces the complex writing network whose trouble shooting in case of
shorting or misconnection is not easy.

Types of PCB’s:

Single Sided: Having circuit pattern only on one side of the board.
Double Sided: Having circuit pattern on both sides of the board

Following steps are taken in fabricating a P.C.B.

• Cladding of copper is done over an insulating material glass epoxy.


• Location holes are drilled over this Cupper clad with the help of C.N.C.
machine.
• Through hole plating of copper is done by dipping the plate into
acidic, alkaline and then into Cu bath.
• Then comes cleaning scrubbing and laminating of this Cu clad.
• Photoprinting with UV rays is done to print the circuit path.
• After photoprinting board is developed by removing lamination.
• Copper is electroplated over the board.
• Tin is electroplated over Cu electroplating to prevent Cu from
dissolving in Sodium Carbonate during etching and cleaning process.
• Board is etched and cleaned by dipping it into Sodium Carbonate
solution.
• Tin is striped from the board leaving Cu electroplating as it is.
• The board is again cleaned and scrubbed.
• Liquid Photo Emergable Solder Mask (LPISM) is put onto the board to
prevent it from the effects of environment.
• After solder masking the board again photoprinting is done over the
board.
• Board is now again developed by removing solder mask.
• Thermal baking of board is done after it’s development.
• Reverse marking of the board is done to enhance assembler’s work
easier.
• In final step board is routed and cleaned.
P.C.B.s thus fabricated are sent to P.C.B. assembly to get components
assembled on them.

QUALITY CONTROL WORKS


According to some laid down standards, the quality control department
ensures the quality of the product.

The raw materials and components etc. purchased are inspected


according to the specifications by the IG department. Similarly QC works
department inspects all the items manufactured in the factory.

The fabrication inspection checks all the fabricated parts and ensures
that these are made as per the part drawing. Plating, Painting and
stenciling etc are done and checked as per the BEL standards.

The assembly inspection department inspects all the assembled parts


such as PCB, cable assembly, cable form, modules, racks and shelters as
per latest documents and BEL standards.
The mistakes in the PCB can be categorized as:
• D&E mistake
• Shop mistake
• Inspection mistake

A process card is attached to each PCB under inspection. Any error in the
PCB is entered into the process card by certain codes specified for each
error or defect.

After mistake is detected, following actions are taken:


• Observation is made.
• Object code is given.
• Division code is given.
• Change code is prepared.
• Recommended action is taken.
WORKS ASSEMBLY
This department plays an important role in the production. Its main
function is to assemble various components, equipment’s and
instruments in a particular procedure. It has two sections, namely:
• PCB assembly
• Electronic assembly

In PCB assembly, the different types of PCB are assembled as per


BEL standards. PCB is received from the PCB department on which
soldering of component is done either by hand soldering or wave
soldering.

HAND SOLDERING: In case of hand soldering, soldering is done


manually.

WAVE SOLDERING: Wave soldering is a procedure in which PCB’s


are fed to the wave soldering machine from the opening on one side and
the soldering is done by machine and after the soldering is done PCB’s are
collected from the another opening of the machine and after that cleaning
is done.

The PCB’s are than send to testing department for testing according
to the product. Test procedure issued by the D&E department. After
testing PCB’s are lacquered and send to the planning store for storage.

In electronic assembly, the cable assemblies, cable forms modules,


drawers, racks and shelters are assembled. Every shelter (e.g. - DMT) is
made of racks, racks are made up of drawers, drawers are made up of
modules and modules are made up of PCB’s, cable assembly and cable
forms.

Every module or drawer before using in next assembly is send for


testing according to their PTP. Shop planning collects the purchase from
the IG store, takes fabricated parts, PCB’s etc. from planning stores and
issued to the assembly department as per the part list of the assembly to
be made.

The documents issued to the assembly are:


KS : Key Sheet
PL : Parts List
CL : Connection List for cable form
WL : Wiring List for modules
WD : Wiring Diagram
GA : General Assembly diagram

MAGNETICS DEPARTMENT
In the magnetics department different types of transformers and coils are
manufactured, which are used in the various defense equipments i.e. radar,
communication equipments. This department basically consists of three
sections.

PRODUCTION CONTROL
Basic function of production control is to plan the production of
transformer and coils as per the requirement of respective division (Radar &
Communication). This department is divided into two groups-
(a)Planning
(b)Planning store

WORKS (PRODUCTION)
Production of transformers and coils are being carried out by the works
departments. Following process are required for the manufacturing of
transformer / coils-
(a) Preparation of former
(b) Winding
(c) Insulation
(d) Tape
(e) Sleeve
(f) Impregnation
(g) Mechanical Assembly
(h) Enveloping
(i) Moulding
(j) Oil filling
(k) Painting
(l) Stencilling
Types of Transformer:-
Following types of transformers are being manufactured in this
department-
1. Air and Oil cool transformers
2. Pulse transformers
3. Air core type
4. Moulding type transformers
5. P.C.B. Mounting transformers
QUALITY CONTROL
After manufacturing the transformer /coils the otem is offered to the
inspection department to check the electrical parameters (DCR,No load
current, full load current, dielectric strength, inductance, insulation
resistance and mechanical dimension) as mention in the GA Drawing of the
product.
MICRO WAVE LABORATARY
This section undertakes:
1. Manufacturing of films and microwave components to meet
internal requirements.
2. Testing of low power antenna for which test-site is about 100 Km
from the factory at sohna.
The main component testing in this department is:
• Oscillators
• Amplifiers
• Mixers
• Radiation elements (e.g. Feeders)
• Microwave components (e.g. Isolators, circulators,
waveguides etc.)
• Filters (e.g. LPF, BPF, Uniplexers, and Multiplexers etc.)
Functioning of component is listed below:
• Frequency response
• Noise figure
• VSWR
• Directivity and coupling
• Power measurements
Various instruments in the lab are:
• Adaptor
• Attenuator
• Coupler
• Mixer
• Detector
DEVELOPMENT AND ENGINEERING
(D & E) DEPARTMENT
As the name suggests  D&E dept.  performs  the function of development  and 
engineering of the requirements of the company’s customers which are mainly 
national defense organizations. There are five sections in this dept. – Radar1, 
Radar2, Communication, Antennae and Data Handling. The five sections work 
in co­ordination with each other and give an aggregate result as output of D&E 
dept.   and   this   output   is   send   as   an   report   to   the   CRL   (Central   Research 
Laboratory)   where   the   requirements   of   the   customers   framed   by   D   &   E   are 
considered and a software is developed fulfilling all the requirements. 

The   pace   of   development   and   technological   obsolescence   in   the   field   of 


electronics necessitates a strong Research and Development base. This is all 
the   more   important   in   the   area   of   Defense   Electronics.   BEL   Ghaziabad   has 
since   its   inception   laid   a   heavy   emphasis   on   indigenous   Research   and 
Development

Design facilities are also constantly being modernized and substantial 
computer­aided design facilities are being introduced including installation of 
mini   and   microcomputers   and   dedicated   design   application.   About   170 
graduate   and   post­graduate   engineers   are   working   on   research   and 
development and indication of the importance R&D has in Bel's growth.
PROJECT
INTEGRATED AIR COMMAND AND
CONTROL SYSTEM (IACCS)
The IACCS system for Air Defence (AD) is required to automate the AD
Command and Control structure of the IAF. The system shall be capable of
automating three levels of the AD Command and Control echelon – the
‘Tactical level’ at Air Defence Direction Centers (ADDC), the ‘Operational
Level’ at Command HQ and the ‘Strategic Level’ at Air HQ. The IACCS would
be configured around a wide area Network, spanning across all the levels of
AD Command and Control Structure of the IAF. The implementation of IACCS
would involve generation of a composite, recognised Air Situation Picture
(ASP) by integrating all sensors and systems available in the network. At the
tactical level, five Command and Control Centres (ADDCs) would be
automated. Activities at the Tactical Level would involve generation of ASP
by integrating all available sensors and systems at each ADDC’s Area of
Responsibility (AOR), exchange of various data between each ADDC’s and
various AD elements within its AOR for conduct of operations. All elements,
including the airbases, weapon control centres, Command and Air HQ, would
be integrated into the IACCS Network as unique entities.

The IACCS system is also expected to connect to other networks such


as the Army, Naval, ODL and civil radar networks and facilitate availability of
near continuous surveillance capability over the Indian Air Space. The
system besides integrating surveillance inputs would also attempt to
automate a wide range of AD functions, especially at the ‘Tactical Level’,
ranging from Flight Plan Processing, Automated Identification, Threat
Evaluation, Weapon allocation, calculation of interception and recovery
solution etc. At the higher echelons, the system would provide total
situational awareness for all operators and decision makers besides
drastically cutting down on the sensor to the shooter reaction time.
TIME SYNCHRONIZATION MODULE
The aim of this time synchronization module is to synchronize all the
agencies of the IACCS Project with time. To obtain this aim all the agencies
query a server for time and date periodically. Thus I need to create two sub
modules viz. client and server

CLIENT SUB-MODULE

In this sub-module client query the server for time and date after a short
period of 10 seconds. Thus in this sub-module I need to set a timer of 10
seconds to query the server. To query the server client send datagrams of
request to the server socket and receive the datagrams of time and date on
it’s socket.

SERVER SUB MODULE

In this sub module server get the time from system and send the datagrams
of time and date to the client socket after receiving a request on it’s socket
from client.
SOCKETS
A socket is a communication mechanism that allows client/server systems to
be developed either locally, on a single machine, or across networks. Sockets
make a clear distinction between client and server. The socket mechanism
can implement multiple clients attached to a single server.

SOCKET CONNECTIONS

First of all, a server application creates a socket, which like a file


descriptor is a resource assigned to the server process and that process
alone. The server creates it using the system call socket, and it can’t be
shared with other processes.

Next, the server process gives the socket a name. Local sockets are
given a filename in the Linux file system, often to be found in /tmp or
/usr/tmp. A socket is named using the system call bind.

The client side of a socket-based system is more straightforward. The


client creates an unnamed socket by calling socket.

SOCKET ATTRIBUTES

Sockets are characterized by three attributes: domain, type, and


protocol. They also have an address used as their name.

Socket domains

Domains specify the network medium that the socket communication


will use. The most common socket domain is AF_INET, which refers to
Internet networking that’s used on many Linux local area networks and, of
course, the Internet itself. The underlying protocol, Internet Protocol (IP),
which only has one address family, imposes a particular way of specifying
computers on a network. This is called the IP address. All IP addresses are
represented by four numbers, each less than 256, a so-called dotted quad.
There may be several services available at the server computer. A
client can address a particular service on a networked machine by using an
IP port.

The domain AF_UNIX, which is the UNIX file system domain can be
used by sockets based on a single computer that perhaps isn’t networked.
When this is so, the underlying protocol is file input/output and the addresses
are absolute filenames.

Other domains that might be used include AF_ISO for networks based
on ISO standard protocols and AF_XNS for the Xerox Network System.

Socket Types

A socket domain may have a number of different ways of


communicating, each of which might have different characteristics. Internet
protocols provide two distinct levels of service: streams and datagrams.

Stream Sockets

Stream sockets (in some ways similar to standard input/output


streams) provide a connection that is a sequenced and reliable two-way byte
stream. Thus, data sent is guaranteed not to be lost, duplicated, or reordered
without an indication that an error has occurred. Large messages are
fragmented, transmitted, and reassembled.

Stream sockets, specified by the type SOCK_STREAM, are implemented


in the AF_INET domain by Transmission Protocol/Internet Protocol (TCP/IP)
connections.

Datagram Sockets

In contrast, a datagram socket, specified by the type SOCK_DGRAM,


doesn’t establish and maintain a connection. There is also a limit on the size
of a datagram that can be sent. It’s transmitted as a single network message
that may get lost, duplicated, or arrive out of sequence—ahead of datagrams
sent after it.

Datagram sockets are implemented in the AF_INET domain by UDP/IP


connections and provide an unsequenced, unreliable service. However, they
are relatively inexpensive in terms of resources, since network connections
need not be maintained. They’re fast because there is no associated
connection setup time. UDP stands for User Datagram Protocol.
Datagrams are useful for “single-shot” inquiries to information
services, for providing regular status information, or for performing low-
priority logging. They have the advantage that the death of a server doesn’t
necessarily require a client restart. Because datagram-based servers usually
retain no connection information, they can be stopped and restarted without
unduly disturbing their clients.

Socket Protocols

Where the underlying transport mechanism allows for more than one
protocol to provide the requested socket type, we can select a specific
protocol for a socket.

Creating a Socket

The socket system call creates a socket and returns a descriptor that
can be used for accessing the socket.

#include <sys/types.h>
#include <sys/socket.h>
int socket(int domain, int type, int protocol);

The socket created is one end point of a communication channel. The


domain parameter specifies the address family such as AF_UNIX and
AF_INET, the type parameter specifies the type of communication to be used
with this socket such as SOCK_STREAM and SOCK_DGRAM, and protocol
specifies the protocol to be employed, 0 selects the default protocol.

Socket Addresses

Each socket domain requires its own address format. In the AF_INET
domain, the address is specified using a structure called sockaddr_in,
defined in netinet/in.h, which contains at least these members:

struct sockaddr_in {
short int sin_family; /* AF_INET */
unsigned short int sin_port; /* Port number */
struct in_addr sin_addr; /* Internet address */
};

The IP address structure, in_addr, is defined as follows:


struct in_addr {
unsigned long int s_addr;
};

The four bytes of an IP address constitute a single 32-bit value. An


AF_INET socket is fully described by its domain, IP address, and port number.

Naming a Socket

To make a socket (as created by a call to socket) available for use by


other processes, a server program needs to give the socket a name. AF_INET
sockets are associated with an IP port number.

#include <sys/socket.h>
int bind(int socket, const struct sockaddr *address, size_t address_len);

The bind system call assigns the address specified in the parameter,
address, to the unnamed socket associated with the file descriptor socket.
The length of the address structure is passed as address_len.

On successful completion, bind returns 0. If it fails, it returns -1 and


sets errno defined within the system.

Closing a Socket

We can terminate a socket connection at the server and client by


calling close, just as you would for low-level file descriptors. We should
always close the socket at both ends.

SOCKET COMMUNICATIONS

For socket communications to take place specification of IP addresses


and port numbers of clients is needed.

If server is to communicate with remote clients, we must specify a set


of IP addresses that we are willing to allow. We can use the special value,
INADDR_ANY, to specify that we’ll accept connections from all of the
interfaces our computer may have. If we chose to, we could distinguish
between different network interfaces to separate, for example, internal Local
Area Network and external Wide Area Network connections. INADDR_ANY is a
32-bit integer value that we could use in the sin_addr.s_addr field of the
address structure.

Host and Network Byte Ordering

Port numbers and addresses are communicated over socket interfaces


as binary numbers. Different computers use different byte ordering for
integers. If the memory used for integers were simply copied byte-by-byte,
the two different computers would not be able to agree on integer values.

To enable computers of different types to agree on values for


multibyte integers transmitted over a network, we need to define a network
ordering. Client and server programs must convert their internal integer
representation to the network ordering before transmission.

#include <netinet/in.h>
unsigned long int htonl(unsigned long int hostlong);
unsigned short int htons(unsigned short int hostshort);

These functions convert 16-bit and 32-bit integers between native host
format and the standard network ordering. Their names are abbreviations for
conversions—for example, “host to network, long” (htonl) and “host to
network, short” (htons).

DATAGRAM COMMUNICATION

Services provided by UDP are typically used where a client needs to


make a short query of a server and expects a single short response. If the
cost in terms of processing time is low enough, the server is able to provide
this service by dealing with requests from clients one at a time, allowing the
operating system to hold incoming requests in a queue. This simplifies the
coding of the server. To use it, we send a single datagram to the service and
get a single datagram containing the date and time in response.

Since UDP is not a guaranteed service, however, you may find that
your datagram or your response goes missing. So if the data is important to
you, you would need to code your UDP clients carefully to check for errors
and retry if necessary. In practice, on a local area network, UDP datagrams
are very reliable. two datagram-specific system calls, sendto
and recvfrom.

The sendto system call sends a datagram from a buffer on a socket


using a socket address and address length. Its prototype is essentially

int sendto(int sockfd, void *buffer, size_t len, int flags,


struct sockaddr *to, socklen_t tolen);

The recvfrom system call waits on a socket for a datagram from a


specified address and receives it into a buffer. Its prototype is essentially

int recvfrom(int sockfd, void *buffer, size_t len, int flags,


struct sockaddr *from, socklen_t *fromlen);

In normal use, the flags parameter can be kept zero in both the cases.

MULTIPLE CLIENTS

Sockets are used to implement client/server systems both locally and


across networks. In the case of multiple, simultaneous clients connecting to a
server, server has to create a new process to deal with these clients. We can
create a new process by calling fork.

Duplicating a process image

The fork system call duplicates the current process, creating a new
entry in the process table with many of the same attributes as the current
process.

The call to fork in the parent returns the Process ID (PID) of the new
child process. The new process continues to execute just like the original,
with the exception that in the child process the call to fork returns 0.

If fork fails, it returns -1


If the server calls fork to create a second copy of itself, the open socket
will be inherited by the new child process. It can then communicate with the
connecting client while the main server continues to accept further client
requests.

Since our server has to handle simultaneous clients so we are not


waiting for child process to complete and arranging for the server to ignore
SIGCHILD signals generated after exit of child process with the special value
SIG_IGN which is used to indicate that the signal is to be ignored. Now we
need to know about signals.

Signals

A signal is an event generated by the UNIX and Linux systems in


response to some condition, upon receipt of which a process may in turn
take some action. A most robust programming interface for signals is
sigaction.

#include <signal.h>
int sigaction(int sig, const struct sigaction *act, struct sigaction *oact);

The sigaction structure, used to define the actions to be taken on


receipt of the signal specified by sig, is defined in signal.h and has at least
the following members:

void (*) (int) sa_handler /* function, SIG_DFL or SIG_IGN


sigset_t sa_mask /* signals to block in sa_handler
int sa_flags /* signal action modifiers

Sigaction returns 0 if successful and -1 if not.


Within the sigaction structure pointed to by the argument act, sa_handler is
a pointer to a function called when signal sig is received.

SETTING TIMER

As we want our client to query the server after a time interval again
and again thus we need to set an interval timer which can be done with the
help of function setitimer(). This function sets the value of interval timer, I’ts
syntax is

int setitimer (int which, const struct itimerval*value, struct itimerval*


ovalue);
The system provides each process with three interval timers, each
decrementing in distinct time domain. When any timer expires, a signal is
sent to the process, and the timer (potentially) restarts. In the syntax which
indicates one of the three timers to be used. I have used ITIMER_REAL. It
decrements in real time, and delivers SIGALRM upon expiration.

Timer values are defined by the following structures:

struct itimerval {
struct timeval it_interval; /* next value*/
struct timeval it_value; /*current value*/
};

struct timeval {
long tv_sec; /*seconds*/
long tv_usec /*microseconds*/
};

The function setitimer sets the indicated timer to the value in value. If
ovalue is non zero, the old value of the timer is stored there.

Timer decrements from it_value to zero, generate a signal, and reset to


it_interval. A timer which is set to zero ( it_value is zero or the timer expires
and it_interval is zero) stops.

Both the tv_sec and and tv_usec are significant in determining the
duration of a timer.
CODING
SOFTWARE USED
• TURBO C
• LINUX ENTERPRISING EDITION

CLIENT PAGE

#include<sys/types.h>
#include<sys/socket.h>
#include<stdio.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<unistd.h>
#include<string.h>
#include<time.h>
#include<sys/time.h>
#include<signal.h>

struct mytime
{
struct timeval tv;
struct timezone tz;
};
struct mytime mytimevarc;
struct tm *tmvar;

void setnewdate(int *status)


{
*status=settimeofday(&mytimevarc.tv,&mytimevarc.tz);
tmvar=localtime(&mytimevarc.tv.tv_sec);
}

void querytheserver()
{
int sockfd,status;
struct sockaddr_in address;
int result,len;

sockfd=socket(AF_INET,SOCK_DGRAM,0);

address.sin_family=AF_INET;
address.sin_addr.s_addr=htonl(INADDR_ANY);
address.sin_port=htons(9734);

len=sizeof(address);

//Send an empty packet to the server


sendto(sockfd,&mytimevarc,sizeof(mytimevarc),0,(struct
sockaddr*)&address,len);

printf("Sending a request to server\n");

//Receive the filled packet from the server


recvfrom(sockfd,&mytimevarc,sizeof(mytimevarc),0,(struct
sockaddr *)&address,len);

//Set the new date received from the server


setnewdate(&status);

if(status==0)
{ printf("\nDate/Time succesfully set\n");
}
printf("%d/%d/%d\n",tmvar->tm_mday,tmvar-
>tm_mon+1,tmvar->tm_year+1900);
printf("%d:%d:%d\n",tmvar->tm_hour,tmvar->tm_min,tmvar-
>tm_sec);

close(sockfd);
}
int main()
{
struct sigaction act2;
struct itimerval timer;

querytheserver();

//Setting a 10 seconds timer


timer.it_value.tv_sec=10;
timer.it_value.tv_usec=0;
timer.it_interval.tv_sec=10;
timer.it_interval.tv_usec=0;
setitimer(ITIMER_REAL,&timer,NULL);

//Defining a handler to handle the SIGALRM


act2.sa_handler=querytheserver;
sigemptyset(&act2.sa_mask);
act2.sa_flags=SA_NODEFER;
sigaction(SIGALRM,&act2,0);

//Program shall run an infinite loop


while(1)
{
}
return(0);

}
SERVER PAGE

#include<sys/types.h>
#include<sys/socket.h>
#include<stdio.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<unistd.h>
#include<string.h>
#include<time.h>
#include<sys/time.h>
#include<signal.h>

struct mytime
{
struct timeval tv;
struct timezone tz;
};
struct mytime mytimevars;
struct tm *tmvar;

void whatisthedate()
{
//To get the time of day in sec elapsed from Jan 1, 1970 00:00hrs
gettimeofday(&mytimevars.tv,&mytimevars.tz);
//Convert the seconds into fields viz: hour, min, sec, etc
tmvar=localtime(&mytimevars.tv.tv_sec);
}
int main()
{ int server_sockfd, client_sockfd;
int server_len, client_len;
struct sockaddr_in server_address;
struct sockaddr_in client_address;

server_sockfd=socket(AF_INET,SOCK_DGRAM,0);

server_address.sin_family=AF_INET;
server_address.sin_addr.s_addr=htonl(INADDR_ANY);
server_address.sin_port=htons(9734);
server_len=sizeof(server_address);

bind(server_sockfd,(struct sockaddr*)
&server_address,server_len);
client_len=sizeof(client_address);
signal(SIGCHLD, SIG_IGN);
while(1)
{
printf("\nServer Waiting\n");

recvfrom(server_sockfd,&mytimevars,sizeof(struct mytime),0,
(struct sockaddr*)&client_address,&client_len);

//Fork a child process


if(fork()==0)
{
printf("-------------Got a request from
%s------------------",inet_ntoa(client_address.sin_addr));

//Fill the packet to be sent back


whatisthedate();

printf("\nSending %d/%d/%d::%d:%d:%d\n",tmvar-
>tm_mday,tmvar->tm_mon+1,tmvar->tm_year+1900,tmvar-
>tm_hour,tmvar->tm_min,tmvar->tm_sec);
//Send the filled packet back to the client after filling it with the
correct date and time.
sendto(server_sockfd,&mytimevars,sizeof(struct mytime),0,
(struct sockaddr*)&client_address,client_len);

close(client_sockfd);
exit(0);
}
else
{
close(client_sockfd);
}
}
}
OUTPUT SNAPSHOTS
SERVER IS WAITING FOR CLIENTS TO SEND DATAGRAMS
TIME SYNCHRONIZATION IN A CLIENT AND SERVER
TIME SYNCHRONIZATION IN A SERVER AND MULTIPLE CLIENTS
PROVISION FOR INCLUSION OF GPS SUPPORT
IN THE PROJECT
Till now we have seen that server sends the system time to the client, but
there is also provision for inclusion of GPS support for time synchronization.
Time and date can be received from a GPS receiver on a serial port of a
server in a pre defined message format and can be sent to the client. Now
we should know about GPS, in which format message is received at serial
port and then how to read the messege from serial port. First have a look on
a brief description of GPS.

NMEA 0183 is an interface protocol created by the National Marine


Electronics Association. The latest release of NMEA 0183 is Version 2.1
(October 15, 1995). This protocol was originally established to allow
marine navigation equipment to share information. NMEA 0183 is a
simple, yet comprehensive ASCII protocol which defines both the
communication interface and the data format.

NMEA 0183 Message Format


The NMEA 0183 protocol covers a broad array of navigation data. This
broad array of information is separated into discrete messages which
convey a specific set of information. The entire protocol encompasses
over 50 messages, but only a sub-set of these messages apply to a GPS
receiver like the Lassen SK II GPS. The NMEA message structure is
described below.

$IDMSG,D1,D2,D3,D4,.......,Dn*CS[CR][LF]

“$” The “$” signifies the start of a message.

ID The talker identification is a two letter mnemonic which describes the


source of the navigation information. The GP identification signifies a
GPS source.

MSG The message identification is a three letter mnemonic which


describes the message content and the number and order of the data
fields.

“,” Commas serve as delimiters for the data fields.

Dn Each message contains multiple data fields (Dn) which are delimited
by
commas.

“*” The asterisk serves as a checksum delimiter.


CS The checksum field contains two ASCII characters which indicate the
hexadecimal value of the checksum.

[CR][LF] The carriage return [CR] and line feed [LF] combination terminate
the message.

NMEA 0183 messages vary in length, but each message is limited to 79


characters or less. This length limitation excludes the “$” and the [CR]
[LF]. The data field block, including delimiters, is limited to 74 characters
or less.

NMEA 0183 Message Options

The Lassen SK II GPS outputs two messages: GGA (NMEA Version 2.1) and
VTG.

NMEA 0183 Message Formats

GGA - GPS Fix Data


The GGA message includes time, position and fix related data for the GPS
receiver.

$GP GGA,hhmmss,llll.lll,a,nnnnn.nnn,b,t,uu,v.v,w.w,M,x.x,M,y.y,zzzz*hh
<CR><LF>

GGA - GPS Fix Data Message Parameters

Field Description

1 UTC of Position
2,3 Latitude, (North) or S (South)
4,5 Longitude, E (East) or W (West)
6 GPS Quality Indicator: 0 = No GPS, 1 = GPS, 2 = DGPS
7 Number of Satellites in Use
8 Horizontal Dilution of Precision (HDOP)
9 ,10 Antenna Altitude in Meters, M = Meters
11,12 Geoidal Separation in Meters, M=Meters. Geoidal separation is the
difference between the WGS-84 earth ellipsoid and mean-sea-level.
13 Age of Differential GPS Data. Time in seconds since the last Type 1 or
9 Update
14 Differential Reference Station ID (0000 to 1023)
hh Checksum
SERIAL PORT COMMUNICATION
Computers transfer information (data) one or more bits at a time.
Serial refers to the transfer of data one bit at a time. Serial communications
include most network devices, keyboards, mice, MODEMs, and terminals.

When referring to serial devices or ports, they are either labeled as


Data Communications Equipment ("DCE") or Data Terminal Equipment
("DTE"). The difference between these is simple - every signal pair, like
transmit and receive, is swapped. When connecting two DTE or two DCE
interfaces together, a serial null-MODEM cable or adapter is used that swaps
the signal pairs.

Asynchronous Communications

In asynchronous mode the serial data line stays in the mark (1) state
until a character is transmitted. A start bit preceeds each character and is
followed immediately by each bit in the character, an optional parity bit, and
one or more stop bits. The start bit is always a space (0)

The optional parity bit is a simple sum of the data bits indicating
whether or not the data contains an even or odd number of 1 bits. With even
parity, the parity bit is 0 if there is an even number of 1's in the character.
With odd parity, the parity bit is 0 if there is an odd number of 1's in the data
Space parity means that the parity bit is always 0, while mark parity means
the bit is always

Flow Control

It is often necessary to regulate the flow of data when transferring data


between two serial interfaces. This can be due to limitations in an
intermediate serial communications link, one of the serial interfaces, or some
storage media. Two methods are commonly used for asynchronous data.

The first method is often called "software" flow control and uses
special characters to start (XON or DC1, 021 octal) or stop (XOFF or DC3,
023 octal) the flow of data.

The second method is called "hardware" flow control and uses the RS-
232 CTS and RTS signals instead of special characters

Synchronous Communications

Unlike asynchronous data, synchronous data appears as a constant


stream of bits. To read the data on the line, the computer must provide or
receive a common bit clock so that both the sender and receiver are
synchronized.

Even with this synchronization, the computer must mark the


beginning of the data somehow. The most common way of doing this is to
use a data packet protocol like Serial Data Link Control ("SDLC") or High-
Speed Data Link Control ("HDLC").

Each protocol defines certain bit sequences to represent the


beginning and end of a data packet. Each also defines a bit sequence that
is used when there is no data. These bit sequences allow the computer to
see the beginning of a data packet

ACCESING SERIAL PORTS

LINUX provides access to serial ports via device files To access a serial
port you simply open the corresponding device file.

Serial Port Files

Each serial port on a UNIX system has one or more device files (files in the
/dev directory) associated with it. For LINUX these are
Port 1 – /dev/ttyS0
Port 2 - /dev/ttyS1

Opening a Serial Port

Since a serial port is a file, the open(2) function is used to access it.
Necesarry files to include are:

#include <stdio.h> /* Standard input/output definitions */


#include <string.h> /* String function definitions */
#include <unistd.h> /* UNIX standard function definitions */
#include <fcntl.h> /* File control definitions */
#include <errno.h> /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */

Open options:

fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

fd is file descriptor for the port It returns -1 if port could not be opened

The O_NOCTTY flag tells UNIX that this program doesn't want to be
the "controlling terminal" for that port
The O_NDELAY flag tells UNIX that this program doesn't care what
state the DCD signal line is in - whether the other end of the port is up
and running.

Writing Data to the Port

Writing data to the port is easy - just use the write(2) system call to
send data it:

n = write(fd, "ATZ\r", 4);


if (n < 0)
fputs("write() of 4 bytes failed!\n", stderr);

The write function returns the number of bytes sent or -1 if an error


occurred.

Reading Data from the Port

Reading data from a port is a little trickier. The read function can be
made to return immediately by doing the following:

fcntl(fd, F_SETFL, FNDELAY);

The FNDELAY option causes the read function to return 0 if no


characters are available on the port. To restore normal (blocking)
behavior, call fcntl() without the FNDELAY option:

fcntl(fd, F_SETFL, 0);

This is also used after opening a serial port with the O_NDELAY option.

Closing a serial port

To close the serial port, just use the close system call

close(fd);

CONFIGURING THE SERIAL PORT


Most systems support the POSIX terminal (serial) interface for
changing parameters such as baud rate, character size, and so on. The
include file <termios.h>; defines the terminal control structure as well as
the POSIX control functions.
The two most important POSIX functions are tcgetattr(3) and
tcsetattr(3). These get and set terminal attributes, respectively; we
provide a pointer to a termios structure that contains all of the serial
options available:

Termios Structure Members


Member Description
c_cflag Control options
c_lflag Line options
c_iflag Input options
c_oflag Output options
c_cc Control characters
c_ispeed Input baud (new interface)
c_ospeed Output baud (new interface)

Control Options
The c_cflag member controls the baud rate, number of data bits,
parity, stop bits, and hardware flow control. The c_cflag member contains
two options that should always be enabled, CLOCAL and CREAD. These
will ensure that your program does not become the 'owner' of the port
subject to sporatic job control and hangup signals, and also that the serial
interface driver will read incoming data bytes.
The baud rate constants (CBAUD, B9600, etc.) are used for older
interfaces that lack the c_ispeed and c_ospeed members.

Setting the Baud Rate

The cfsetospeed(3) and cfsetispeed(3) functions are provided to set


the baud rate in the termios structure regardless of the underlying
operating system interface.

The tcgetattr(3) function fills the termios structure you provide with
the current serial port configuration. After we set the baud rates and
enable local mode and serial data receipt, we select the new configuration
using tcsetattr(3). The TCSANOW constant specifies that all changes
should occur immediately without waiting for output data to finish sending
or input data to finish receiving.

Setting the Character Size

Unlike the baud rate, there is no convenience function to set the


character size. Instead you must do a little bit masking to set things up.
The character size is specified in bits:

options.c_cflag &= ~CSIZE; /* Mask the character size bits */


options.c_cflag |= CS8; /* Select 8 data bits */

Setting Parity Checking

Like the character size you must manually set the parity enable and
parity type bits. UNIX serial drivers support even, odd, and no parity bit
generation. Space parity can be simulated with clever coding.

• No parity (8N1):
• options.c_cflag &= ~PARENB
• options.c_cflag &= ~CSTOPB
• options.c_cflag &= ~CSIZE;
• options.c_cflag |= CS8;

Setting Hardware Flow Control

Some versions of UNIX support hardware flow control using the CTS
(Clear To Send) and RTS (Request To Send) signal lines. If the
CNEW_RTSCTS or CRTSCTS constants are defined on your system then
hardware flow control is probably supported. Do the following to enable
hardware flow control:

options.c_cflag |= CNEW_RTSCTS; /* Also called CRTSCTS */

Similarly, to disable hardware flow control:

options.c_cflag &= ~CNEW_RTSCTS

Local Options

The local modes member c_lflag controls how input characters are
managed by the serial driver. In general you will configure the c_lflag
member for canonical or raw input.
Choosing Canonical Input

Canonical input is line-oriented. Input characters are put into a


buffer which can be edited interactively by the user until a CR (carriage
return) or LF (line feed) character is received.

When selecting this mode you normally select the ICANON option:

options.c_lflag |= (ICANON);

Choosing Raw Input

Raw input is unprocessed. Input characters are passed through


exactly as they are received, when they are received. Generally you'll
deselect the ICANON option when using raw input:

options.c_lflag &= ~(ICANON);

Input Options

The input modes member c_iflag controls any input processing that
is done to characters received on the port.

Setting Software Flow Control

Software flow control is enabled using the IXON, IXOFF, and IXANY
constants:

options.c_iflag |= (IXON | IXOFF | IXANY);

To disable software flow control simply mask those bits:

options.c_iflag &= ~(IXON | IXOFF | IXANY);

Output Options

The c_oflag member contains output filtering options Like the input
modes, you can select processed or raw data output.

Choosing Processed Output

Processed output is selected by setting the OPOST option in the


c_oflag member:

options.c_oflag |= OPOST;
Of all the different options, you will only probably use the ONLCR
option which maps newlines into CR-LF pairs. The rest of the output
options are primarily historic and date back to the time when line printers
and terminals could not keep up with the serial data stream!

Choosing Raw Output

Raw output is selected by resetting the OPOST option in the c_oflag


member:

options.c_oflag &= ~OPOST;

When the OPOST option is disabled, all other option bits in c_oflag are
ignored.

o RS-574 (IBM PC/AT) Pinouts


The RS-574 interface is used exclusively by PC manufacturers and
uses a 9-pin male D-Sub connector:

RS-574 Connector

RS-574 (IBM PC/AT) Signals


Pin Description Pin Description
1 DCD - Data Carrier Detect 6 Data Set Ready
2 RXD - Received Data 7 RTS - Request To Send
3 TXD - Transmitted Data 8 CTS - Clear To Send
4 DTR - Data Terminal Ready 9 Ring Detect
5 GND - Logic Ground

//To test the serial port

#include<stdio.h>

#include<unistd.h>

#include<fcntl.h>
#include<errno.h>

#include<termios.h>

int open_port()

int fd;

char buff[60];

struct termios options;

fd=open("/dev/ttyS0",O_RDWR|O_NOCTTY|O_NDELAY);

if(fd==-1)

perror("Couldn't open\n");

return(1);

else

printf("\nPort opened\n");

if(write(fd,"ABC\n",4)<0)
{ printf("Write failed\n");

else

{printf("Data written successfully\n");

tcgetattr(fd,&options);

options.c_cflag|=(CLOCAL|CREAD);

options.c_cflag &= ~PARENB;

options.c_cflag &= ~CSTOP;

options.c_cflag &= ~CSIZE;

options.c_cflag |= CS8;

options.c_iflag |= (IXON | IXOFF | IXANY);

options.c_oflag &= ~OPOST;

//options.c_oflag |= ONLCR;

//options.c_lflag &= ~ICANON;

cfsetispeed(&options,B19200);

cfsetospeed(&options,B19200);

fcntl(fd,F_SETFL,0);

tcsetattr(fd,TCSANOW,&options);

while(1)
{

bzero(buff,60);

scanf("%s",buff);

write(fd,buff,60);

return(fd);

int main()

{ open_port();

Receive

//To test the serial port

#include<stdio.h>

#include<unistd.h>

#include<fcntl.h>

#include<errno.h>

#include<termios.h>
int open_port()

int fd;

char buff[60];

struct termios options;

fd=open("/dev/ttyS0",O_RDWR|O_NOCTTY|O_NDELAY);

if(fd==-1)

perror("Couldn't open\n");

return(1);

else

printf("\nPort opened\n");

if(write(fd,"ABC\n",4)<0)

{ printf("Write failed\n");

else

{printf("Data written successfully\n");


}

tcgetattr(fd,&options); //Getting the serial port


attributes

options.c_cflag|=(CLOCAL|CREAD); //My program shold


not be the owner o the port

//The program is goin to read the


incoming data

options.c_cflag &= ~PARENB; //Disable parity

options.c_cflag &= ~CSTOP; //Only one stop bit

options.c_cflag &= ~CSIZE; //Specify the size of the


character

options.c_cflag |= CS8;

options.c_iflag |= (IXON | IXOFF | IXANY); //To enable


software flow control outgoing/incoming/any character can
start

//options.c_iflag |= IGNCR;

options.c_lflag |= ICANON; //Data will be sent only


after hitting Enter key
cfsetispeed(&options,B19200); //Input output baude
rate setting

cfsetospeed(&options,B19200);

fcntl(fd,F_SETFL,0); //The read call must block and


wait for the incoming character

tcsetattr(fd,TCSANOW,&options); //Saving the termios


structure

while(1)

bzero(buff,60);

read(fd,buff,60);

printf("\n%s\n",buff);

return(fd);

int main()

{ open_port();