CHAPTER 1

INTRODUCTION

1
 1.1 BACKGROUND

Embedded system is an intelligent system that has the capability of processing,

monitoring and controlling. It may comprise of Sensors, Microcontrollers, FPGA, ASIC,
etc. It typically has a specialized function with programs stored on ROM. Examples of
embedded systems are automatic environmental systems, security systems, and
entertainment systems.
An added feature in any embedded system is its ability to communicate. The
communication can be via Bluetooth, WI-FI, GSM, or Ethernet cables. The TCP/IP
protocol is a widely used standard for modern digital communication.
A weather station is a facility with instruments and equipment to make weather
observations by monitoring atmospheric conditions.
The project we have undertaken is “IP based Weather Station (Mausam
Parisuchak)”. It includes the three concepts we discussed earlier viz. embedded systems,
TCP/IP communication, and weather station. It provides real time data of weather in
remote/inaccessible locations through a wireless /wired connection.

1.2 NEED OF THE PROJECT

Nepal being a mountianous country it is difficult to build some development

infrastructures. One of the biggest mountain ranges of the world, The Himalayas, lies in
Nepal. Various organisation like ACAP, ICIMOD, and many other NGOs and GOs are
working to solve this problem through sustainable tourism and natural disaster mitigation
(eg:- bursting of glacier lakes, avalanche, etc).
The existing weather data collection technology in Nepal is backward for example
in Godawari ICIMOD is implementing data loggers which collect data and logged into
the magnetic hard disk which is swept at a frequency of 48 hrs manually. Our National
Meteorological Department (NMD) has manual data collection process. Sometimes this
may result in the problem of unavailability of weather data at the time of necessity. Our
project “IP based weather station” can play a vital by addressing to these problems and
providing data which can be used for monitoring various activities.

2
1.3 OBJECTIVE

Main objective of our project is to make internet/ip enabled embedded device

serving as advanced remote data logger which can be accessed remotely via
workstation. Our internet enabled device “alias: Mausam Parisuchak” will be
interfaced with various sensors like temperature sensor, humidity sensor.

This project finds its application in various fields like Weather Forecasting
Department, organizations like ICIMOD (International Center for Integrated Mountain
Development), ACAP (Annapurna Conservation Area Project), etc which works on
remote monitoring and development of the mountainous areas.

Looking at the benefits of its technical efficiency and practical implementation

along with its coverage of course materials like Telecommunication, Instrumentation,
Electronic Circuits, we selected this project as our final year project.

On completion of this project, our module will be used by ICIMOD at Godawari

for its practical implementation.

1.4 OUTLINE OF THE PROJECT

The system designed in our project applied to monitor weather data from the
remote field. The weather data is then communicated or transmitted to the central server
through an Ethernet connection. The server is a web and database server which holds all
the past data transmitted by the system and also servers web pages to the public internet
users.

The sensors we have decided to use are the Temperature and Light Dependent
Sensors. They are connected to the PIC18F4620 microcontroller.

3
 The PIC18F4620 microcontroller is used as a computer and the ENC28J60 is used
to connect the microcontroller to a LAN. The LCD display and the serial port interface
provide more functionality to the overall system. The LCD displays the current and any
new IP address of the Ethernet chip.

The serial connection is used rarely in our system like to configure our module
(e.g. to change the IP address). It can also be used for debugging purposes. Thus serial
connection is not so compulsory section in our project.

Fig1.1: Simplified Diagram of Component Interconnections

4
 CHAPTER 2
LITERATURE REVIEW

5
 2.1 HARDWARE COMPONENT OVERVIEW

Our project comprises of following hardware components:

• Sensors
o Temperature
o LDR
• PIC18F4620 microcontroller
• ENC28J60 Ethernet chip
• Magnetic Ethernet jack
• RS232 Serial port
• LCD
• LAN connectivity

2.1.1 Sensors

2.1.1.1 Temperature sensor

The LM35 is an integrated circuit sensor that can be used to measure
temperature with an electrical output proportional to the temperature (in oC). The LM35
thus has an advantage over linear temperature sensors calibrated in ° Kelvin, as the user is
not required to subtract a large constant voltage from its output to obtain convenient
Centigrade scaling. The LM35's low output impedance, linear output, and precise inherent
calibration make interfacing to readout or control circuitry especially easy. The sensor
circuitry is sealed and not subject to oxidation, etc. The LM35 generates a higher output
voltage than thermocouples and may not require that the output voltage be amplified.

6
 Fig 2.1: LM35 connection circuit

Features

• Calibrated directly in ° Celsius (Centigrade)

• Linear + 10.0 mV/°C scale factor
• 0.5°C accuracy guaranteeable (at +25°C)
• Rated for full -55° to +150°C range
• Suitable for remote applications
• Low cost due to wafer-level trimming
• Operates from 4 to 30 volts
• Less than 60 µA current drain
• Low self-heating, 0.08°C in still air
• Nonlinearity only ±¼°C typical
• Low impedance output, 0.1 Ohm for 1 mA load

7
2.1.1.2 LDR (Light Dependent Resistor)
Light Dependent Resistor (LDR) also known as photoresistor is an electronic
component whose resistance changes with the incident light intensity. It is made of a
high-resistance semiconductor. If light falling on the device is of high enough frequency,
photons absorbed by the semiconductor give
bound electrons enough energy to jump into
the conduction band. The resulting free
electron (and its hole partner) conduct
electricity, thereby lowering resistance.
The resistance of LDR may be 5000
ohm in daylight and 20000000 ohm in dark
condition.
Fig 2.2 LDR

Fig2.3: Characterstics curve of LDR Fig2.4: Typical Application circuit

8
2.1.2 Microcontroller (PIC18f4620)
We could have used different microcontroller such as 8051, AVR but we opted for
PIC family of microcontroller. It has the following advantages
1. It has high memory space.
2. It has built in ADC
3. It is developed using nanoWatt TECHNOLOGY that reduces power
consumption during operation.

We specifically choose PIC18f4620 because

1. It has large number of I/O pins.
2. It has 13 ten bits ADC channels which makes it easy for us to interface the
sensors.

Fig2.5: Pin Configuration of PIC18F4620

The PIC18f4620 has 5-ports. They are A, B, C, D, E. Port A, B, C, D are of 8-bits

in length but port E is of only 4-bits length. All these ports are in digital I/O besides A6

9
and A7. The oscillator is connected to these pins. The analog input pins are in
A0,A1,A2,A3,A5,E0,E1,E2,B0,B1,B2,B3,B4. The serial port data to the computer is
transmitted from C6 and received form C7. The serial data to the Ethernet chip is
transmitted from C5 and received from C4. If pin no. 1 is set to low the data memory of
microcontroller will be reset.

Features PIC18F4620
Operating frequency DC upto 40MHz
Program memory 64kb
Temporary data memory(Ram) (Approx.)4kb
Permanent data memory(EEPROM) 1kb
I/O Ports Ports A,B,C,D,E
Serial communication MSSP,USART
10-bits A/D Module 13 channels
Instruction sets 75 instruction

Table 2.1: Features of PIC18f4620

There are three types of memory in PIC18 Enhanced microcontroller devices:

•Program Memory
•Data RAM
•Data EEPROM

As Harvard architecture devices, the data and program memories use separate
busses; this allows for concurrent access of the two memory spaces. The data EEPROM,
for practical purposes, can be regarded as a peripheral device, since it is addressed and
accessed through a set of control registers.

10
 i. Program Memory
PIC18 microcontrollers implement a 21-bit
program counter, which is capable of addressing a 2-
Mbyte program memory space. Accessing a location
between the upper boundary of the physically
implemented memory and the 2-Mbyte address will
return all ‘0’s (a NOP instruction). PIC18F4620 have
64Kbytes of Flash memory and can store up to
32,768 single-word instructions. PIC18 devices have
two interrupt vectors. The Reset vector address is at
0000h and the interrupt vector addresses are at
0008h and 0018h. Writing or erasing program
memory will cease instruction fetches until the
operation is complete. The program memory cannot
be accessed during the write or erase, therefore, code
cannot execute. An internal programming timer
terminates program memory.

Fig2.6: Memory Organisation

ii. Data Memory
The data memory in PIC18 devices is implemented as static RAM. Each Register
in the data memory has a 12-bit address, allowing up to 4096 bytes of datamemory. The
memory space is divided into as many as 16 banks that contain 256 bytes each;
PIC18F4620 device implement all 16 banks. The data memory contains Special Function
Registers (SFRs) and General Purpose Registers (GPRs). The Special Function Registers
(SFRs) are registers used by the CPU and peripheral modules for controlling the desired
operation of the device. These registers are implemented as static RAM. SFRs start at the
top of data memory (FFFh) and extend downward to occupy the top half of Bank 15
(F80h to FFFh). GPRs are used for data storage and scratchpad operations in the user’s
application. The entire data memory may be accessed by Direct, Indirect or Indexed
Addressing modes.

11
iii. Data EEPROM
The data EEPROM is a nonvolatile memory array separate from the data RAM
and program memory that is used for long-term storage of program data. It is not directly
mapped in either the register file or program memory space but is indirectly addressed
through the Special Function Registers (SFRs). The EEPROM is readable and writable
during normal operation.

The EEPROM data memory is rated for high erase/write cycle endurance. A byte
write automatically erases the location and writes the new data (erase-before-write). The
write time is controlled by an on-chip timer; it will vary with voltage and temperature as
well as from chip to chip.

2.1.3 Ethernet chip (ENC28J60)

There are many Ethernet chip in the markets but we choose ENC28J60 because it
is produced from the same manufacturer as the PIC. Thus it is easier for us to interface
the two chips from microchip.

The ENC28J60 is a stand-alone Ethernet controller with an industry standard

Serial Peripheral Interface (SPI). It is designed to serve as an Ethernet network interface
for any controller equipped with SPI. The ENC28J60 meets all of the IEEE 802.3
specifications. It incorporates a number of packet filtering schemes to limit incoming
packets. It also provides an internal DMA module for fast data throughput and hardware
assisted IP checksum calculations. Communication with the host controller is
implemented via two interrupt pins and the SPI, with data rates of up to 10Mb/s. Two
dedicated pins are used for LED link and network activity indication.

With the ENC28J60, two pulse transformers and a few passive components are all
that is required to connect a microcontroller to a 10Mbps Ethernet network.The
ENC28J60 is designed to operate at 25MHz with a crystal connected to the OSC1 and
OSC2 pins.

The ENC28J60 does not support automatic duplex negotiation. If it is connected

to an automatic duplex negotiation enabled network switch or Ethernet controller, the

12
ENC28J60 will be detected as a half-duplex device. To communicate in Full-Duplex
mode, the ENC28J60 and the remote node (switch, router or Ethernet controller) must be
manually configured for full-duplex operation.

2.1.3.1 Ethernet Controller Features:

1. IEEE 802.3 compatible Ethernet controller
2. Receiver and collision squelch circuit
3. Supports one 10BASE-T port with automatic polarity detection and correction
4. Supports Full and Half-Duplex modes
5. Programmable automatic retransmit on collision
6. Programmable padding and CRC generation
7. Programmable automatic rejection of erroneous packets
8. SPI Interface with speeds up to 10Mb/s

2.1.3.2 Ethernet Controller Block Diagram

Fig2.7: Detail Overview of ENC28J60

13
The ENC28J60 consists of seven major functional blocks:
1. An SPI interface that serves as a communication channel between the host controller
and the ENC28J60.
2. Control Registers which are used to control and monitor the ENC28J60.
3. A dual port RAM buffer for received and transmitted data packets.
4. An arbiter to control the access to the RAM buffer when requests are made from DMA,
transmit and receive blocks.
5. The bus interface that interprets data and commands received via the SPI interface.
6. The MAC (Medium Access Control) module that implements IEEE 802.3 compliant
MAC logic.
7. The PHY (Physical Layer) module that encodes and decodes the analog data that is
present on the twisted pair interface.

The device also contains other support blocks, such as the oscillator, on-chip voltage
regulator, level translators to provide 5V tolerant I/Os and system control logic.

Fig2.8: Pin Configuration of ENC28J60

14
 Fig2.9: Typical Application Circuit of Ethernet Chip

All memory in the ENC28J60 is implemented as static RAM. There are three
types of memory in the ENC28J60:

•Control Registers
•Ethernet Buffer
•PHY Registers

The control registers’ memory contains Control Registers (CRs). These are used
for configuration, control and status retrieval of the ENC28J60. The Control Registers are
directly read and written to by the SPI interface.The Ethernet buffer contains transmit and
receive memory used by the Ethernet controller in a single memory space. The sizes of
the memory areas are programmable by the host controller using the SPI interface. The
Ethernet buffer memory can only be accessed via the read buffer memory and write buffer
memory. The PHY registers are used for configuration, control and status retrieval of the
PHY module. The registers are not directly accessible through the SPI interface; they can
only be accessed through the Media Independent Interface (MII) implemented in the
MAC.

15
 Fig 2.10: Memory Organization of ENC28J60

i. Control Registers
The Control Registers provide the main interface between the host
controller and the on-chip Ethernet controller logic. Writing to these registers controls the
operation of the interface, while reading the registers allows the host controller to monitor
operations. The Control Register memory is partitioned into four banks. Each bank is
32bytes long and addressed by a 5-bit address value. The last five locations (1Bh to 1Fh)
of all banks point to a common set of registers: EIE, EIR, ESTAT, ECON2 and ECON1.
These are key registers used in controlling and monitoring the operation of the device.

16
 ii. Ethernet Buffers
The Ethernet buffer contains transmit and receive memory used by the
Ethernet controller. The entire buffer is 8Kbytes, divided into separate receive and
transmit buffer spaces. The sizes and locations of ransmit and receive memory are fully
programmable by the host controller using the SPI interface.

iii. PHY Registers

The PHY registers provide configuration and control of he PHY module, as
well as status information about its operation. All PHY registers are 16 bits in width.
There are a total of 32 PHY addresses; however, only 9 locaions are implemented. Writes
to unimplemented locations are ignored and any attempts to read these locations will
return ‘0’. All reserved locations should be written as ‘0’; their contents should be ignored
when read. Unlike the control registers or the buffer memory, the PHY registers are not
directly accessible through the SPI control interface. Instead, access is accomplished
through a special set of MAC control registers that implement a Media Independent
Interface for Management (MIIM).

17
2.1.4Magnetic Ethernet jack

Magnetic Ethernet jack is a single port shielded RJ45 connector with integrated
10/100 magnetic.

Fig 2.11: Magnetic Ethernet Jack

Fig2.12: Schematics of Magnetic Ethernet Jack

18
2.1.5 Serial port interfacing

A serial port is a serial communication physical interface through which

information transfers in or out one bit at a time (contrast parallel port). Throughout most
of the history of personal computers, data transfer through serial ports connected the
computer to devices such as terminals and various peripherals. Such interfaces are
Ethernet, FireWire, and USB all send data as a serial stream, the term "serial port" usually
identifies hardware more or less compliant to the RS-232 standard, intended to interface
with a modem or with a similar communication device.

Serial ports can also be found in industrial automation systems, scientific analysis,
and some industrial and consumer products. Network equipment (such as routers and
switches) often have serial ports for configuration. Serial ports are still used in these areas
as they are simple, cheap and allow interoperability between devices.

2.1.5.1 Serial (RS232) port interface pin out and signal

RS232 DB9 pinout

Fig 2.13: Serial (RS232) Port Interface Pin Out and Signal

19
 9 pin# Abbreviation Full Name
Pin 3 TD Transmit Data
Pin 2 RD Receive Data
Pin 7 RTS Request To Send
Pin 8 CTS ` Clear To Send
Pin 6 DSR Data Set Ready
Pin 5 SG Signal Ground
Pin 1 CD Carrier Detect
Pin 4 DTR Data Terminal Ready
Pin 9 RI Ring Indicator

Table 2.2: Showing the RS232 pin configuration and signals

2.1.5.2 RS-232 Level Converters

Almost all digital devices which we use require either TTL or CMOS logic levels.
Therefore the first step to connecting a device to the RS-232 port is to transform the RS-
232 levels back into 0 and 5 Volts. As we have already covered, this is done by RS-232
Level Converters.

MAX232 is a RS232 level converter. It includes a Charge Pump, which generates

+10V and -10V from a single 5V supply. This I.C. also includes two receivers and two
transmitters in the same package. This is handy in many cases when we only want to use
the Transmit and Receive data Lines. Necessity of two chips, one for the receive line and
one for the transmit line is not required.

20
Fig 2.14: Pin configuration of MAX232 Fig 2.15: Typical MAX-232 circuit

However all this convenience comes at a price, but compared with the price of
designing a new power supply it is very cheap. There are also many variations of these
devices. The large values of capacitors are not only bulky, but also expensive. Therefore
other devices are available which use smaller capacitors and even some with inbuilt
capacitors.

21
2.1.6 LCD
A liquid crystal display (LCD) is a thin, flat display device made up of any
number of color or monochrome pixels arrayed in front of a light source or reflector

PIN NO. SYMBOL FUNCTIONS

1 Vss 0 volts
2 Vcc 5 volts
3 Vee
4 RS Low=instruction code input
High=data input
5 R/W High=data read
Low=data write
6 E High to low =Enable signal
7 DB0
8 DB1
9 DB2
10 DB3
11 DB4 Data bus line
12 DB5
13 DB6
14 DB7
15 LED +
16 LED -

Table 2.3: Pin connections of LCD

2.1.7 LAN connectivity

Our device can be connected to a LAN either through a wired Ethernet cable or
through a wireless Wi-Fi access point/transmitter.

2.2 SOFTWARE COMPONENT OVERVIEW

Our project comprises of following software components:

• TCP/IP Stack

22
 • C language
• Web/Database server
• PHP
• Proteus simulation software

2.2.1 TCP/IP STACK

Many TCP/IP implementations follow a software architecture referred to as the
“TCP/IP Reference model”. Internet Software based on this model is divided into
multiple layers, where layers are stacked on top of each other (thus the name “TCP/IP
Stack”) and each layer accesses services from one or more layers directly below it.

TCP/IP Reference Model Our TCP/IP Model

Fig2.16: Comparing our TCP/IP Model with the TCP/IP Reference Model

23
 Like the TCP/IP reference model, our TCP/IP Stack divides the TCP/IP Stack into
multiple layers. The code implementing each layer resides in a separate source file, while
the services and APIs (Application Programming Interfaces) are defined through
header/include files. Unlike the TCP/IP reference model, many of the layers in our
TCP/IP Stack directly access one or more layers which are not directly below it. A
decision as to when a layer would bypass its adjacent module for the services it needs, is
made primarily on the amount of overhead and whether a given service needs intelligent
processing before it can be passed to the next layer or not.

An additional major departure from traditional TCP/IP Stack implementation is

the addition of two new modules: “StackTask” and “ARPTask”. StackTask manages the
operations of the stack and all of its modules, while ARPTask manages the services of the
Address Resolution Protocol (ARP) layer.

To identify an individual computer on the Internet, it must have a unique address.

The current version of the Internet Protocol (IPv4) uses a four-byte number, expressed in
dotted decimal notation, (e.g., 123.45.67.8). This address consists of three parts.
1. A network address, which uniquely identifies an organization.
2. A subnet address, which identifies a subnet within that organization.
3. A system address, which identifies a single node on that subnet.

The size of these fields varies, depending on the size of the organization, but they
must occupy a total of four bytes.

2.2.1.1 Stack Modules

Following are some of the stack modules and API used.

a. MAC (Media Access Control Layer):

The Ethernet hardware doesn't understand IP addresses; it has its own addressing
scheme based on a unique six-byte address for each network adaptor manufactured;
this is generally called the media access and control (MAC) address.

24
 b. ARP & ARPTASK (Address Resolution Protocol)
The IP-to-hardware address translation protocol is called address resolution
protocol (ARP). A node sends a subnet broadcast containing the IP address that is
to be resolved, and the node that matches that IP address sends a response with its
hardware address.

c. IP (Internet Protocol)
The first software layer above the network drivers is IP and its partner ICMP.
Above these, there is a split: connection-oriented applications use transmission
control protocol (TCP), whereas connectionless applications use user datagram
protocol (UDP). An IP packet is known as a "datagram”.

d. ICMP (Internet Control Message Protocol)

ICMP is an adjunct to IP that gives all nodes on the network the ability to perform
simple diagnostics and return error messages. For example, if you ask a router to
forward a datagram to an address it can't reach, it will return an ICMP "destination
unreachable" message. ICMP messages are contained within the data field of a IP
datagram using IP protocol number.

e. TCP (Transmission Control Protocol)

TCP helps to do several jobs at once. It initiates a connection between two nodes
and sends data bidirectionally between those two nodes. It handles the network
failure, network datagram loss. It closes the connection between those two nodes as
well.

f. HTTP (Hyper Text Transmission Protocol)

HyperText Transfer Protocol (HTTP) simply involves an exchange of text messages
followed by the transfer of Web data down a TCP connection.

To fetch a Web document, the browser opens a TCP connection to server port 80, and
then uses HTTP to send a request. Compared to TCP, HTTP is refreshingly simple:

25
the request and response are one or more lines of text, each terminated by the
newline (carriage return, line feed) characters. If the request is successful, the
information (document text, graphical data) is then sent down the same connection,
which is closed on completion.

HTTP commands are called methods; the one used to fetch documents is the get
method.

Table2.4: Request For Comment

The complete list of Internet RFCs and the associated documents are available on
many Internet web sites. Interested readers are referred to www.faqs.org/rfcs
and www.rfc-editor.org as starting points.

26
 2.2.2 “C” language with MCC18 compiler
The C language compiler/linker used by us was the MCC18 of microchip. The
IDE used by us was the MPLAB of microchip.

Components of the C language such as comment definition, constants definition,

variable definition, function declaration, operator’s usage, program control statements,
arrays, strings, pointers, structures, and unions are similar to the ANSI C standards.

Some of the keywords used in the MCC18 language are shown in table.

_asm Extern Short

_endasm Far Signed
Auto Float Sizeof
Break For Static
Case Goto Struct
Char If Switch
Const Int Typedef
Continue Long Union
Default Near Unsigned
Do Ram Void
Double Volatile Else
Return While Enum

Table 2.5: Keywords of MCC18

The processor-specific library files contain definitions that may vary across
individual members of the PIC18 family. This includes all of the peripheral routines and
the Special Function Register (SFR) definitions. The peripheral routines that are provided
include both those designed to use the hardware peripherals and those that implement a
peripheral interface using general purpose I/O lines. The functions included in the
processor-specific libraries include Hardware Peripheral Functions and. Software
Peripheral Library.

27
Advantages of C language in embedded systems:
1. It is easier to code and requires less effort.
2. It has many built in functions

Disadvantages of C language in embedded systems:

1. It occupies more memory space.
2. It is inconvenient for time critical applications.

2.2.3. Web/Database server

MySQL is a multithreaded, multi-user SQL database management system
(DBMS). The basic program runs as a server providing multi-user access to a number of
databases.

Libraries for accessing MySQL databases are available in all major programming
languages with language-specific APIs. In addition, an ODBC interface called MyODBC
allows additional programming languages that support the ODBC interface to
communicate with a MySQL database, such as ASP or ColdFusion. The MySQL server
and official libraries are mostly implemented in ANSI C/ANSI C++.

MySQL is popular for web applications and acts as the database component of the
LAMP, MAMP, and WAMP platforms (Linux/Mac/Windows-Apache-MySQL-
PHP/Perl/Python), and for open-source bug tracking tools like Bugzilla. Its popularity for
use with web applications is closely tied to the popularity of PHP and Ruby on Rails,
which is often combined with MySQL

28
 2.2.4 PHP (PHP: Hypertext Preprocessor)
PHP is a widely-used general-purpose server side scripting language that is
especially suited for Dynamic Web development and can be embedded into HTML. PHP
generally runs on a web server, taking PHP code as its input and creating Web pages as
output. However, it can also be used for command-line scripting and client-side GUI
applications. PHP can be deployed on most web servers and on almost every operating
system and platform free of charge. The PHP Group also provides the complete source
code for users to build, customize and extend for their own use.

PHP primarily acts as a filter. The PHP program takes input from a file or stream
containing text and special PHP instructions and outputs another stream of data for
display.

There are eight data types in PHP which facilitates the programmer are:
Integer, Double, Boolean, String, Object, Array, Null, Resource

PHP has a formal development manual that is maintained by the free software
community. In addition, answers to many questions can often be found by doing a simple
internet search.

CGI
The Common Gateway Interface (CGI) is a standard protocol for interfacing
external application software with an information server, commonly a web server. The
task of such an information server is to respond to requests (in the case of web servers,
requests from client web browsers) by returning output. Each time a request is received;
the server analyzes what the request asks for, and returns the appropriate output. The two
simplest ways, for the server, of doing this are the following:

 if the request identifies a file stored on disk, return the contents of that file;
 if the request identifies an executable command and possibly arguments, run the
command and return its output

29
 CGI defines a standard way of doing the second. It defines how information about
the server and the request is passed to the command in the form of arguments and
environment variables, and how the command can pass back extra information about the
output (such as the type) in the form of headers.

Whenever a request to a matching URL is received, the corresponding program is

called, with any data that the client sent as input. Output from the program is collected by
the Web server, augmented with appropriate headers as defined by the CGI spec, and sent
back to the client.

The information regarding physical parameters is sensed from the sensor. This is
received by microcontroller and is stored in CGI variables. These CGI variables can be
accessed by CGI scripts running in web/database server. The data are stored in the
MySQL database. Finally the required graphical representation of the data can be
displayed interactively in the website.

30
 2.2.5 Proteus: Simulation Software
Proteus is circuit simulation software. Its demo version can be downloaded from
www.labcenter.co.uk for free. Proteus consists of 2 major software parts. They are ISIS
and ARES. ISIS is a simulation package whereas ARES is a PCB making package. The
Proteus Design Suite is wholly unique in offering the ability to co-simulate both high and
low-level micro-controller code in the context of a mixed-mode SPICE circuit simulation.
If one person designs both the hardware and the software then that person benefits as the
hardware design may be changed just as easily as the software design. In larger
organisations where the two roles are seperated, the software designers can begin work as
soon as the schematic is completed; there is no need for them to wait until a physical
prototype exists. In short, Proteus VSM improves efficiency, quality and flexibility
throughout the design process.

Proteus VSM for PIC18 contains everything we need to develop, test and virtually
prototype our embedded system designs based around the Microchip Technologies PIC18.
The unique nature of schematic based microcontroller simulation with Proteus facilitates
rapid, flexible and parallel development of both the system hardware and the system
firmware.

In this software we simulated most of our project circuits and codes including the
ENC28J60 and PIC18F4620 interconnection and the C language code.

31
 CHAPTER 3
METHODOLOGY

32
 3.1 HARDWARE DESIGN IMPLEMENTATION

3.1.1 PIC Programmer Circuit

Fig3.1: Complete Circuit Diagram of the PIC18 Programmer

(Ref: http://www.ucapps.de/mbhp_burner.html)

For loading the .HEX file in the PIC we used the provided P18 software.

We searched for various programmers circuits and designed in breadboard. But all
circuits failed. Finally we got above circuit, which worked fine. It was really great to find
the programmer circuit working fine. Then we started to deal with PIC18F4620. We did
some basic programs like LED blinking, LCD display, ADC port programming, etc. Then
we stepped toward sensor interfacing and Ethernet interfacing.

33
 3.1.2 Sensor interfacing

Fig3.2: Sensor Interfacing with PIC18F4620

LM 35 is connected to the analog port of the PIC18F4620 microcontroller. As we

know the PIC18F4620 has 13 analog pins which can also function as digital I/O. Before
the sensor is connected to one of these pins, the PIC18F4620 must first be configured to
accept analog data on the specified pins. Only then is the data from the sensor considered
to be valid. The PIC18F4620 then changes the analog data to 10 bits and stores it in it’s
registers ADRESH:ADRESL which will contain the value of the last completed
conversion.

34
 3.1.3 LCD interfacing

Fig3.3: LCD Interfacing with PIC18F4620

The MCC18 functions are designed to allow the control of a Hitachi HD44780
LCD controller using I/O pins from a PIC18 microcontroller. The LCD we used in this
project was JHD162A series from ETC corporation. The LCD could be used in 4 bit or 8
bit mode. The 4 bit mode saves pins in the microcontroller but requires more processing
time and makes the pic18f4620 slower for other functions. Thus we used the 8 bit mode.
We used the LCD to display the IP address of the microcontroller and the current sensor
value.

35
 3.1.4 RS-232 interfacing

Fig3.4: Serial Interfacing with PIC18F4620

The PIC18F4620 has 2 serial ports modules the USART (Universal synchronous
and asynchronous receiver and transmitter) and the MSSP (master synchronous serial
port) module. We used the USART module for interfacing with the RS232 port of the
computer. The computer is used only for debugging purposes and is not totally necessary
for operation of the weather box.

#include <p18f4620.h>
#include <usart.h>
void main(void)
{
// configure USART
OpenUSART( USART_TX_INT_OFF & USART_RX_INT_OFF &
USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX
& USART_BRGH_HIGH, 25 );
while(1)
{
while( ! PORTAbits.RA0 ); //wait for RA0 high
WriteUSART( PORTD ); //write value of PORTD
if(PORTD == 0x80) // check for termination
break; // value
}
CloseUSART();
}

36
 3.1.5 Ethernet chip interfacing

Fig3.5: Interfacing ethernet chip

Communication with the host controller is implemented via two interrupt pins and
the SPI, with data rates of up to 10Mb/s. Two dedicated pins are used for LED link and
network activity indication. The following pins are also used:

SCK = Serial Clock

SI = Serial In
SO = Serial Out
INT = Interrupt (general)
WOL = Interrupt (Wake On LAN)

The INT and WOL pins are used to interrupt the microcontroller from the ethernet
chip. The INT pin of the ethernet chip is conencted to the INT0 of PIC18F4620 and the
WOL pin is connected to the INT1 pin of PIC18F4620.

37
 We performed level conversion because the microcontroller operates at 5V TTL
level while the ethernet chip operates at 3.3V CMOS level. The level conversion was
done using 74HCT08 (quad AND gate).

3.1.6 Complete Circuit Design

Fig3.6: Schematic Diagram of PIC Interfacing (Designed using Proteus v.7.1)

The 2 LEDs are added in the ENC28J60 for debugging purposes. The
green LED signifies that a network conenction is available and the red led
indicates that the network is ready to accept and transmit messages and packets.
The LCD and the computer connected through the RS 232 is not needed for the
operation of the device. The ethernet chip is connected to the ethernet cable by a
RJ45 with magnetics included and a ferrite bead to reduce high frequency EM
interference. The sensor is connected to the ANO and AN1 pins.

38
 3.2 SOFTWARE DESIGN IMPLEMENTATION

3.2.1 TCP/IP Implementation

Our stack is a collection of different modules. Some modules (such as IP, TCP,
UDP and ICMP) must be called when a corresponding packet is received. Any application
utilizing our stack must perform certain steps to ensure that modules are called at the
appropriate times. This task of managing stack modules remains
the same, regardless of main application logic.

In order to relieve the main application from the burden of managing the
individual modules, our TCP/IP Stack uses a special application layer module known as
“StackTask”, or the Stack Manager. This module is implemented by the source file
“StackTsk.c”. StackTask is implemented as a cooperative task; when given processing
time, it polls the MAC layer for valid data packets. When one is received, it decodes it
and routes it to the appropriate module for further processing.

It is important to note that Stack Manager is not an integral part of our TCP/IP
Stack. It is written so that the main application does not have to manage stack modules, in
addition to its own work such as RS-232, LCD, and Sensor interfacing. Before the Stack
Manager task can be put to work, it must be initialized by calling the StackInit( ) function.
This function initializes the Stack Manager variables and individual modules in the
correct order. Once StackInit( ) is called, the main application must call the StackTask( )
function periodically, to ensure that all incoming packets are handled on time, along with
any time-out and error condition handling.

39
The exact steps used by StackTask are shown in the algorithm below.

If a data packet received then

Get data packet protocol type
If packet type is IP then
Fetch IP header of packet
Get IP packet type
If IP packet type is ICMP then
Call ICMP module
Else if IP packet type is TCP then
Call TCP module
Else if IP packet type is UDP then
Call UDP module
Else
Handle not supported protocol
End If
End If
Else if packet type is ARP then
Call ARP module
End If

Thus the protocols supported by our project are MAC, ARP, IP, TCP, UDP, ICMP,
and HTTP. The FTP, DHCP and other protocols such as SLIP are not supported. The
absence of DHCP implementation in our project causes the IP address of the
microcontroller to be fixed and unable to be changed by the network server.

40
For example the stack manager operations concerning the ICMP packets transmission and
reception is shown and described below.

SM=ARP SM=TCP

SM= Stack Manager FT = Frame Type

Fig 3.7: Flow chart of TCP/IP Implementation (For ICMP only)

First of all SM is set to idle. Then the SM enters in the MAC module. The status
of SM gets changed to either ARP or IP. Then the frame type is checked if that of ARP or
IP. If IP then status is changed to ICMP and SM enters into ICMP module. Again frame
type is checked. If frame type is ICMP (say), then SM is changed to ICMP (say). If
SM=ICMP, then the SM enters ICMP module, to handle the ICMP task.

41
3.2.2Web/Database Server
Our module is an IP enabled device. Now if a public IP if provided to it, it can
definitely be accessed through the internet. But being an eight bit microcontroller it would
not be able to serve thousands of possible requests from the public domain. Also any
hacker wanting to crash our system can generate large no of requests that our module
cannot handle. In order to address this problem and to manage readings of different
weather variables, the essence of a Web/database server is inevitable.

For our demonstration purpose we assign IP of our module to be 192.168.11.5 and

the IP of the central web/database server was assigned to be 192.168.11.2 (192.168.11.X,
where X is any value in between 1 to 255 but not equal to 5), both connected to same
router. Also connecting these two via a lab link cable or the cross wire cable, with data
transfer rate set to be 10Mbps in half duplex mode equally worked.

Now the challenging task was to send a request to our module at a constant
interval, retrieve the data, store it in a managed way, and show a graphical representation
of data according to the request at the time of request.

The first problem of repeated query to our module at a constant interval was
solved using the META tag in the PHP page which sends a request to our module. There
was code in that very same page which would read the CGI page, “status.cgi”, stored in
our module. META tag was in such a way that it recursively called the page itself. Now
for our demonstration purpose we called our page at an interval of one minute.

The second problem of retrieving of data was done using the string operation. The
page “status.cgi” in our module was written in such a way that we have kept certain
tokens that would help to extract the required readings from the total contents of file.
Firstly we read the whole contents of the file and stored it in a string. Then using few
string operations, taking into consideration of the token we have kept, the readings were
retrieved and stored in variables for further processing.

42
 Third problem was to store the retrieved value in a manageable way. For that as
mentioned we use MySQL database. Before storing we also need to consider the time at
which the reading has been taken. For that we use the built in function of PHP, ‘date( )’.
Usage of the function was to be done in proper consent. We were storing the retrieved
data, weather variables, in such a way that ‘year’, ‘month’, ‘day’, ‘hour’ and ‘minute’
were also the field of table. From this function we extracted all these fields and stored it
in different variables. And along with the weather readings, these were also stored in the
table.

Last but not least we need to represent those data in the graphical format. The
main challenging task was to represent the data as according to the user request. Here
users can send requests to view the plot in an hourly basis or daily basis as well. So, if we
were to average the data at the fly time (request time), it would be definitely be an idiotic
task. Let’s say a user requested to view the average temperature on a yearly basis in order
to have an idea of impact of global warming, at the place where our module is kept for
monitoring. Here for each reading to be plotted we need to average 525600(=365*24*60)
readings because we were taking readings at an interval of one minute. Now in order to
address this problem what we did was we created five tables. When the data was being
written in the main table, we were checking the values of the ‘date’ parameters. The value
of minute to be 00 indicates that the hour has been incremented by one. At that very
instant we would read the last 60 rows of data from the main table in order to calculate
the average value of the readings of that particular hour and then store it in the new table
where the minute field is not present as it was in the main table. Similarly, the value of
hour to be 00 indicated the change of day, which in turns leads to calculate the average
reading of that day from the ‘hour’ table and store in the day table where field are only
‘year’, ‘month’ and ‘day’ including the weather variables. In the similar manner two more
tables for month and year were also maintained.

This finally led us to have proper data which is to be used to show the proper
graph as requested by user in the public domain. For the purpose of plotting of graph we
use gd_2 library of PHP.
The sample of user interface and the graph plotted using random data for
temperature is as shown in the ‘fig e’ and ‘fig f’ respectively.

43
CHAPTER 4
EPILOGUE

44
 1

4.1 PROJECT TIMELINE

The project passed through all the phases: Research, Analysis, Design (Simulation
and Hardware), Testing and Maintenance and Documentation. The Gantt chart of our
project is shown below.

OCT OCT NOV NOV DEC DEC JAN JAN FEB

Events / Time (1- (15- (1- (15- (1- (15- (1- (15- (1-
15) 30) 15) 30) 15) 30) 15) 30) 15)
Research &
Analysis
Sponsorship
Material Order
Simulation
7Design
Hardware
Design
Testing &
Maintenance
Documentation

Fig4.1: Gantt chart: “IP Based Weather Station: Mausam Parisuchak” 2007-2008

4.2 PROJECT COST ANALYSIS

s/n Hardware requirements Specifications Quantity Rate $ Total $

1 Sensors
a. Temperature Sensor LM35 1 1.50 1.50
b. LDR 1 0.25 0.25
2 Ethernet Controller ENC28J60 1 6.25 6.25
3 RJ45 JACK J1006FOIT 1 8.00 8.00
4 Microcontroller PIC18F4620 1 7.75 7.75
5 LCD HD7740 family 1 4.47 4.47
6 Miscellaneous Resistors,buffers,etc. 10
TOTAL MODULE COST 38.22

6 Wi-Fi transreceiver From ICIMOD 1

7 PV panels From CES,IOE 1
Table 4.1: Financial Details of Hardware Requirements for single module (1$=63 NRS)

45
Thus the total weather module cost is approximately 2,400 /- NRs.

46
 4.3 FUTURE ENHANCEMENTS

This project is flexible and efficient for the proper remote monitoring of the
remote area, and thus can be implemented as Advanced Remote Data Logger. With the
addition of many weather sensors, it can give the data of various parameters.

Solar Panel can be added on our module so that it can behave as independent unit
and can be mounted in the remote area without any external power supply.

4.4 APPLICATIONS OF THE PROJECT

With the advancement of today’s technology only logging of data is not sufficient.
But the availability of data in the usable form for the real time application is most
important. This is what incorporated in our project.

With the feature of real time avialability our aim is to provide the unmanned
weather station. Where sensing and recording of data are done automatically and also
that the data are tabulated properly in modern database system () which further enhances
the usability of data recorded.

In botanical studies for example in the green house the regular monitoring of
data is an important and tidious task and with aid of our project this can be done quite
easily and efficiently. It also provides references for futher experiments as data are kept in
the managed way in the modern databse.

Temperature and humidity monitoring in airport is also an important and critical

task where too our project can be utilized.

In the industrial plants as well, our project can be used to monitor different
physical parameters which in turns help to analyse the performance to different

47
sophisticated machines and also predefined premitive measures can be carried out to
prevent disasters.

Knowing different weather parameters of climate of Snowy Mountain is an

essential factor for development of mountain tourism in the country like Nepal. Small
variations of weather parameters for small period can contain vital information thus
implementing our project help to address those types of cases as well.

4.5 PROBLEMS FACED

Where there is a gravel road, it is easy to be paved; but if there is no road, then to
construct a paved road, is even more difficult. This was the problem we faced when we
chose to implement a web server in a microcontroller. For days we searched in the library
for a similar project being undertaken by our seniors but could not get a single one.

Next step in our project was to select the adequate hardware. Here we receive the
nightmare of problems. Some major components of our project were not avialable in the
local market so we needed to get them from the manufacturers abroad. Also the cost of
attaining each component was far too behind our budget as we need to get more than one
complete set of components, because in course of our working process the probability of
getting components damaged cannot be ignored. And also that we cannot complain the
manufacturer if we received any damaged piece. Time was another important factor. We
need to order components by keeping adequate time margin that we have enough time for
succesful completion of our project.

For the solution of this problem we decided to search for the places where our
project could be implemented and that we could get mutual benifits. ICIMOD was the
organisation toward whom we should be grateful for reliefing us from entangling in such
a mess by providing us supports and encouragements.

Since PIC18F series was unfamiliar to our friends and seniors as well. We also
need to work hard on getting appropriate programmers. With dedicated hard work and

48
searching procedures we were able to accumulate a couple programmer circuits
schematics but could not get a working one on our table. But eventually we got one.

The code for microcontroller was to be written using C language. But the working
environment of MPLAB was quite different and we do need to work hard to get
familiarize with.

Directly testing our codes on the hardware module could result in the devastating
effects. So we need to have proper simulation software for that purpose. But to get the
relevent and reliable simulation software which provide the facility of simulating our
components and that to free was really a tough job. But newer release of proteus solved
our problem.

Though simulation helps in providing a dirction to a project but never is an exact relica of
overall project. For days we get frustrated as our task use to be done on the simulation but
not on the hardware. On successful completion of the design on Proteus Simulation we
implemented the design in the hardware. On the course of hardware design we faced
various problems. Since our Ethernet chip worked at 3.3 V and PIC18F4620 at 5V, we
have to take care of voltage level conversion in our design which is taken care by using
AND gate as 3.3V to 5V logic shifter. Since we need to work at higher frequency 20
MHz, we also need to consider high frequency design as well. For this we used ferrite
bead, twisted pair cable, decoupling capacitors, proper alignement of active and passive
components etc.Thus we can say gradual debugging and reconnenting components taking
in account of knowledge gain in the course of instrumentation II really become a fruitfull.

49
 4.6 CONCLUSION

The project entitled “IP based weather station: MAUSAM PARISUCHAK”

undertaken by us consists of 3 major portions: the sensors, the microcontroller, and the
Ethernet chip which is used to connect to a LAN. It includes the 3 concepts: embedded
systems, TCP/IP communication, and a weather station. It provides real time data of
weather in remote/inaccessible locations through a wireless /wired connection.

The module built in our project acts as a web server and displays the sensor data
in the form of web pages. This module finds its practical implementation in the remote
mountainous area of Nepal which can provide data through the internet either by a series
of microwave links or satellite links.

We would like to thank all those who have supported us. We would also like to
thank the teachers and our supervisors for providing us the needed support. Finally the
support of ICIMOD is also highly appreciated.

50
REFERENCES

1. www.microchip.com
2. www.labcenter.co.uk
3. TCP/IP lean- Web servers for Embedded Systems by Jeremy Bentham
4. Microprocessors and Interfacing by Douglas V Hall

and many more blogs

51
ANNEX

Fig a: Snapshot of Simulation on Proteus

52
Fig b: Snapshot of C Programming in MPLAB IDE

53
Fig c: Snapshot of the Project Work done in ProtoBoard

54
Fig d: Snapshot of the PIC Programmer built in ProtoBoard

55
 Fig e: Interface designed in PHP for the public domain users

Fig f: Graph designed in PHP for public domain users as per request.
Note: this graph is created from random data

56
Fig g: Our module in PCB

57