Page I

Device Control using Embedded based web server

Group Members:

Muhammad Shirjeel Shehzad 2K9-EE-201

Junaid Ahmad 2K9-EE-240

Tariq Yasin 2K9-EE-246

Haris Ali 2K9-EE-250

Project Advisor

(Engr. Omer Mushtaq)

Department of Electrical Engineering

NFC Institute of Engineering & Technology Multan,

Pakistan

August 2013

Page II

Embedded based web server

Department of Electrical Engineering

NFC Institute of Engineering & Technology Multan, Pakistan

The project “Device Control using Embedded based web server”

presented by:

Mohammad Shirjeel 2K9-EE-201

Junaid Ahmad 2K9-EE-240

Tariq Yasin 2K9-EE-246

Haris Ali 2K9-EE-250

Under the supervision of their project advisor and approved by the project

Examination committee, has been accepted by the NFC Institute of Engineering &

Technology, in partial fulfillment of the requirements for the four year Degree of

B.Sc. (Electronics Engineering).

__________________________

(Engr. Omer Mushtaq) (Dr. Abdul Sattar Malik)

Internal Examiner Assistant Professor,

UCE & T, B.Z.U Multan

(Dr. Kamran Liaqat Bhatti)

Head, Department of Electrical Engineering

Page III

Dedication

This project work has been dedicated to our beloved parents and teachers who

inspired us to higher ideas of life.

Without their patience, understanding, support, guidance and most of all their

affection, the completion of this work would not have been possible.

Page IV

Acknowledgement

“Being good is commendable, but only when it is combined with doing well is it

useful”

All praise for ALLAH Almighty who guides us in lacerate and congenial

circumstances and whose mercy and help is the pinnacle of our desires and wishes.

All respect for His Prophet Hazrat Muhammad (PBUH) who showed us the path of

knowledge. We pay our thanks and sincere appreciation to our advisor Engr. Omer

Mushtaq for his direction, guidance and support during the whole project session. He

always made himself available to help and encourage us whenever we needed.

Our special thanks to Dr. Akhter Malik Karlo Vice Chancellor NFC IET) for his

direction and expertise. We got through many difficulties due to his scholarly

guidance. Without his cooperation we would not have been able to make our project

work.

We wish to offer our sincere and deepest gratitude to our parents and other family

members for their inspiration and moral support throughout our project. We would

also like to pay thanks to our friends and colleagues for encouragement and

worthwhile suggestions.

Page V

List of contents

List of figures

Abstract Contents

Table of Contents

1.1 History INTRODUCTION .................................................................................................... 1

1.2 Introduction ............................................................................................................................ 2

1.2.1 Everyday appliances with web servers ............................................................................... 3

1.3.1 Ethernet open source project for building Ethernet devices .............................................. 6

1.3.2 Device coordination in home and office networks ............................................................. 8

1.3.3 Commercial platforms ......................................................................................................... 8

1.3.4 Relevant research activities .............................................................................................. 12

1.3.5 Ethernet-based embedded web servers ............................................................................. 12

1.3.6 Architecture ....................................................................................................................... 12

Chapter 2 OVERVIEW OF PROJECT ...................................................................................... 15

2.1 Overview .............................................................................................................................. 15

2.1.1 Rationale ............................................................................................................................ 15

2.2 High Level Design ................................................................................................................ 15

2.2.1 System Overview ............................................................................................................... 15

2.2.2 Software Overview ............................................................................................................ 17

2.2.3 Hardware Overview ........................................................................................................... 17

Chapter 3 DESIGNING ............................................................................................................. 19

3.1.1 Micro controller ATMEGA32 ........................................................................................... 19

3.1.2 Features .............................................................................................................................. 19

3.1.3 Networking Open Systems Interconnection (OSI) Model ................................................. 22

3.1.3 (b) Data Link Layer ........................................................................................................... 23

3.1.3 (c) Network Layer .............................................................................................................. 23

3.1.3 (d)Transport Layer ............................................................................................................. 24

Chapter 4 HARDWARE DESIGN ............................................................................................. 25

4.1.1 PCB Layout ....................................................................................................................... 25

4.2 Micro Controller ................................................................................................................... 25

4.3 Ethernet Controller ............................................................................................................... 28

Page VI

4.4 Ethernet Jack ........................................................................................................................ 31

Chapter 5 SOFTWARE DESIGN .............................................................................................. 32

5.1.1 ENC28J60 Ethernet Chip Driver Module .......................................................................... 32

5.1.2 Network Interface Card (NIC) Module .............................................................................. 32

5.1.3 uIP Module ........................................................................................................................ 32

5.1.4 HTTPD Module and Website CGI ..................................................................................... 33

5.1.5 Miscellaneous Modules...................................................................................................... 34

Chapter 6 CONCLUSION AND RESULTS ............................................................................... 35

6.1 Conclusions ........................................................................................................................... 35

6.2 Testing & Results ................................................................................................................. 35

6.3 Intellectual Property .............................................................................................................. 36

6.4 Ethical and Legal Considerations ......................................................................................... 36

6.5 Final Conclusions ................................................................................................................. 36

6.6 Considerations ...................................................................................................................... 37

INDEX........................................................................................................................................ 38

References .................................................................................................................................. 39

Page VII

List of Figures

Figure 1 : Ethernet-based embedded web server’s architecture. ........................................................... 13 Figure 2 : Data Flow ............................................................................................................................. 16 Figure 3 : Software Module Dependencies ........................................................................................... 17 Figure 4 : Pin Configuration ATMEGA32 .......................................................................................... 21 Figure 5 : The OSI Networking Stack .................................................................................................. 22 Figure 6 : PCB Layout .......................................................................................................................... 25 Figure 7 : Hardware look ...................................................................................................................... 27 Figure 8 : ATMEGA32 & RS232 ......................................................................................................... 28 Figure 9 : 3.3V Regulator Circuit ......................................................................................................... 29 Figure 10 : Ethernet Controller Module Circuit .................................................................................... 30 Figure 11 : ETHERNET CONTROLLER ............................................................................................ 30 Figure 12 : Ethernet Jack Circuit .......................................................................................................... 31

Page VIII

Abstract

Powerful microcontrollers are used as parts of most home and office

appliances of today. Integrating web servers to these intelligent devices will aid

in controlling them over the Internet and also in creating effective user

interfaces in the form of web pages. Assigning multiple functionalities to a

single button on an appliance help manufacturers economize user interfaces,

but, this can easily create confusion for the users. Since the cost of web-based

interfaces is considerably low, they can be used to provide the infrastructure

for the design of simple and more user-friendly interfaces for household

appliances. Also, a web page based interface is much easier to change, when

needed, as compared to a hardware interface. This paper presents a novel

approach to control devices with embedded web servers over the Internet and

to form device networks such that their components can make use of one

another’s services and functions while improving the user interfaces . The

main benefits of this approach include its lightweight design, automatic

configuration, and, utilization of widely available and tested network protocols

of TCP/IP and HTTP. The validity of the approach has been verified through a

prototype system working with real appliances.

Page 1

Chapter 1

INTRODUCTION

1.1 History Many home and office appliances such as televisions, VCRs, telephones,

watches, ovens, toasters, dish-washers and thermostats produced over the last

decade are equipped with complex features. This has become possible by the

computer industry’s ability to fit more transistors into a smaller area of silicon

which increases the computational capabilities of devices while decreasing the

cost and the power consumption. Nowadays, most of the home and office

devices contain embedded microcontrollers. One of the most important

reasons for embedding computers to everyday appliances is that they make

the appliance easy to use while giving them new features that enhance their

values (Borriello and Want, 2000). As of today, these embedded computers

cost a few dollars and are as capable as desktop computers of 1980s. Such

devices can support an embedded operating system with a TCP/IP stack,

interface to a 10/100 Mbps network and can be used as web servers [1].

The Internet has been mostly used to connect personal computers so far, but

shortly all kinds of appliances with embedded computers will exchange

information over the Internet. A massive number of microcontrollers are available

in today’s devices which can be linked to the Internet. If these intelligent

appliances could be connected to the Internet at low cost, the way we control

and manage their functions would change entirely.

As the abilities of appliances increase, the complexity o f controlling these

devices increases as well. The need for informative user interfaces is

suppressed by the higher cost of implementation. Therefore, complex appliances

come with poorly labeled buttons and overloaded functions. For instance, to set

the timer o f a stereo, a user should press a combination of buttons within a

few seconds. To ease the interaction with complex appliances, the scenario that

every device has a keyboard and a display is not an option considering an

Page 2

environment with thousands of embedded systems. We clearly should come up

with a compact solution. Web pages can be used as user interfaces where each

appliance has the ability to serve its user

Interface as a web page over the Internet. These pages can contain not only text

but also pictures, hypertexts, photographs, video and audio as in usual web

pages. By the advent of the user interfaces based on web pages, all devices

requiring user

Interaction can be controlled and managed from one device which includes a

web browser, such as a personal digital assistant, cell phone, etc. Also, use of

web page based, button and display free designs reduce the cost of production

while making the systems more user-friendly [2].

1.2 Introduction

Remote control via the Internet is not a new feature and used in home

automation systems. However, providing a mechanism for interaction between

devices in this environment is quite challenging. For example, an alarm clock

can interact with the heating system according to the alarm time and can send

instructions to the heating system to start warming the house before the

residents wake up. There exist some commercial platforms, which facilitate the

development of applications interacting with and exploiting the abilities of

networked intelligent devices, such as Universal Plug and Play (UPnP) (UPnP

Forum; Jini Community; Pascoe, 1999) etc. Our system is not similar to these

platforms. However, all solutions including ours aim at the same features,

namely supporting remote control of devices via the Internet and providing a

mechanism for interaction between devices. We believe that an attractive

alternative to the existing techniques is a web servers based system, where

each appliance runs an embedded web server serving the pages needed for its

own user interface. This approach is considerably simpler than the existing

systems while keeping most of their functionalities as will be explained in this

paper.

We designed application architecture, and, built and demonstrated a

prototype System that can integrate web servers to everyday appliances with

Page 3

embedded microcontrollers to control and manage them via web pages using

regular web browsers over the Internet. The system allows forming device

networks such that their components can easily make use of each other’s services

and functions. The unique architecture presented in this paper is used to develop

the prototype system which, in turn, used to test and demonstrate the

characteristics of our design. The main contributions of this architecture are its

lightweight design, automatic configuration and utilization of widely available

network protocols of TCP/IP and HTTP.

The remainder of this paper is organized as follows: Section 2 discusses

everyday appliances with web servers. It details out the Ethernet platform and

Ethernet Web Server, the basic components that we used in building our

platform. Section 3 presents the device coordination in home and office

networks. Platforms such as UPnP, Jini, and Salutation are introduced and

compared. In Section 4, Ethernet based architecture and our prototype system

design is introduced and compared with other available platforms. Section 5

discusses the benefits and drawbacks of the Home Appliance Network

architecture. Finally, Section 6 presents our conclusions [3].

1.2.1 Everyday appliances with web servers

Recent technological developments enable us to embed web servers into

everyday appliances with low costs. What do we hope to gain by putting our

devices online? Basically, the web enables users to fetch web pages and display

them on their own browsers in a platform-independent manner. Moreover,

information coming from an appliance’s sensors can be used to generate

dynamic HTML documents by common gateway interface (CGI) scripts.

Therefore, any device connected this way can be monitored and controlled

through CGI scripts and the results can be sent to the user’s browser as a web

page. Not only users, but also manufacturers can use web access to update their

products‟ software simply by uploading the new software to devices remotely or

appliances can be programmed to regularly check the manufacturer’s web site

for software updates and download them automatically when they are available.

Furthermore, when an appliance requires maintenance, it can automatically

inform the technical staff without interrupting the user.

Page 4

Web-based interfaces are cross-platform and easier to develop. The costs

related to product documentation, training and support are lower. These can be

instrumental in solving user interface related problems. Most complex

appliances have many unused functions, because users find them too difficult to

use. There are several reasons for poor interfaces. An important one of these

is that since manufacturers economize on buttons and displays, complex

features can be used only by button combinations with no or very hard to

understand indications on the button labels. Moreover, the feedback given to

the user after a performed action is

Usually not satisfactory (Nichols and Myers, 2003). On the other hand, as

manifested by the exponential growth of the number of web users globally,

ordinary people can use web based interfaces effortlessly without any

knowledge of the underlying hardware and software.

There are many industrial and academic groups that are working on generating

interfaces for complex appliances (Jini Community; Have; Nichols et al.,

2002). Human Computer Interaction Institute of Carnegie Mellon University

investigates how handheld devices can be used to improve the interfaces for

everyday appliances, using an approach called personal universal controller

(PUC). PUC exchanges information with the appliance. First, it downloads the

description of the appliance’s functions, and then it creates a control panel

using transferred description and finally it sends control signals to the

appliance as the user operates the panel. The control panel contains figures,

informative texts and extra features that ease the usage of the appliance. The

research is focused on automatic generation of control panels. Two studies

have been conducted in order to create high quality and user friendly control

panels. The first study is a between-subjects comparison of a handheld interface

with the interface to an actual device (Ponnekanti et al., 2001). Paper

prototypes (Rettig, 1994) were used in the first study as the handheld interface.

In the second study, actual implementations of handheld interfaces were used

instead of paper prototypes. Both studies showed that users were able to

complete complex tasks in about one half of the time and with half as many

Page 5

errors as the actual device interfaces (Nichols et al., 2002). The results of

experiments support the need for more informative user interfaces. In the sense

of simplifying the user interface of the appliance, the handheld interface

mentioned above and the web-based interface presented in this paper both

address the same requirements. Therefore, users can control complex

appliances easily with well designed, feature rich web-based interfaces which

contain self- informative buttons, hyperlinks, texts, figures, etc.

At this point, we should indicate that providing user interfaces as web

pages by no means guarantee having well designed user interfaces. However,

they facilitate

Easy design and maintenance of well-designed user interfaces based on web pages

and associated design tools. This paper focuses on the infrastructures for using

web pages as user interfaces. Web page design for better user interfaces is

outside our scope. The benefits of embedding a web server into an appliance

can be summarized as follows:

• Users can interact with appliances using a device which contains a web

browser.

Such devices, ranging from PCs to cell phones, are universally available

and using them is common knowledge.

• User-interface hardware (electromechanical) costs can be eliminated and

more user- friendly interfaces can be designed with low costs.

• Controlling, monitoring and updating can be done from anywhere in the

world.

• Products can be supported throughout their life cycles by manufacturers by

uploading

New software versions remotely, reducing the maintenance costs.

• User interfaces can be updated or extended. For example, accessibility

options for helping handicapped users can be added. User interface can be

featured in different languages [4].

Page 6

1.3.1 Ethernet open source project for building Ethernet devices

An embedded web server should use the HTTP protocol to transmit Web

pages from the embedded system to the web browser and to transmit form

data back to the embedded system attached to the appliance. The embedded

system requires a network interface, such as Ethernet, a TCP/IP protocol

stack, embedded web server software and static and dynamic web pages that

form the user interface for that specific device. Because the embedded systems

have limited CPU and memory resources and these resources are mostly used by

real- time applications, end-users may have to wait up to few seconds for an

HTTP response. Multi-threading should be employed in the embedded systems

to avoid slow response. Moreover, web server software must be able to

respond to multiple HTTP requests simultaneously and must use non-blocking

multithreading such that one HTTP transaction waiting for data will

not Prevent another HTTP transaction.

When implementing the TCP/IP stack for microcontrollers, some features can

be omitted depending on the specific application requirements. In order to serve

wide range of application requirements while keeping the size compact, an

embedded system should implement five basic protocols of the TCP/IP

protocol suite: TCP, UDP, IP, ICMP and ARP. Moreover, application level

protocols DHCP, DNS and HTTP should also be implemented [5].

Users can interact with appliances by submitting a form to an embedded web

server. The form data is processed by a CGI script and the results are returned

back to the user as an HTML page. Appliances can be monitored and

controlled by forms.

Hardware of a web-enabled embedded system must have a powerful and low-

cost microcontroller, compact size, flash/EEPROM for accommodating the

TCP/IP stack and an Ethernet controller.

Taking all these software and hardware parameters into consideration, we

chose the Ethernet system, which is an open source hardware and software

project for building embedded Ethernet devices, as the core component of our

web accessible home appliance network system.

Page 7

the Ethernet system includes a small board (80 mm x 100 mm), which is

equipped with Atmel At mega 128 CPU running at 14.7456 MHz with 4

KB internal SRAM, full duplex IEEE 802.2 compliant Realtek 10 Mbps

TRL8019AS (Ethernet 1) or 100 Mbps LAN91C111 (Ethernet 2) Ethernet

controller, 2 RS-232 serial ports, on board RJ-45 and DB9 connector, 22

programmable digital I/O, 8 channel, 10 bit analog/digital converter, 2 x 8 bit

and 2 x 16 bit timers/counters. The Ethernet 1 and Ethernet 2 boards are

equipped with 32 and 480 KB external SRAM, respectively.

The software part of the project consists of a real time operating system (Nut/OS),

which supports dynamic memory management, event queues, stream I/O

Functions, simple Flash ROM file system, and a TCP/IP protocol suite

(Nut/Net) which includes ARP, IP, ICMP, TCP DCHP, HTTP API with file

system access and CGI functions. The source code is well-documented and

implemented mostly in C. Wide range of applications were developed using

the Ethernet (Ethernet Hardware Manual) such as networked sensors, remote

monitoring equipment, alarm service providing, remote diagnose and service,

industrial Ethernet applications home/building control.

Web servers running on normal computers with mass storage devices use the file

system to retrieve the requested web document. To offer similar functionality,

Ethernet contains a very simple file system which is based on data structures

stored in the flash memory. The available space is very limited in embedded

systems to store web pages; however, web pages require only flash ROM space

and SRAM is not utilized (with typical applications at least 64 KB of web page

storage is available).

One of the ways of interfacing applications with web servers is to employ CGI. If

a form is submitted by the user, the web server executes the related CGI script

and the resulting web page is dynamically formed and returned to the user. By

this way, user can monitor the appliance’s status or control it through the

digital I/O ports.

Page 8

1.3.2 Device coordination in home and office networks

Letting the home devices communicate, interact and share functions/services

with each other requires some sort of device coordination within the appliance

network such that devices can enter the network, announce their services and

find services offered by other devices. For enabling device coordination, a subset

of the following capabilities should be provided to a device (Rekesh, 1999):

• Declare its existence to the appliance network,

• Discover the appliances in the network automatically,

• Describe its services and capabilities to other devices,

• Query and understand the capabilities of other devices,

• Configure itself automatically,

• Inter-operate with other devices wherever meaningful.

Some of the best-known commercial platforms for facilitating the development

of distributed applications interacting with and exploiting the capabilities of

diverse networked appliances is Jini, UPnP, Salutation and HAVi. Next, we

describe related work including these commercial platforms as well as relevant

research activities [6].

1.3.3 Commercial platforms

Jini from Sun Microsystems is based on Java technology. It is a programming

model and infrastructure that aims to enable spontaneously networked devices

to communicate, interact, and share each other’s services. The key idea of Jini is

to allow any device with a processor, memory and network connection to

provide services to other entities in a network and to use such services

offered by others. Jini provides mechanisms to enable devices to plug

together to form a Federation. Components of the federation may be

physical devices or software objects written in Java. In Jini terminology, such

devices and objects are called Services which can be connected to a network

and announce their presence to a Lookup Service. Clients that wish to use these

Services locate and call them to perform tasks [7].

Page 9

The Jini system contains three main types of players which are connected to a

network. There is a Service, such as a VCR, a printer, a digital camera, a

coffee machine, etc., a Client that would like to use this Service and a

Lookup Service that acts as an agent between services and Clients. Jini is

based on Java technology, so it exploits several advantages of Java. It turns

a heterogeneous device network into a homogeneous Java Virtual Machines

network, which supports the Write-Once-Run-Anywhere capability and

operating system independence. On the other hand, a device plugged into the

network has to be assigned with an IP address and a subnet mask. Thus,

Administration is still needed for the network. The most important

disadvantage of the Jini System is that running Java still costs a lot of

processing power. If you want to run JVM on limited resources, such as on an

8-bit microcontroller, the only choice has been the reduced subset of Java

created especially for the environment. Depending on processor, application,

and component set, a typical core code needs a memory space of 40 Kbytes

(Bettstetter and Renner, 2000).

UPnP from Microsoft is an architecture defined at a much lower level than Jini.

Instead of using virtual machines to change heterogeneous device networks to

homogeneous ones, protocols such as TCP/IP and standards like HTTP and

XML which can easily be implemented on all devices are used.

UPnP has five major components: Device Discovery, Device Description,

Presentation, Events and Subscriptions and Control. Device discovery enables

devices to announce their presence to the network as well as discover other

available devices in the network. During discovery, the information that is

exchanged, provide basic information about the devices and their services, and a

description URL, which can be used to gather additional information about the

device.

A device may contain a set of services corresponding to each functional

component of the device. UPnP keeps description of these services in XML files.

Page 10

In the device discovery phase, minimum information about the capabilities of

that particular device is transferred with the discovery messages. In the

description phase, control point learns more about the device by retrieving the

XML file from the URL provided by the device discovery message. If a device

has a URL for presentation, then the control point can retrieve a page from this

URL, load the page into a browser and depending on the capabilities provided, a

user can control the device and/or view its status. When a control point

subscribes to a service, the service sends event messages to the control point

to announce changes in device status. Control points use URLs that are

provided during the description process to access additional XML information

that describes actions to which the UPnP device services respond, with

parameters for each action. Control messages are formatted in XML and use

SOAP [8].

A device plugged into the network can receive its IP address and subnet mask

either by dynamic host configuration protocol (DHCP) or AutoIP (Rekesh,

1999). If there is a DHCP server in the network, device is configured

automatically by DHCP. On the other hand in AutoIP mechanism, the device

randomly chooses an IP address from a reserved range and then sends out a

request with address resolution protocol (ARP) to detect whether the IP

address is used by another device. UPnP does not specify any security

mechanism for access and control of UPnP devices. Security has to be

provided by the applications or services. Security standards on lower

networking layers such as SSL may be used to gain security. The security

features of this architecture have not been developed yet.

Salutation, developed by the Salutation Consortium, is cooperation architecture

to solve the problems of service discovery and utilization among diverse

appliances and equipment. The Salutation architecture provides a standard

method for devices to describe and advertise their capabilities to possible

Clients. It also enables devices to search other applications, services and

devices for a particular capability, and to request and establish sessions with

them to utilize the capability (Salutation Consortium, 1999a,; Salutation

Page 11

Consortium, 1999b). Salutation is shipping while others are still thinking!

Claims the Salutation Consortium in (Pascoe, 1999) while comparing its

solution to Jini and UPnP.

Products equipped with Salutation are available in the market since 1997. Six

member companies (Canon, Fuji, IBM Japan, Mita, Muratec and Ricoh)

demonstrated some Salutation-enabled products in 1997. These products

support a company intranet that automatically detects new peripherals as

they get attached and makes their capabilities available for use. The new

products include both hardware and software applications. Demonstrated

products are digital copiers, fax machines, scanners and printers. Many of them

integrate with Lotus Notes in a corporate intranet environment.

Salutation is nonproprietary and specifications are available for third-party

development. It is also a relatively lightweight platform, which is a significant

benefit for current mobile phones and PDAs. Salutation is not suitable for

dynamic and large-scale networks. Currently, its specification is being

modified to better suit large-scale networks. Unlike UPnP, Salutation does

not address the automatic configuration because of its transport independent

design. Moreover, it would not be easy to propose a solution to this problem

that worked on all transport types. Thus, its use for home networking is not

easy, since it needs administration for configuration. Moreover, Salutation does

not specify any security mechanism for access and control of networked

devices. Therefore, security mechanism has to be provided by the applications

or services.

The device discovery architectures given above, approach the problem of

service discovery very well. Jini and UPnP are both flexible and scalable.

Although Salutation is not suitable for dynamic and large-scale networks, it

addresses mobile devices successfully because of its lightweight design.

Moreover, it is the only platform used in commercial products in today’s

market [9].

Page 12

1.3.4 Relevant research activities

A number of research groups are working on controlling appliances from

handheld devices. The Stanford I Crafter (Ponnekanti et al., 2001) is a

framework for distributing appliance interfaces to several controlling devices.

Their structure supports the automatic generation of interfaces. The Web project

(Olsen Jar et al., 2000) aims to separate functionality of the appliance from

the device upon which it is displayed. Web defines an XML language from

which user interfaces can be created. The PUC is another framework for

improving interfaces to complex devices by introducing an intermediary

interface. A PUC engages in two-way communication with everyday

appliances, first downloading a description of the appliance’s functions, and

then automatically creating an interface for controlling the appliance.

The research activities mentioned above focus on automatic creation of user

interfaces rather than the system and infrastructure issues. These frameworks

separate the appliance from the interface. Interfaces are generated using

specification languages depending on the type of the control device.

1.3.5 Ethernet-based embedded web servers

Device networks based on Jini, UPnP and Salutation platforms need specialized

servers to be accessed over the Internet. On the other hand, we can connect our

home appliance networks together and enable access to appliances over the

Internet using the Ethernet. The architecture overview is given below and

illustrated in Fig 1.

1.3.6 Architecture

The Home Appliance Network (HAN) connects to the Internet through the

Ethernet Home Server (EHS). The Internet connection can be established

either via an analog modem over PSTN or via a GSM modem over GPRS

using the point-to-point protocol (PPP) (RFC 1661). Appliances within a

HAN can connect to the network either by wired (10/100baseT) or wireless

(IEEE 802.11) network technologies. After connecting to the Internet, EHS

sends its IP address and Unique Home Identifier (UHI) to an Address Server.

Page 13

Address Server keeps UHI, IP address couple for a certain period unless it is

renewed. This facilitates robust behavior in the case of Internet connection

failures and IP address changes, as the Address Server will not contain

HANs that are no longer available. Moreover, the Address Server prevents

unauthorized access to the HANs. An Address Server with a static IP is

necessary in this architecture since in every PPP connection EHS

Figure 1 : Ethernet-based embedded web server’s architecture.

May get a different IP address which must be known by the user in order

to reach the correct HAN over the Internet.

When an appliance is plugged into the network, it obtains its IP address,

subnet mask and gateway address from a DHCP server if it exists in the

network. If no DHCP server is available, appliance randomly chooses an IP

address from a reserved range of IP addresses and then sends out a request

using ARP to detect whether the IP address is used by another device. If the

address is used by another device, self-configuration procedure is started over

with a new IP address chosen randomly from the specified range.

After self-configuration finishes, the appliance locates the EHS by broadcast

unless it knows the EHSs IP address. If the EH‟s address is known by the

appliance, unicast can be used to send the information. The appliance sends

its identifier, IP and MAC address to the EHS. The identifier contains a

Page 14

descriptive name of the appliance, understandable by a user, such as „„The

Internet Clock‟. If an EHS is not available in the network, appliance starts

serving its web pages within the network and waits for an EHS online

announcement. When an EHS becomes online in the network, it broadcasts

an online announcement, so that appliances that are already in the network

register themselves to the EHS.

Each appliance within a HAN includes a web server that keeps web pages to

control and monitor its functions and status. Services of an appliance can be

executed using the hyperlinks to CGI functions on this web server. A service

request to a device within the HAN coming via the Internet is routed to the

target device by the EHS.

If the requester clicks one of these hyperlinks, again the CGI function opens a

TCP socket and performs actions on the target device (the IP address of the

target device is 192.168.1.5) according to the URL parameters and retrieves the

resulting web page. Once more, it modifies the web page so that later requests to

the appliance are directed over the EHS. A hyperlink pointing to an appliance

exists on the main web page of the EHS for a certain time unless the

information is renewed. This leasing mechanism is crucial for the robust

behavior of the system in case of appliance connection failures.

Page 15

Chapter 2

Overview of Project

2.1 Overview

Power Manager is a remote power management system that can be controlled through

a web browser on a local area network (LAN). Devices plugged into Power

Manager’s outlets can be turned on or off with the click of a button on a webpage.

Power Manager runs on an ATMEGA32 microcontroller and an ENC28J60 Ethernet

controller. Together, this embedded system acts as a web server to serve a web page

that allows the user to turn on or off the supply of power to the connected devices.

The project serves as a fundamental element in a home automation system.

2.1.1 Rationale

These days, everyone has a smart phone in their pocket connected to their home LAN.

With such a powerful device, why should anyone have to physically control their

home's power and lighting? With the advancement of micro controller technology, it

is now possible to have every device in a home be connected to a home LAN. These

home devices can act as web servers to provide a web-based GUI to control and

monitor the device. The simplest and most necessary kind of control is turning a

device on or off. Power Manager fulfills this need in a standard way; any device with

a standard electrical plug can be controlled (on or off) through home LAN [10].

2.2 High Level Design

2.2.1 System Overview

The Power Manager system is based on a client server model of communication. The

Power Manager acts as a web server embedded on the ATMEGA32 MCU and

ENC28J60 Ethernet controller. The MCU connects to the Ethernet controller through

an SPI interface; the controller handles the physical and MAC layers of networking,

and provides a standard interface to the MCU to send and receive packets. With this

interface, the MCU is able to run IP, TCP, and HTTP layers. Additionally, the MCU

connects through an audio cable to a power box. The power box contains a relay to

Page 16

control the flow of power to standard electrical sockets; the other end of the audio

cable is used to control this relay, allowing full control of power from the MCU.

To use the system, a client (perhaps a browser on an iPhone) sends a request over

HTTP to the Power Manager Web server, which returns a page indicating the current

state of power (on or off) and a button to toggle the state. When receiving a state

change request, the MCU calls a CGI function to change its output to the power box,

effectively changing the state of power flow to the electrical outlets. The flow of data

through the system is best described in Figure 1 below.

Figure 2 : Data Flow

Page 17

2.2.2 Software Overview

The design architecture for Power Manager can best be described on a modular

level. The system is made up of both networking and system modules. The

networking modules work together to provide data transmission and retrieval

functionality. The system modules implement system dependent data structures

and timers. All of these modules work together to provide the functionality

that Power Manager requires accomplishing its goals.

Figure 3 : Software Module Dependencies

2.2.3 Hardware Overview

Power Manager uses an ATMEGA32 micro controller (MCU) embedded on the

standard ECE 4760 custom PC board. The MCU connects to an ENC28J60 Ethernet

controller chip through an SPI interface on Port B. A module for the Ethernet

controller was custom built on a solder board, and appropriately connects the

controller to power, ground, I/O, etc. The Ethernet controller runs a 3.3V, so a power

regulator is used to drop the MCU's 5V VCC signal to 3.3V for the chip. Since the

Page 18

Ethernet controller's outputs to the MCU are at 3.3V, level shifters are used to turn the

signal back to 5V. This is not needed in the reverse direction, since the controller's

inputs are 5V tolerant. An RJ45 Ethernet jack is connected to the Ethernet controller.

Page 19

Chapter 3

Designing 3.1.1 Micro controller ATMEGA32

The high-performance, low-power Atmel 8-bit AVR RISC-based microcontroller

combines 32KB of programmable flash memory, 2KB SRAM, 1KB EEPROM, an 8-

channel 10-bit A/D converter, and a JTAG interface for on-chip debugging. The

device supports throughput of 16 MIPS at 16 MHz and operates between 4.5-5.5

volts.

By executing instructions in a single clock cycle, the device achieves throughputs

approaching 1 MIPS per MHz, balancing power consumption and processing speed.

3.1.2 Features

High-performance, Low-power Atmel

AVR

8-bit Microcontroller

Advanced RISC Architecture

131 Powerful Instructions – Most Single-clock Cycle Execution

32 × 8 General Purpose Working Registers

Fully Static Operation

Up to 16 MIPS Throughput at 16MHz

On-chip 2-cycle Multiplier

High Endurance Non-volatile Memory segments

32Kbytes of In-System Self-programmable Flash program memory

1024Bytes EEPROM

2Kbytes Internal SRAM

Write/Erase Cycles: 10,000 Flash/100,000 EEPROM

Data retention: 20 years at 85°C/100 years at 25°C

Optional Boot Code Section with Independent Lock Bits

In-System Programming by On-chip Boot Program

True Read-While-Write Operation

Programming Lock for Software Security

Page 20

JTAG (IEEE std. 1149.1 Compliant) Interface

Boundary-scan Capabilities According to the JTAG Standard

Extensive On-chip Debug Support

Programming of Flash, EEPROM, Fuses, and Lock Bits through the JTAG

Interface

Peripheral Features

Two 8-bit Timer/Counters with Separate Prescaler and Compare Modes

One 16-bit Timer/Counter with Separate Prescaler, Compare Mode, and

Capture Mode

Real Time Counter with Separate Oscillator

Four PWM Channels

8-channel, 10-bit ADC

8 Single-ended Channels

7 Differential Channels in TQFP Package Only

2 Differential Channels with Programmable Gain at 1x, 10x, or 200x

Byte-oriented Two-wire Serial Interface

Programmable Serial USART

Master/Slave SPI Serial Interface

Programmable Watchdog Timer with Separate On-chip Oscillator

On-chip Analog Comparator

Special Microcontroller Features

Power-on Reset and Programmable Brown-out Detection

Internal Calibrated RC Oscillator

External and Internal Interrupt Sources

Six Sleep Modes: Idle, ADC Noise Reduction, Power-save, Power-down,

Standby

and Extended Standby

I/O and Packages

32 Programmable I/O Lines

40-pin PDIP, 44-lead TQFP, and 44-pad QFN/MLF

Operating Voltages

2.7V - 5.5V for ATmega32L

Page 21

4.5V - 5.5V for ATmega32

Speed Grades

0 - 8MHz for ATmega32L

0 - 16MHz for ATmega32

Power Consumption at 1MHz, 3V, 25°C

Active: 1.1mA

Idle Mode: 0.35mA

Power-down Mode: < 1µA[8]

Figure 4 : Pin Configuration ATMEGA32

Page 22

3.1.3 Networking Open Systems Interconnection (OSI) Model

The OSI model is a standard way to do networking at all levels, from the physical

electrons on the wire to the applications communicating with each other. Power

Manager Implements all layers of this model. Figure 3 presents each layer of the

model. In our system, the Ethernet controller is responsible for the physical layer.

Figure 5 : The OSI Networking Stack

3.1.3 (a) Physical Layer

The physical layer is the first and lowest layer in the OSI model of computer

networking. This layer abstracts different hardware transmission technologies on a

network. The physical layer defines electrical and mechanical specifications for

devices and is perhaps the largest and most complicated layer in the OSI model.

Protocols in this layer define means of translating digital information into analogue

signals and vice versa. It handles the bit by bit transmission of data over both wired

and wireless communication mediums. Power Manager uses the ENC28J60 module to

handle this layer, and allows the MCU to use this layer through an SPI interface.

Page 23

3.1.3 (b) Data Link Layer

The data link layer arranges the bits handled by the physical layer into logical

sequences called frames. It abstracts the physical layer by providing the functional

and procedural means to transfer data between adjacent nodes or devices in a network.

The data link layer also provides specifications for correcting certain errors that may

occur over the physical layer. The Ethernet protocol is defined in the data link layer

for LAN. Ethernet is a fundamental standard for networking primarily because it is

the first layer where nodes are differentiated on a network. In the Ethernet protocol

each device is mapped to a globally unique 48-bit address. This address provides a

means to route frames to their correct destination. Power Manager also uses the

ENC28J60 module to handle this layer. Power Manager splits this layer between the

MCU and the Ethernet controller. The MCU must first generate (and write into its

device's EEPROM) a globally unique MAC address. Once this MAC address is

configured and set, the ENC28J60 driver stamps packet headers with both this address

and the MAC address of the device where the packet is designated to go. With this

information, the Ethernet controller is then able to push data onto the network using a

built in Media Access Control (MAC) module [11].

3.1.3 (c) Network Layer

The network layer provides the functional and procedural means for communication

among different networks. This is different from the data link layer because the data

link layer supports communication in the same network. IP is the de facto

communications protocol used for relaying datagrams across an internetwork.

Although this layer is not entirely necessary for Power Manager, it provides the

foundation for reliable protocols in higher layers like TCP. It also makes it possible to

control power in devices that may be in sub networks managed by multiple routers in

an encompassing LAN. Power Manager handles this layer using the uIP module. This

module handles stripping IP addresses from packets generated by a browser client. It

handles both IPv4 and IPv6 addresses. The uIP module abstracts away lower layers by

providing functions which accept any form of an IP address along with the content for

a desired packet and interfaces with the NIC and ENC28J60 modules to correctly

Page 24

structure and transmit it. It also provides a means to accept packets in their raw form

and deconstruct them to pull out the relevant information. Power Manager also uses

the uIP module to perform Address Resolution Protocol (ARP) broadcasts and

requests. ARP is a popular standard used to resolve an IP address from a MAC

address. Every device on the LAN (including Power Manager) maintains an ARP

cache which is necessary for routing packets to their correct destinations. ARP is

necessary because IP addresses are dynamic and have the potential to change (unlike

MAC addresses which are persistent throughout a device's life) with the devices life

cycle within its network [12]

3.1.3 (d)Transport Layer

The transport layer is the last layer that is relevant to the uIP module. It encompasses

the most important protocol for Power Manager known as the transport protocol layer.

TCP provides a reliable one to one connection between two nodes in a network.

Power Manager requires this technology because it must only transmit and receive

datagram packets with the client browser it is communicating with. TCP defines a

standard to ensure that packets arrive in the correct order and completely. Even if this

means that it must send multiple sub packets to get the information across. TCP is a

complicated protocol and is beyond the scope of this design documentation. It's

important to note however, that uIP handles all aspects of TCP like SYN-ACK

connection establishment, checksums, datagram fragmenting, datagram assembly, and

much more. uIP along with most of the other modules used in Power Manger was

designed and implemented by other programmers that will be credited in the reference

section of this report. We leveraged this module to help with the networking aspects

of Power Manager. We also tweaked the module to make it work with our specific

environment.

Page 25

Chapter 4

Hardware Design

4.1.1 PCB Layout

Figure 6 : PCB Layout

4.2 Micro Controller

An ATMEGA32 micro controller was used on the standard ECE 4760 custom PC

board. A schematic of the board can be seen in Figure 6. This MCU is clocked at

16MHz. Since power is drawn from the MCU to power the rest of the Power Manager

system (including Ethernet controller, RJ45 jack, relay, etc.), the standard 5V

regulator provided with the custom PC board could not provide enough current. Thus,

a larger 5V regulator was used with a heat sink to guarantee a steady 5V power supply

with large currents. To provide a serial connection to UART for debugging, a serial

Page 26

port, custom ECE 4760 serial board, and a Max233CPP serial controller were used;

pins D0 and D1 are wired to control this serial connection. The serial board can be

seen in Figure 7. Additionally, pin A7 is used as an output to control the relay in the

power box; outputting HIGH keeps the power on, while outputting LOW keeps the

power off. This connection between the MCU and the power box is completely

electrically isolated through the relay. A 3.5mm audio port is connected to pin A7 and

ground; the stereo lines to the port are shorted together to produce a 2-pin port. A

3.5mm audio cable plugs into this port and then into the power box to transfer the

signal.

Page 27

Figure 7 : Hardware look

Port B of the MCU is used to interface with the Ethernet chip, primarily through SPI.

Pin B1 is an input from the Ethernet controller and used as an interrupt for new

packets or dropped packets. Pin B2 is an output that connects to a hardware reset on

the Ethernet controller. Pin B4 is an output for slave select on the SPI interface. Next,

pin B5 acts as a master out, slave in (MOSI) for the SPI interface, where the MCU is

the master and the Ethernet controller is the slave. Pin B6 acts as an SPI master in,

slave out (MISO) from the Ethernet controller. Finally, pin B7 is an output for the SPI

clock. SPI is run at a frequency of the MCU's frequency divided by 16, meaning a bit

rate of 1 MHz Higher bitrates could be achieved if the SPI interface was done on an

integrated PC board; however, our long wires connecting the MCU to the Ethernet

controller requires a lower bit rate.

Page 28

LLERRIAL COMMUNICATION

4.3 Ethernet Controller

The Ethernet controller used is a MICROCHIP ENC28J60 Stand-Alone Ethernet

Controller with SPI interface. This chip contains a PHY module to handle the physical

layer of the OSI model, a MAC module to handle part of the data-link layer, an

internal buffer to store packets, and an SPI module to talk to a MCU. It runs at 25

MHz through an external 25 MHz crystal. The chip requires a 3V3 power source.

Power is drawn at 5V from the MCU's VCC pin and passes through a LD117-3.3

regulator to produce a 3.3V signal; capacitors are used on the input and output of the

regulator to remove noise in the power signal. The schematic can be seen in Figure 8

below, and a picture of this unit can be seen in Figure 5 above [13].

Figure 8 : ATMEGA32 & RS232

Page 29

Figure 9 : 3.3V Regulator Circuit

The ENC28J60 chip is connected to a custom module built on a solder board. The

schematics for this module can be seen in Figure 9 below, and a picture can be seen in

Figure 5 above. Schematics were made in accordance to the data sheet of the chip. All

constant 3.3V inputs to the chip have a 100 nF capacitor close by to ground in order to

remove noise from the power flow. The RESET, CS, SCK, and MOSI pins are inputs

to the controller from the MCU, and are 5V tolerant. The interrupt (INT) and MISO

outputs, however, are at 3.3V; thus, level shifters consisting of two 2N3904 NPN

transistors are used to create a non-inverted 5V signal from the original 3.3V signal.

The TPIN-, TPIN+, TPOUT-, TPOUT+, LEDA, and LEDB pins connect directly to

the RJ45 jack circuit (see next section). A 10 microfarad capacitor is used on VCap to

bias an internal regulator to produce a 2.5V signal to power some of the internal

modules of the chip.

Page 30

Figure 10 : Ethernet Controller Module Circuit

NET

CONTROLLER

Figure 11 : ETHERNET CONTROLLER

Page 31

4.4 Ethernet Jack

The RJ45 Ethernet jack used is a Magic Jack 10/100 BTX connector with internal

magnetics and two LEDs. The schematics for the jack can be seen below in Figure 10,

and a picture can be seen in Figure 5 above. Header pins were soldered to the tiny

pins of the connector to allow standard connections to the rest of the board. A ferrite

bead rated for at least 100 mA is used to reflect noise when transmitting packets; such

a bead is not needed for receiving packets. Capacitors to ground stabilize the packet

signals.

Figure 12 : Ethernet Jack Circuit

Page 32

Chapter 5

Software Design

5.1.1 ENC28J60 Ethernet Chip Driver Module

This module is composed of exactly two header files and a source file. The purpose of

this module is to define and implement all of the driver functions that are necessary to

transmit and receive data packets from the local area network. The enc28j60.h header

file defines different pin configurations for the board where the chip is located. The

driver abstracts away all of the complicated SPI communication between the MCU

and the ENC28J60 board from other components that make up Power Manager. This

makes writing and receiving packets into a matter of a few simple function calls. The

enc28j60def.h header file defines all of the memory locations for the different bank

registers, register bits, and SPI operation codes for the Ethernet controller. The header

file also defines where the in memory the start and stop address should be for its

incoming/outgoing packet buffers. Most of this information is available in the official

ENC28J60 design documentation [14].

5.1.2 Network Interface Card (NIC) Module

This module further simplifies the process of sending and receiving packets by

abstracting away the Ethernet driver details. Basically the NIC defines functions to

initialize itself, send packets, and to poll the network for any new packets. We input

packets by polling (through SPI) the chip's packet buffers for available information.

The system's method handles the situation of importing packets that are too big for its

buffer by simply dropping it. Once the packet has been received it stores it in a buffer

for the uIP module to break up and process.

5.1.3 uIP Module

The uIP module is a TCP/IP protocol stack designed to be as compact as possible for

embedded devices like the ATMEGA32 MCU. It handles all of the mid-level

networking protocols as defined in the open systems interconnection model (OSI). To

simplify communication in a network, the OSI standard hierarchically abstracts

Page 33

communication functions into logical layers. These layers help provide naming and

routing information for a device to be able to send its packets to its correct

destination.

5.1.4 HTTPD Module and Website CGI

Power Manager runs an HTTP web server over its TCP/IP stack. It is able to listen to

HTTP requests and respond with an HTML web page. The HTTP web server lies on

the application layer of the OSI model. When an HTTP request is received, the

requested page is loaded from program memory. This page contains calls to Common

Gateway Interface (CGI) functions; each CGI function call spawns a new

protothreads to run the function. In fact, the initial HTTP request is abstracted as

its own CGI function call; the request loads a protothreads which loads the page

from memory and outputs it on an HTTP response buffer. Additional CGI function

calls are made at this time and add to the HTTP response buffer. Once all CGI calls

are made, the HTTP response buffer is sent to the client and displayed on their

browser.

The Power Manager system contains three web pages: index.shtml, action.shtml, and

404.shtml. These web pages provide a GUI to view the current state of power flow in

the power box and to control the state of power flow. The 404 page is displayed on

default when a page that doesn't exist is requested. The index page displays the

current state of power, and a button to toggle the power. The button makes a request

to action.shtml with the requested action. If the action is "on", then HIGH is outputted

on pin A7 to turn the relay on; if the action is "off" a LOW is outputted to turn the

relay off. These actions guarantee that power will be at the requested state despite the

initial state. As soon as the action is performed, an HTTP redirect is issued to return

the user back to the index.shtml page to display the new state. A picture of the

index.shtml page can be seen below in Figure 13.

Page 34

5.1.5 Miscellaneous Modules

These consist of the modules that we leveraged from other sources but didn't touch.

This includes the modules that support protothreads, protosockets, timers, clocks, and

local continuations. Protothreads are stack less threads that were designed for memory

constrained embedded systems such as the ATMEGA32 MCU. Protosockets work

with protothreads to help provide sockets for TCP to work. A socket is an abstraction

that encapsulates a connection between a client and a server. It is used with the uIP

module to provide a means for TCP to make reliable connections. The timer and clock

modules serve to periodically signal Power Manager to perform its list of required

tasks (e.g. ARP broadcasts and incoming packet buffer polling). The clock and timer

modules are fundamental to Power Manager because events are handled

synchronously using polling methods. They are also important because different tasks

need to be performed in different time intervals. ARP broadcasts don't have to be

done on every clock cycle because IP addresses don't generally change that frequently

within networks. NIC polling on the other hand needs to be done more frequently

because packets come in all the time. These different tasks must be managed and

performed and different rates to ensure that everything goes smoothly. The local

continuations module provides support for local continuations which are fundamental

protothreads.

Page 35

Chapter 6 Conclusion & Results

6.1 Conclusions

The Power Manager system is effectively able to run IP, TCP, and HTTP stacks on an

AtMega32 MCU and interface these layers with the physical layer on an ENC28J60

Ethernet controller through SPI. All of this is done given the memory and processing

constraints of the AtMega32. To work with these constraints, all packets are limited to

at most 400 bytes; anything more is instantly dropped when received and broken into

multiple packets when transmitted. Additionally, the processing constraints and the

fact that long wires were used meant that the SPI interface had to be run at a slow

1MHz.

6.2 Testing & Results

Power turned out to be an issue with the system. On the ECE 4760 board, a regulator

generates a 5V power signal. We use this signal to power the MCU, the Ethernet chip,

the RJ45 jack, and the relay. The original regulator could not provide current to power

all of these devices. Thus, a larger regulator was used instead. This larger regulator

would get extremely hot and sometimes cut power, so a heat sink was added to stop

this.

Since CGI is used to generate HTTP responses, the CGI function calls provide a

serialization point for power control. Thus, multiple users can control the power at the

same time; however, the MCU can only handle a few simultaneous connections at

once, and is not meant for large scale use. A single client can effectively control

power from the web-based GUI with very little delay, performing basically

instantaneous power control.

Page 36

6.3 Intellectual Property

The majority of the fundamental modules were based on other people's code. A lot of

configuration was necessary to port the libraries to our environment, and we glued the

libraries together with our own main Power Manager module. The majority of our

code was based off the uhttpd-avr project. We want to give credit to Adam Dunkels,

whose library we leveraged for Power Manager’s uIP-1.0 minimalistic TCP/IP stack.

We configured Dunkel's HTTPD module which Power Manager uses to communicate

with client browsers on a local area network. This can be found on the same website

as the uIP module. We also leveraged the uIP version 0.9 ports to AVR ATmega32

with ENC28J60 which was written by Jonathan Granade (edi87 at fibertel.com.ar).

We give credit to the original writers of all modules we used.

The ENC28J60 module was based off of designs from Olimex, MICROCHIP,

NuElectronics, and TuxGraphics. These designs were ported to work with our

ATMEGA32. We give these designers full credit for their work.

6.4 Ethical and Legal Considerations

We abide by the IEEE code of ethics so we aren't worried about ethical and legal

issues. Although a significant amount of our code was based off other modules, we

give credit to the authors for their work and reference the links for their original

frameworks. Our source will be open source because all the code we leverage is also

open source under the creative commons license.

6.5 Final Conclusions

Power Manager meets all of our goals initially set out. Power to standard electrical

outlets, and thus to any plugged in device, is successfully controlled remotely through

a web-based interface, served entirely on an AtMega32 and ENC28J60 Ethernet

controller. Future iterations of this design would do everything much smaller on an

integrated circuit and be placed inside of the power box rather than as a separate unit

connected with an audio wire. Additionally, Wi-Fi could be used instead of Ethernet

to allow easier placement in one's home. Overall, we are happy with the final outcome

of our project.

Page 37

6.6 Considerations

We would like to thank Professor Bruce Land for working with us throughout the

semester to finish this project and patiently answer all of our questions. We would

also like to thank all of the TAs and course staff for ECE 4760 for working closely

with us to debug our issues, answers our questions, and keep the lab open late for

our benefit. Thank you all.

Page 38

INDEX

A Address Resolution Protocols (ARP) 11 AVR ATMEGA32 16

B C CGI Script 4 Conclusion 34 Consideration 36

D DHCP 11 Data Flow Diagram 17 Data Link Layer 24

E EEPROM 7 EHS 13 Ethernet Controller 31 Ethernet Jack 35 ENC28j60 6

F Features of Atmega32 19 Features of ENC28j60 Final Conclusion 35

G Gateway 4

H HAN 13 HTTP 3 Home Automation 17 HTML 4 Hardware looks 28

I ICMP 7 Intellectual Property 34

J K

L M Microcontroller 26

N Network Layer 24

O

OSI Model

P Protocols 3 PUC 5 Physical Layer 23 Pin diagram 22 PCB Design 26

Q R Regulator 3.3v 26 Regulator 5v 26

S SRAM 8 Subnet Mask 10

T TCP/IP 7 Transport Layer 25

U UDP 7

V

W Wireless protocol IEEE 802.11

X Y Z

Page 39

References

[1] “Embedded Web server Systems,” IEEE STD 802.11– 2007, October, 2007.

[2] “Air Interface for Fixed and Mobile Broadband Wireless Access Systems,” IEEE

P802.16e/D12,February, 2004.

[3] Hassan Yagoobi, “Scalable OFDMA Physical Layer in IEEE 802.16 WirelessMAN”,

Intel Technology Journal, Vol 08, August 2004.

[4] “WiMAX End-to-End Network Systems Architecture - Stage 2: Architecture Tenets,

Reference Model and Reference Points,” WiMAXForum,December,2005.

[5] “Mobile WiMAX – Part II: Competitive Analysis”, WiMAX Forum, February, 2006

[6] John Hoadley and Al Javed, “Overview: Technology Innovation for Wireless

Broadband Access”, Nortel Technical Journal, Issue 2, July 2005.

[7] John Liva and Titus Kwok-Yeung Lo, “Digital Beamforming in Wireless

Communications,” Artech House Publishers, 1996.

[8] S.M. Alamouti, “A Simple Transmit Diversity Technique for Wireless

Communications,” IEEE Journal on Selected Areas in Communications, vol. 16, pp

1451-1458, October 1998.

[9] G. J. Foschini, G.D. Golden, P.W. Wolniansky and R.A. Valenzuela, “Simplified

Processing for Wireless Communication at High Spectral Efficiency,” IEEE. Journal on

Selected Areas in Communications, vol. 17, pp. 1841-1852, 1999.

[10] A. Salvekar, S. Sandhu, Q. Li, M. Vuong and X. Qian “Multiple-Antenna Technology

in WiMAX Systems,” Intel Technology Journal, vol 08, August 2004.

[11] L.J. Cimini, “Analysis and Simulation of a Digital Mobile Channel Using Orthogonal

Frequency Division Multiplexing,” IEEE Trans. Comm., vol. COM-33, no. 7, pp 665-675,

June 1985.

Page 40

[12] Richard Van Nee and Ramjee Prasad, “OFDM for Wireless Multimedia

Communications,” Artech House, 2000.

[13] W. Xiao and R. Ratasuk, “Embadded Server Home Automation”, Proceedings of

the Annual Allerton Conference on Communications, Control, and Computing, pp. 1618-

1619, Oct 2002.

[14] G. Nair, J. Chou, T. Madejski, K. Perycz, P. Putzolu and J. Sydir “IEEE 802.16

Medium Access Control and Service Provisioning”, Intel Technology Journal, vol 08,

August 2004.