1 INTRODUCTION



CHAPTER 1

INTRODUCTION

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.

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.

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.

CHAPTER 2

LITERATURE REVIEW

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.

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 |

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

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.

[pic]

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 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.

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.

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.

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 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

[pic]

Fig2.7: Detail Overview of ENC28J60

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.

[pic]

Fig2.8: Pin Configuration of ENC28J60

[pic]

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.

[pic]

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.

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).

2. Magnetic Ethernet jack

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

[pic]

Fig 2.11: Magnetic Ethernet Jack

[pic]

Fig2.12: Schematics of Magnetic Ethernet Jack

4 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.

1 Serial (RS232) port interface pin out and signal

RS232 DB9 pinout

[pic]

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

|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 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.

[pic][pic]

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.

5 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 | |

| | | |

| | | |

| | |Data bus line |

|8 |DB1 | |

|9 |DB2 | |

|10 |DB3 | |

|11 |DB4 | |

|12 |DB5 | |

|13 |DB6 | |

|14 |DB7 | |

|15 |LED + | |

|16 |LED - | |

Table 2.3: Pin connections of LCD

6 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

• 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

[pic]

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

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.

2 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.

3 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.

4 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”.

5 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.

6 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.

7 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: 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.

[pic]

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 rfcs

and rfc- as starting points.

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.

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.

10 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

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

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.

2.2.5 Proteus: Simulation Software

Proteus is circuit simulation software. Its demo version can be downloaded from 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.

CHAPTER 3

METHODOLOGY

3.1 HARDWARE DESIGN IMPLEMENTATION

3.1.1 PIC Programmer Circuit

[pic]Fig3.1: Complete Circuit Diagram of the PIC18 Programmer

(Ref: )

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.

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.

3.1.3 LCD interfacing

[pic]

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.

3.1.4 RS-232 interfacing

[pic]

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

#include

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();

}

3.1.5 Ethernet chip interfacing

[pic]

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.

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

[pic]

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.

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.

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.

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

[pic]

SM= Stack Manager FT = Frame Type

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.

23 Web/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.

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.

CHAPTER 4

EPILOGUE

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.

|Events /|OCT (1-15) |OCT (15-30) |NOV (1-15) |NOV (15-30) |DEC (1-15) |

|Time | | | | | |

|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) |

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

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 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 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.

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.

References

1.

2. 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

ANNEX

[pic]

[pic]

[pic]

Fig c: Snapshot of the Project Work done in ProtoBoard

[pic]

Fig d: Snapshot of the PIC Programmer built in ProtoBoard

[pic]

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

[pic]

Fig f: Graph designed in PHP for public domain users as per request.

Note: this graph is created from random data

[pic]

Fig g: Our module in PCB

-----------------------

SM=ARP

SM=TCP

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

Fig3.5: Interfacing ethernet chip

Fig 2.1: LM35 connection circuit

Fig b: Snapshot of C Programming in MPLAB IDE

Fig1.1: Simplified Diagram of Component Interconnections

Fig a: Snapshot of Simulation on Proteus

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download