PROJECT REPORT

(Project Semester January –July)

SMART POLE and ANALOG LOGGER

SUBMITTED BY

MOHIT SINGLA

100806062

UNDER THE GUIDANCE OF

Professor Subrat Kar

Program Coordinator

Global Internship Program in Engineering Design and Innovation

under the aegis of Foundation of Innovation and Technology Transfer

Indian Institute of Technology Delhi Hauz Khas, New Delhi 110016, INDIA

DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING

THAPAR UNIVERSITY – PATIALA

JULY 2011

ACKNOWLEDGMENT

I thank the Global Internship Program in Engineering Design and Innovation

(GIPEDI) under the aegis of Foundation of Innovation and Technology Transfer

(FITT) Indian Institute of Technology Delhi (IITD) Hauz Khas, New Delhi for

giving me the opportunity to participate in their program.

In my six months industrial training it was a wonderful experience to be at Indian

Institute of Technology Delhi and a very good opportunity to work under brilliant

minds. I thank Prof. Subrat Kar for being my Faculty Mentor and for their timely

support and sharing of their experience with me. Their valuable comments are truly

appreciated. The knowledge I had gained throughout my training have the practical

implementation during this period.

I owe special thanks to Mr. Vijay Rao who, as my student mentor, guided me with

patience and knowledge. I thank him for his valuable help throughout the internship.

Last but not the least I would like to thank our college and training coordinator Mr.

Hardeep Singh and A.K.Chatterji for their efforts towards our six month internship.

MOHIT SINGLA

100806062

CONTENTS

INTERNSHIP PROGRAM AT IIT DELHI

INTRODUCTION

ASSIGNMENTS

o ASSIGNMENT 1- LATEX

INTRODUCTION TO LATEX

REQUIRED COMPONENTS OF A LATEX DOCUMENT

WORK DONE USING LATEX

o ASSIGNMENT 2- MAKEFILE AND DOXYGEN

MAKEFILE

DOXYGEN

WORK DONE USING MAKEFILE AND DOXYGEN

o ASSIGNMENT 3-GEDA

INTRODUCTION

FEATURE OF GEDA

WORK DONE ON GDEA

STEPS USED FOR ROUTING

ANALOG LOGGER

o INTRODUCTION

o PRINCIPLE

o HARDWARE REQUIRED

o DESIGNING IN ALTIUM

o FABRICATION

o RESULTS

SMART POLE

o INTRODUCTION TO SMART POLE

OBJECTIVE

HARDWARE DESCRIPTION

COMPONENT DESCRIPTION

o PROBLEM STATEMENT

o PROPOSED METHODOLOGY

o RESULTS

o CONCLUSIONS

o FUTURE WORK

APPENDIX

A. CODING IN C OF ATMEGA32 AND ATTINY2313

MICROCONTROLLER

B. COMMUNICATION RATE AND DATA RATE

C. MICROCONTROLLER INTRODUCTION

REFERENCE

INTRODUCTION TO INTERNSHIP PROGRAM AT IIT DELHI

INTERNSHIP PROGRAM

Within the Bharti School of Telecommunication Technology and Management, IIT

Delhi has started an Global Internship Program in Engineering Design and

Innovation (GIPEDI) under the aegis of Foundation of Innovation and Technology

Transfer (FITT) Indian Institute of Technology Delhi for Undergraduate /

Postgraduate students in any branch of the Electrical Sciences e.g. Electrical Engg,

Electronics with Telecommunication / Communications, Computer Science,

Instrumentation, Opto-electronics etc.

This Internship Programme is a different and separate program from the IIT Delhi

Summer Research Internship Program which has a limited intake. This internship

program will accept any student selected under the IITD Summer Research Program

with no charges (no application fee, no handling charges and no internship fee will be

charged).

BHARTI SCHOOL OF TELECOMMUNICATION TECHNOLOGY AND

MANAGEMENT

INTRODUCTION

Bharti School of Telecommunication Technology and Management was set up in

year 2000 through a joint initiative of IIT Delhi and Bharti Enterprises, with a vision

“To develop telecom leaders through excellence in education and research”.

The Bharti School of Telecom regularly organizes lectures for students to provide

them with an environment to learn from the industry leaders, receive insight into the

national and international best practices of the industry, and avail an opportunity to

interact with eminent leaders. The lectures add tremendous value to widen the

horizon of the students. All the lectures are rated by the students on the parameters of

content, learning application, subject research, innovations, etc.

AREA OF RESEARCH

Telecom Networks

Telecom Software

Wireless Technologies

Optical Networks

Signal Processing

RF Technologies

Telecom Systems Design

Planning and Management

Regulatory and Policy Aspects of Telecom Services and Systems

Embedded Telecom Systems

Telecom Network Management

AIRTEL IIT DELHI CENTRE OF EXCELLENCE IN

TELECOMMUNICATIONS

The Airtel IIT Delhi Centre of Excellence in Telecommunications came into

existence on 12 December 2007 with the signing of a tri-partite Memorandum of

Understanding (MoU) between the Department of Telecommunication, Government

of India, Indian Institute of Technology Delhi and Bharti Airtel Ltd.

AICET is functioning as an integral part of Bharti School of Telecommunication

Technology and Management, IIT Delhi.

AICET focuses on „Telecom Technology and Management‟ to build excellence

which is at par with world standards.

Various existing and emerging technologies, growth prediction and technology

adaptation in Indian context, application development using multiple technologies etc

form the broad spectrum of activities of the centre.

Airtel has indicated priority on the Spectral Efficiency, End-to-end IP network,

Energy management, Wireless Broadband and Traffic Engineering. It houses the

Virtual Wireless Lab projects, sponsored by MMRD, which is likely to impart the

engineering student community nationwide for remote experimentation and research.

INFRASTRUCTURE

THE TELECOM SOFTWARE LAB offers instruction in tools and methodologies

for telecom software development. Through a generous support program from M/s

Telelogic with its Telelogic Tau products, it is one of the few laboratories in the

country outside the Industry which conducts research and offers courses in Protocol

Development, embedded real-time operating systems and CASE tools.

With its server farm, consisting of an 8-CPU/16GB RAM server plus a cluster of five

4-way Xeon servers, 4GB RAM each, and a total storage of 1200 GB of hot-plugged

storage, the laboratory also offers the primary computing support to the entire school.

It offers a one workstation per student environment to the student.

The lab strongly supports Open Source Software and all its servers and workstations

are based on zero cost Open Source Software (Linux). The lab uses par virtualization

software both open source (Xen) and commercial (VMWare / Virtual Box) to

achieve increased server utilization by running several virtual servers on each

physical server. Further, this approach leads to drastically reduced set up times for

server initialization, easy process migration and data centre class server management.

The Telecom Software laboratory trains post graduate students. Research in areas of

telecommunication is conducted through Open Source software. The Lab is well

constructed over an area of 3200 sqft. having 52 PCs. It has facility of Wi-Fi enabled

network connection. The Telecom Software Laboratory invites intellectual

partners/researchers and sponsors.

Facilities

OS : Linux – Ubuntu 8.04 (Dapper), Solaris, Windows 2003

Simulation: Ptolemy, NS, Opnet*, Rsoft, Optiwave*, Commsim

VHDL: VHDL Studio (Green Mountain)

Embedded Systems: Rabbit, Bochs/IA-32Emulator, Intel IXP4xx, Intel IXP1200,

Intel IXP2400

IDE: Anjuta, Eclipse, SN, Forte/Netbeans

UML/SDL: Poseidon, Telelogic*, Rational

Cluster Software: OpenMosix, Citrix, Windows 2003

Requirement Management: Telelogic/DOORS

Open Source Initiatives

Carrier class telecom software development and deployment (OpenSOFT)

Embedded real-time systems for telecom (OpenOS – uCLinux)

Network management (OpenNMS)

Protocol specification and development (OpenSTACK)

Affordable telecom development tool-chain

Project Management/Analysis Processes

Management of software development processes

Telecom software requirement management

Formal specification using UML / real-time UML and SDL

Use of MSC and TTCN

THE TELECOM NETWORKS LAB is involved with the design and interworking

aspects of telecom networks access, edge, core and deep core networks. Recognizing

the benefits and cost effectiveness of emulating real life networks through emulators,

the lab has planned investments in several software suites both commercial software

like CommSim, Telelogic, OpNet and open source software which allow instruction

in communication networks while paring the investment in physical infrastructure to

a minimum. This also helps to avoid rapid obsolescence in physical equipment for

teaching and research. The lab has emulators for ISDN networks at the access level

and is in the process of acquiring test and measurement equipment for DSL, cable

modem, Bluetooth based protocols.

One of the significant objectives of this Lab is to build open source telecom protocol

stacks and building blocks under its Open Stacks initiative. This initiative is intended

to develop open source stacks for use without royalty.

This lab is equipped with the state of the art equipment which gives the students

hands on experience of the latest in Wireless Communications thereby enticing the

students to explore further frontiers of technology.

THE WIRELESS COMMUNICATIONS LABORATORY at the Bharti School is

engaged in research and education in the broad area of wireless communications and

networking, as to provide ubiquitous access to wired and wireless resources for

mobile and wireless multimedia users. It rein forces our belief that future wireless

networks will allow people on the move to communicate with anyone, anywhere, at

any time, using a range of multimedia services.

About the lab

The Wireless Communication Laboratory was setup with the following objectives:

To conduct lab classes at graduate level and advanced undergraduate level

To carry out wireless related project work

To support research activity in the area of wireless communications

To develop killer applications that will be interesting for the industry

To offer short term courses for people from the industry and academia

The Wireless Communication Laboratory is engaged in research on Multiple Input

Multiple Output (MIMO) systems and Space Time Codes, Broadband Wireless

Access, Software Defined Radio (SDR), Ultra Wideband (UWB) Communications,

embedded Systems for Wireless Communications, channel measurement and 10

modelling and broadband antenna design.

Current projects in the lab include the development of a UWB communications

prototype, development of Wideband antennas, security issues in energy constrained

sensor networks and the development of Software Defined Radios. Our research

activities are supported by generous grants from the Department of Science and

Technology (DST), Ministry for Human Resource Development (MHRD) and All

India Council for Technical Education (AICTE).

FOUNDATION FOR INNOVATION AND TECHNOLOGY TRANSFER

INTRODUCTION

Foundation for Innovation and Technology Transfer (FITT) is the Industrial Interface

of IIT Delhi. It was established at the Indian Institute of Technology Delhi (IIT

Delhi) as a Registered Society on 9th

July 1992. The mission of FITT is to be an

effective Interface with the Industry to foster, promote and sustain commercialization

of Science and Technology in the Institute for mutual benefits. For seventeen years

now, FITT has been in a mission mode for affecting the interface between the

Institute and the industry and has been devising innovative ways to create

partnerships and linkages with business and community to enable knowledge transfer

for common good. The team at FITT and IIT Delhi (IITD) academicians have been

largely responsible for their successful outreach efforts including extensive S&T

collaborations.

The role of FITT can be seen in fostering technology development, technical

consultancy, collaborative R&D, professional HR development programs, industry

site visits, event participation, corporate membership etc. This is necessitated by the

key agenda of the foundation to showcase and transfer the Institute “intellectual

ware” to industry and also inject industrial relevance in teaching and research at

IITD.

Quite a number of short term and medium term education courses on emerging

technologies have been organized and a number of important problem solving

innovative and research oriented consultancy projects have been taken up.

TRAINING

FITT regularly conducts both short term & long term HR Training Programmes

(Industrially Relevant courses) for the Professionals Working in Industry & Research

Institutions. Normally the training courses focus on contemporary areas of science

and technology such as nanotechnology, artificial intelligence, embedded technology,

renewable energy etc. The duration of the training courses varies from a few days to

some weeks etc.

PARTNERS

Corporate Members

Through the corporate membership scheme, FITT allows corporate to have a “single

window” on IIT Delhi Science & Technology and fosters links between business and

the academic community. Over the past several years, more than 250 companies have

taken advantage of this opportunity.

R&D Collaborators

National

Reliance Industries Ltd., Mumbai

C&S Protection and Control Ltd.

KritiKal Solutions Pvt. Ltd. (KSPL)

SHELL Technology India Pvt. Ltd.

BHEL Bangalore

BSES Yamuna Power ltd.

International

Mitsubishi Heavy Industries

Corning Inc

Institutional Partners in Techno-Entrepreneurship

Department of Information Technology (DIT), Govt. Of India

Department of Scientific and Industrial Research (DSIR), Govt. Of India

Technology Development Board (TDB)

Ministry of Micro, Small and Medium Enterprises (MSME), Govt. Of India

Tata Consultancy Services (TCS)

Indian Angle Network (IAN)

The Indus Entrepreneurs (TIE)

INTRODUCTION

I had done my six month internship in the internship program named Global

Internship Program in Engineering Design and Innovation (GIPEDI) under the aegis

of Foundation of Innovation and Technology Transfer (FITT) Indian Institute of

Technology Delhi started within the Bharti School of Telecommunication

Technology and Management, IIT Delhi by Indian Institute of Technology (IIT)

Delhi.

I had worked in the Telecom Networks Lab within the Bharti School of

Telecommunication Technology and Management, IIT Delhi.

I worked on various assignments and two projects as follow.

Assignment 1- LaTeX

LaTeX is a family of programs designed to produce publication-quality

typeset documents.

Assignment 2- Makefile and Doxygen

Make is a utility that automatically builds executable programs and libraries

from source code.

Doxygen is a documentation generator for the programming languages C,

C++.

Assignment 3- gEDA

gEDA is a set of software applications (Computer-aided design tools) used

for electronic design released under the GPL.

Project Analog Logger

Analog Logger is a GUI based data logger that takes an analog input and

transmits those data values digitally to PC where the data is collected in a file

and a Graph is plotted simultaneously.

Project Smart Pole

Smart Pole is a Motion detector based on detection using the sensors and

hardware consist of embedded system.

ASSIGNMENTS

1. ASSIGNMENT 1- LATEX

INTRODUCTION TO LATEX

LaTeX is a family of programs designed to produce publication-quality typeset

documents. It is particularly strong when working with mathematical symbols. The

history of LaTeX begins with a program called TEX. In 1978, a computer scientist

by the name of Donald Knuth grew frustrated with the mistakes that his publishers

made in typesetting his work. He decided to create a typesetting program that

everyone could easily use to typeset documents, particularly those that include

formulae, and made it freely available. The result is TEX.

Knuth's product is an immensely powerful program, but one that does focus very

much on small details. A mathematician and computer scientist by the name of Leslie

Lamport wrote a variant of TEX called LaTeX that focuses on document structure

rather than such details.

REQUIRED COMPONENTS OF A LATEX DOCUMENT

Every LaTeX document must contain the following three components. Everything

else is optional (even text).

\documentclass{article}

\begin{document}

\end{document}

The first statement tells LaTeX what kind of document it is to process, as there are

different style rules for different kinds of documents. The possible document classes

include article, report, book, and letter.

The body of the document, where you include all of your text, must occur between

the \begin{document} and \end{document} commands. Any text that comes after the

\end{document} command will be ignored.

WORK DONE USING LATEX

Assignment on latex contains a pdf file which has to be made in the latex. In that pdf

there were all type of initial learning process related to the latex. That pdf contains

the mathematical formulas, figures, function to be written table of data and many

more initial learning processes.

Manual for Analog Logger (With Multi-Platform USB Interfaced GUI). The manual

of the project analog logger was made in latex which contains all the information

about the analog logger like its process, principle, hardware and software

requirement, operating system on which it work and all the installing steps for the

analog logger on the linux, Windows7, Windows vista system etc.

2. ASSIGNMENT 2- MAKEFILE AND DOXYGEN

MAKEFILE

In software development, make is a utility that automatically builds executable

programs and libraries from source code by reading files called makefiles which

specify how to derive the target program. Make can decide where to start

through topological sorting.

It was originally created by Stuart Feldman in 1977 at Bell Labs. In 2003 Dr.

Feldman received the ACM Software System Award for the authoring of this

widespread tool.

DOXYGEN

Doxygen is a documentation generator for the programming languages C, C++, C#,

Fortran, Java, Objective C, PHP, Python, IDL (CORBA and Microsoft Flavors),

VHDL, and to some extent D.

It runs on most Unix-like systems, including Mac OS X, and on Windows. The first

version of Doxygen borrowed some code from an old version of DOC++; later, the

Doxygen code was rewritten by Dimitri van Heesch. Doxygen is a tool for writing

software reference documentation.

The documentation is written within code, and is thus relatively easy to keep up to

date.

Doxygen can cross reference documentation and code, so that the reader of a

document can easily refer to the actual code.

WORK DONE USING MAKEFILE AND DOXYGEN

I had written a C program that accepts 'n' user-names one-by-one and print them in a

sorted order using a link list. The linked list operations (addition, insertion, deletion)

were implemented in a separate file (userlist.c). A makefile was used to build the

executable 'user-sorter'.The program was commented using doxygen style comments

and doxygen was used to generate reports in html and latex.

Output of that program is given below.

Example:

Enter user name: yyy

(List: yyy)

Do you wish to continue? Y

Enter user name: ppp

(List: ppp->yyy)

Do you wish to continue? Y

Enter user name: rrr

(List: ppp->rrr->yyy)

Do you wish to continue? N

Sorted list:

ppp

rrr

yyy

3. ASSIGNMENT 3-GEDA

INTRODUCTION

gEDA is a set of software applications (Computer-aided design tools) used for

electronic design released under the GPL. As such, gEDA is an ECAD (electronic

CAD) or EDA (electronic design automation) application suite.

gEDA is mostly oriented towards printed circuit board design (as opposed to

integrated circuit design).

The gEDA applications are often referred to collectively as "the gEDA Suite".

The word "gEDA" is a conjunction of "GPL" and "EDA". The names of some of the

individual tools in the gEDA Suite are prefixed with the letter "g" to emphasize that

they are released under the GNU General Public License.

FEATURE OF GEDA

Modify the schematic

The process of transferring schematic modification to the PCB layout is very simple

using gsch2pcb. When initially you ran gsch2pcb it creates .net and .pcb files and

many more e.g. board.net, board.pcb etc.

Custom gschem symbol

We can generate our on symbol in the gEDA. One common way to do this is to

modify the existing symbols in the gEDA library.

WORK DONE ON GDEA

I had done an assignment using gEDA for PCB routing. I had to do the PCB routing

of the schematic given to me.

Here is the schematic diagram of the schematic of the assignment and the final routed

PCB designed using gEDA.

Schematic Diagram

PCB Final Routing

STEPS USED FOR ROUTING

Creating schematic

For creating schematic just we need to run gschem. We can create multiple

schematic and by using net connection they can be combined to form a single routed

PCB.

Adding components

Once we are done with the schematic creation we have to add the components to the

schematic. There is a tool bar at the top of the GEDA software. There is a tool named

components which has to be selected for adding the components. There are different

libraries for different components. We can select any component from the given

libraries.

Main advantage in this is that, we can also add our own libraries by making our own

components.

Adding attributes to the components added

Attributes are just named tags attached to symbols to convey some bit of information.

For using the schematic with PCB, there are three of these attributes which are

relevant and must be specified. Each added symbol or component should have a

footprint, value, and refdes attributes.

The schematic footprint attribute value of a component is the name of the element to

be placed on the layout for that instance of the component.

The gschem refdes attribute value of the component is the reference designator on

the schematic such as Q1, U1, R1, etc.

The gschem value attribute value is the particular component value such as BC546,

7400, 1K, etc.

Now we have to select the attribute window on clicking on the component to add

attributes to it.Net attributes gives the information about the connection of the

component with other component.

Generating PCB files from schematic

Now after adding attributes when our schematic is complete we have to generate

PCB files from the schematic that is done by gschem2pcb.Which generate the .pcb

file.

Placing the component

Now run the .pcb file to have the layout PCB file. After running .pcb file for the first

time you have to make some setting then components appears which are all together

in layout file. We have to disperse the components. This can be done by the

command disperse all elements or either manually.

Doing this manually is called placing the components. This can be done by dragging

and dropping the component from one place to other. This is done in a manner such

that there is minimum overlapping of the connection (rats nest lines) between the

components.

Routing the board

After placing the components we have to start routing traces between pins connected

by the rats nest lines. On the left PCB toolbar, select the LINE tool, select the layer

you wants to draw on (solder, component, etc), and start drawing lines by selecting

endpoints with the left mouse button. After we are done with the routing part our

PCB is complete for fabrication process.

ANALOG LOGGER

INTRODUCTION

Analog Logger (With Multi-Platform USB Interfaced GUI) is a GUI based data

logger that takes an analog input ranging from 0-50 mV and transmits those data

values digitally to PC through an USB interface where the data is collected in a file

with corresponding date & time value of sample taken and a Graph is plotted

simultaneously.

PRINCIPLE

The concept was to use ADC (Analog to Digital Converter) and UART (Universal

Asynchronous Receiver and Transmitter) of MCU.

The data coming at one of the ADC channels was converted into digital form by

ADC and then loaded on to UART of MCU internally to be transmitted serially at the

transmit (Tx) pin of MCU. This serial data was forwarded to PC with the help of

MAX232 (TTL to RS232 logic level converter) and a DB9 cable and the GtkTerm

was used to view this transmitted data. The entire coding was done in C language

HARDWARE REQUIRED

Device Package

USB port in PC

TRS Input Socket

SOFTWARE REQUIRED

FTDI Drivers for USB interfacing (Not required in Ubuntu (Linux))

OS: Linux/Windows XP/Windows Vista/Windows 7

DESIGNING IN ALTIUM

Creating a new PCB project

For creating new PCB project select File » New » Project » PCB project from the

menus. The projects panel displays. The new project file, PCB_Project1.PrjPCB, is

listed here with no documents added. Save it with your project name with .PrjPCB

extension.

Creating a new schematic sheet

Select File » New » Schematic, or click on Schematic Sheet in the new section of the

files panel. A blank schematic sheet named Sheet1.SchDoc displays in the design

window and the schematic document is automatically added (linked) to the project.

The schematic sheet is now listed under source documents beneath the project name

in the projects tab. save schematic sheet with an extension of “.SchDoc” with any

name. Select add existing to project for adding schematic sheets to the project.

Drawing the schematic

To manage the thousands of schematic symbols included with Altium Designer, the

schematic editor provides powerful library search features. There are default installed

libraries which are useful for finding the components but if we don‟t find the

components then we can install the libraries containing that component.

Before placing the component on the schematic, first we edit its properties by

opening the Component Properties dialog for the component. Here we set the value

of the designator field and footprints are given to the components.

Now we place the required components from different libraries to make our

schematic diagram. After placing all the components we have to wire up all the

components.

Wiring up the circuit

Wiring is the process of creating connectivity between the various components of

your circuit. Whenever a wire runs across the connection point of a component, or is

terminated on another wire, Altium Designer will automatically create a junction.

Nets and net labels

Each set of component pins that you have connected to each other now form what is

referred to as a net. To make it easy to identify important nets in the design, we can

add net labels.

After all the nets and net labels have been added our schematic capture is completed.

Setting up project options

The project options include the error checking parameters, a connectivity matrix, Class

Generator, the Comparator setup, ECO generation, output paths and netlist options,

Multi-Channel naming formats, Default Print setups, Search Paths and any project

parameters you wish to specify. Altium Designer will use these setups when you

compile the project.

When a project is compiled, comprehensive design and electrical rules are applied to

verify the design. When all errors are resolved, the re-compiled schematic designs

are loaded into the target document, e.g. PCB document.

Compiling the project

Compiling a project checks for drafting and electrical rules errors in the design

documents and puts you into a debugging environment.

We have already set up the rules in the error checking and connection matrix tabs of

the options for project dialog. To compile our project, select Project » Compile PCB

Project.

When the project is compiled, any errors generated will display in the messages

panel. Click on this panel to check for errors. If our circuit is drawn correctly, the

messages panel should not contain any errors. If the report gives errors, we have to

check our circuit and ensure all wiring and connections are correct.

Here is the schematic diagram shown in figure of the project analog logger.

Schematic Diagram of the Device Packat

Creating a new PCB document

Before we transfer the design from the schematic editor to the PCB editor, we need

to create the blank PCB with at least a board outline. The easiest way to create a new

PCB design in Altium Designer is to use the PCB board wizard.

With PCB board wizard we can set measure units, our own board size, and number of

layer in the board, via style, the component/track technology (routing) options and

design rules for track width and via sizes.

After setting these parameter, PCB board wizard create a new board named

PCB1.PcbDoc. Save that PCB board with any other name.

The board look like as shown in figure below.

PCB Board

Transferring the Schematic Information to the PCB

Once the project has been compiled and any errors in the schematic fixed, use the

update PCB command to generate ECOs (Engineering Change Orders) that will

transfer the schematic information to the target PCB.

Engineering Change Orders

After closing the ECO the target PCB opens with components positioned ready for

placing on the board.

The Components Next to the Board, Ready for Positioning

Designing the PCB

Now we can start placing the components on the PCB and routing the board. Before

we start positioning the components on the board, we need to set up the PCB

workspace, such as the grids, layers and design rules.

Grid We need to ensure that our placement grid is set correctly before we start

positioning the components. All the objects placed in the PCB workspace are aligned

on a grid called the snap grid. This grid needs to be set to suit the routing technology

that we intend to use.

Layers The View Configurations dialog provides access to colour settings for layers.

This dialog enables you to define, edit, load and save view configurations. It has

settings to control which layers to display, how to display common objects such as

pads, tracks, strings etc, displaying net names and reference markers, transparent

layers and single layer mode display etc.

Design Rules The PCB Editor is a rules-driven environment, meaning that as we

perform actions that change the design, such as placing tracks, moving components,

or autorouting the board, Altium Designer monitors each action and checks to see if

the design still complies with the design rules. If it does not, then the error is

immediately highlighted as a violation. Setting up the design rules before we start

working on the board allows us to remain focused on the task of designing, confident

in the knowledge that any design errors will immediately be flagged for our attention.

Positioning the Components on the PCB

Now we have to place the components on the board ensuring that the whole of the

component stays within the board boundary and there is minimum connection

overlapping between the components.

The components can be placed manually by using drag and drop system. We need to

re-optimize the connection line as when we drag and drop the components the nets

remain at their own position they don‟t move with the components so we need to re-

optimize the connection lines as we position each component.

Here is the diagram showing components on the board to be placed using drag and

drop system.

Components on the Board

Routing the Board

Routing is the process of laying tracks and vias on the board to connect the

components. Altium Designer makes this job easy by providing sophisticated

interactive routing tools as well as the autorouter option, which optimally routes the

whole or part of a board at the touch of a button.

While autorouting provides an easy and powerful way to route a board, there will be

situations where we will need exact control over the placement of tracks or we may

want to route the board manually just for the fun of it. In these situations we can

manually route part or all parts.

Here is the diagram of manually routing process and the final routed board.

Cursor Following Streamlines the Manual Routing Process.

Complete Routed Board

Verifying Our Board Design

Altium Designer provides a rules-driven environment in which to design PCBs and

allows us to define many types of design rules to ensure the integrity of our board.

Typically, we set up the design rules at the start of the design process and then verify

that the design complies with the rules at the end of the design process. To verify

that the routed circuit board conforms to the design rules, we will now run a Design

Rule Check (DRC).

There should not be any rule violations in DRC. We have completed the PCB layout

and are ready to produce output documentation.

.

Design Rule Check Dialog

Output Documentation

Now that you‟ve completed the design and layout of the PCB, you will want to

produce output documentation to get the board reviewed, manufactured and

assembled. These documents are generally intended for a board fabricator and,

because a variety of technologies and methods exist in PCB manufacture, Altium

Designer has the capability to produce numerous outputs for these purposes.

Now for fabrication process we need some Gerber output files.

Generating Gerber Files

Each Gerber file corresponds to one layer in the physical board top signal layer,

bottom signal layer, the keep-out layer and so on. Which are shown below.

Routed Bottom Layer

Routed Top Layer

Keep Out Layer of the Routed Board

Drill Layer of the Routed Board

Creating a Bill of Materials

The bill of materials for PCB document dialog displays the following.

Bill of Material

FABRICATION PROCESS

We are done with the designing process now fabrication is to be done with the files

obtained in the designing process. That was done on the machine used for this

purpose. We obtained the PCB after fabrication as shown in figure.

Front view of the PCB

Rear view of the PCB

Now coponents are soldered on this fabricated PCB to make our hardware. The

hardware after soldering and full device is shown in figure.

Hardware After Soldering the Components

Device Package

RESULTS

We tested the Analog Logger on windows 7 and on Linux (Ubuntu). The results are

shown for both the operating system.

Whenever we run the application, a console will appear which will test for available

ports and open ports. It will then search and assign a port for our device.

We change the input data i.e. analog value and we get the corresponding data value

on the graph which can be paused anytime in midway to see the previous data with

the help of a slider.

The corresponding data files will be formed in the application folder with the current

date appended to its name.

Data Received in Linux

Graph Plotted in Linux

Data Received in Windows 7

Graph Plotted in Windows 7

SMART POLE

INTRODUCTION TO SMART POLE

OBJECTIVE

Smart Pole is a Motion detector. Using a pole structure it detects the motion around it

and gives information about the object distance and the direction of motion.

HARDWARE DESCRIPTION

Smart Pole

Each ATtiny2313 microcontroller is connected to one PIR sensor and all

128ATtiny2313 microcontrollers are connected to ATmega32 microcontroller by

TWI protocol. Here is the Schematic diagram of the Smart Pole shown below.

Schematic of Entire Project

Programmer Board

I made a programmer board for loading hex file into the flash memory of the

microcontroller. The component required for this board are listed in the table below.

Component Name Value No. of Components

Printed Circuit Board PCB 1

Microcontroller ATmega8 1

USB Connector 1

IC Base 28 pin 1

Crystal Oscillator KDS1200 1

LED Red, Green,

Yellow

1 each

Connector 10 Pin 1

Jumper 3

Electrolytic Capacitor 10uF,25V 1

Parasitic Capacitor 22pf 2

Zener Diode 2

Resistor 1K(4),56(2),20K(1) 7

Component Required for Programmer Board

This was the programmer board before component soldering all the components

shown below.

Initial Programmer Board before Component Soldering

I soldered all these components on the printed circuit board and made programmer

board as shown in figure below.

Final Programmer Board after Component Soldered

COMPONENT DESCRIPTION

What is PIR sensor?

The PIR (Passive Infra-Red) Sensor is a device that detects motion by measuring

changes in the infrared levels emitted by surrounding objects. This motion can be

detected by checking for a high signal on a single I/O pin.

Apparent motion is detected when an infrared source with one temperature, such as a

human, passes in front of an infrared source with another temperature, such as a wall

because all objects above absolute zero emit energy in the form of radiation.

Here are the diagram of the rare view and front view of the PIR sensor shown below.

PIR Sensor Rare view

PIR Sensor Front view

The PIR sensor has two sensing elements. A body passing in front of the sensor will

activate first element and then the other element. The radiation source must pass

across the sensor in a horizontal direction so that the elements are sequentially

exposed to the IR source. Signals caused by vibration, temperature changes and sun

light will affect both elements simultaneously and are cancelled.

What is TWI Protocol?

TWI (two wire interface) is formally known as the Inter-Integrated Circuit bus, or

just the I2C bus. The TWI protocol is a simple, two wire connection that can link

multiple devices together and allow them to exchange data. In its simplest form there

is one master device that communicates to multiple slave devices. All devices are

connected in parallel to the two wires of the TWI protocol. The two wires are known

as SCL and SDA. SCL is the clock line and is controlled by the master device. SDA

is the bidirectional data line. To transfer data, the master sends out a slave address

combined with a one bit read/write flag. If a write is desired, the master will continue

to send data to the addressed slave. If a read is requested, the slave will respond with

data. To coordinate transactions, the SCL and SDA lines are manipulated by the

master and the slave to signal several conditions. These include START, STOP,

ACK (acknowledge) and NAK (no acknowledge). The nominal data rate on the TWI

protocol bus is 100Kbits/second.

Electrical Requirement The electrical requirements are very simple. The master and

the slaves must use the same level for VCC, the grounds must be connected, and the

SCL and SDA lines must be pulled up to VCC. TWI protocol is shown in figure

below.

TWI Protocol

PROBLEM STATEMENT

We are having 128 PIR sensors connected to each ATtiny2313 microcontroller.

Whenever there is motion observed to any of the PIR sensor then it got triggered.We

have to detect which sensor out of 128 sensors got triggered. PIR sensor got triggered

whenever there is a motion in covering area of the sensor (covering area of each PIR

sensor is up to three meter approximately in the vicinity of the sensor) and then it

sends a signal to corresponding ATtiny2313Microcontroller.

PROPOSED METHODOLOGY

Methodology used here is the embedded systems. Using this we are soft coding the

master and the slaves so that they transfer the data to each other.

We have to soft code both the microcontroller in such a way that whenever there is a

signal to ATtiny2313 it sends the information to the ATmega32 microcontroller

using the TWI protocol.

By using this TWI protocol we are sending the data from each slave to the single

master. This data contain the information that which sensor got triggered. Every

slave gets the information whenever there is motion in front of the sensor of that

slave.

In one second, master ATmega32 microcontroller communicate 16 times with each

slave ATtiny2313 microcontroller at the data rate of 100Kbits/sec on the TWI

protocol. For calculation of communication rate between master and slave refer to

appendix B.1.

PIR sensor output remains high for more than one second therefore in that interval

each slave is addressed by master more than 16 times so there is no possibility of lose

of and data. Possible data rate on the TWI protocol are 100K bits/sec, 400Kbits/sec

and many more. But the nominal data rate is100Kbits/sec. For setting of data rate on

TWI protocol refer to appendix B.2.

Master flow chart

Here is the flow chart of the master soft code.

Master Flow Chart

As shown in the flow chart microcontroller sends the address of the slave

continuously i.e. shown as 'i' in the flow chat. Then there is communication between

the slave and the master to send the data from the slave to master. Then master

displays the data taken from the slave. If the slave does not send any data i.e. send

zero value, that means the sensor in front of that slave has not been triggered so

master sends one higher address of the slave to communicate with (to take data) that

slave and continues in this fashion. Master sends the address up to 128 and after 128

it again send the address of first slave and continue doing that. For the full code of

the master refer to ATmega32 Code in the appendix A.1.

Slave flow chart

Here is the flow chart of the slave soft code.

Slave Flow Chart

Here we are using a temporary register to store the triggered value whose initial

value is taken to be zero. As shown in the flow chart if PIR sensor got triggered

microcontroller update the temporary register to one. Now if slave is addressed then

it sends the data and updates the register again to zero. Now if the sensor has not

been triggered then the register value remains zero. And when the slave get

addressed is sends the zero value. For the full code refer to ATtiny2313 Code in the

appendix A.2.

RESULTS

Result for interfacing PIR sensor with ATtiny2313 microcontroller is shown below.

PIR_IP_TNY in the figure refer to the direct output of PIR sensor which is the input

to the ATtiny2313 microcontroller. PIR_OP_TNY refer to the outputof ATtiny2313

when PIR sensor got triggered. In this way the data is collected in the slave.

Result for Interfacing PIR Sensor with ATtiny2313 Microcontroller

Result of the SCL and SDA line of the TWI protocol are shown in figure below.

Channel D8 is data line (SDA) as shown in figure and D9 is clock line (SCL) as

shown in figure. Frequency of the SCL line is 100Khz. Address is coming on the data

line. We can observe START and STOP condition as well on the line.

Result for SDA and SCL line

Result for SDA and SCL line and Data Coming out

Data Output and Code Checker

CONCLUSIONS

We are having PIR sensor output value. That value is being sent whenever there is

motion in front of the sensor. So PIR sensor interfacing with ATtiny2313 is

complete.

In TWI protocol, we are sending the address continuously as shown in the figure

above on the data line and the different slave has been addressed in each pass up to

128. Here we had tested our code for only one PIR sensor so the output of the data

coming from that sensor is being sent to the D0, D1, D2, D3 line as shown in figure

above. Here the result for the acknowledgment can also be observed in the figure.

FUTURE WORK

Data coming at ATmega32 output is stored in a variable. That data can be used for

alarming, for glowing LED, display on LCD and can also be display on PC (personal

computer) etc. This data can be used also in security purpose.

APPENDIX A

CODING IN C OF ATMEGA32 AND ATTINY2313 MICROCONTROLLER

A.1 ATmega32 C Code for working as master on the TWI protocol

/********************************************************************

Includes

********************************************************************/

#include <inttypes.h>

#include <stdio.h>

#include <stdlib.h>

#include <avr/io.h>

#include <util/twi.h>

/********************************************************************

Device Dependent Defines

********************************************************************/

#define MR_SLA_ACK 0x40

#define MR_DATA_ACK 0x50

#define START 0x08

#define MR_SLA_NACK 0x48

#define MR_DATA_NACK 0x58

#define REP_START 0x10

/********************************************************************

Public Variables

********************************************************************/

unsigned char DATA=0;

/********************************************************************

Public Functions

********************************************************************/

// initialize all peripherals

void init_peripherals( )

{

//PORTS

DDRD = 0xFF;

PORTD = 0x00;

//INTERRUPTS

SREG = 0x80;

//TWI

TWBR = 0x20;

TWCR = 0x45;

TWSR = 0x00;

}//end of initialization

// handle all communication for receiving data

void twi_receiver( )

{

// local variable

unsigned char i=0,j;

// infinite loop

while(1)

{

// loop continue for 128 times for every ATtiny2313

for(i=0;i<=127;i++)

{

//Multiplying 2 and adding 1 to get all 128 odd values

//between 0 to 255 for matching to read condition only

//and only sending these 128 addresses

j=i*2+1;

// Load address into TWAR Register

TWAR=j;

// Send START condition

TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN);

// Wait for TWINT Flag set. This indicates that the

//START condition has been transmitted

while (!(TWCR & (1<<TWINT)));

// Check value of TWI Status Register. Mask prescaler

//bits. If status is equal to START OR REPETED START condition

if ((TWSR & 0xF8) == START || (TWSR & 0xF8) == REP_START)

{

// Load address of slave into TWDR Register.

TWDR = TWAR;

// Clear TWINT bit in TWCR to start transmission of address

TWCR = (1<<TWINT) | (1<<TWEN);

// Wait for TWINT Flag set. This indicates that the address

//of slave has been transmitted, and ACK/NACK has been received

while (!(TWCR & (1<<TWINT)));

// Check value of TWI Status Register if status is equal to MR_SLA_ACK

if ((TWSR & 0xF8) == MR_SLA_ACK)

{

// Clear TWINT bit in TWCR to start receiving data

TWCR = (1<<TWINT) | (1<<TWEN);

// Wait for TWINT Flag set. This indicates that the DATA

//has been received, and ACK/NACK has been send.

while (!(TWCR & (1<<TWINT)));

// Check value of TWI Status Register. Mask prescaler

//bits. If status different from MR_DATA_ACK

if ((TWSR & 0xF8) == MR_DATA_ACK)

{

// Load data from TWDR Register.

DATA=TWDR;

// Transmit STOP condition

TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);

}

// Check value of TWI Status Register. Mask prescaler

//bits. If status different from MR_DATA_NACK

else if ((TWSR & 0xF8) == MR_DATA_NACK)

{

//Decresing variable to send repeated start

i--;

}

else

{

// Transmit STOP condition

TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);

}

}

// Check value of TWI Status Register if status is equal

//to MR_SLA_NACK

else if ((TWSR & 0xF8) == MR_SLA_NACK)

{

//Decresing variable to send repeated start

i--;

}

else

{

// Transmit STOP condition

TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);

}

}

// If status is not equal to START OR REPETED START condition

else

{

// Transmit STOP condition

TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);

}

}

}

}// end of twi_receiver

//main function calling other functions

int main( )

{

//Calling init_peripherals

init_peripherals();

// Calling twi_receiver

twi_receiver();

return 0;

}// end of main function

A.2 ATtiny2313 C Code for working as slave on the TWI protocol

/********************************************************************

Includes

********************************************************************/

#include <avr/io.h>

#include <avr/interrupt.h>

/********************************************************************

Device Dependent Defines

********************************************************************/

# define DDR_USI DDRB

# define PORT_USI PORTB

# define PIN_USI PINB

# define PORT_USI_SDA PB5

# define PORT_USI_SCL PB7

# define PIN_USI_SDA PINB5

# define PIN_USI_SCL PINB7

# define USI_START_COND_INT USISIF

# define USI_START_VECTOR USI_START_vect

# define USI_OVERFLOW_VECTOR USI_OVERFLOW_vect

# define SLAVE_ADDRESS 0x00

/********************************************************************

Functions Implemented as Macros

********************************************************************/

#define SET_USI_TO_SEND_ACK( ) \

{ \

/* prepare ACK */ \

USIDR = 0; \

/* set SDA as output */ \

DDR_USI |= ( 1<< PORT_USI_SDA ); \

/* clear all interrupt flags, except Start Cond */ \

USISR = \ ( 0<< USI_START_COND_INT ) | \ ( 1 << USIOIF ) |

( 1<< USIPF ) | \ ( 1<< USIDC )| \

/* set USI counter to shift 1 bit */ \

( 0x0E<< USICNT0 ); \

}

#define SET_USI_TO_TWI_START_CONDITION_MODE( ) \

{ \

USICR = \

/* enable Start Condition Interrupt, disable Overflow Interrupt */ \

( 1<< USISIE ) | ( 0<< USIOIE ) | \

/* set USI in Two-wire mode, no USI Counter overflow hold */ \

( 1<< USIWM1 ) | ( 0<< USIWM0 ) | \

/* Shift Register Clock Source = External, positive edge */ \

/* 4-Bit Counter Source = external, both edges */ \

( 1<< USICS1 ) | ( 0<< USICS0 ) | ( 0 << USICLK ) | \

/* no toggle clock-port pin */ \

( 0<< USITC ); \

USISR = \

/* clear all interrupt flags, except Start Cond */ \

( 0<< USI_START_COND_INT ) | ( 1<< USIOIF ) | ( 1 << USIPF ) | \

( 1<< USIDC ) | ( 0x0<< USICNT0 ); \

}

#define SET_USI_TO_SEND_DATA( ) \

{ \

/* set SDA as output */ \

DDR_USI |= ( 1<< PORT_USI_SDA ); \

/* clear all interrupt flags, except Start Cond */ \

USISR = \ ( 0<< USI_START_COND_INT ) | ( 1 << USIOIF ) |

( 1<< USIPF ) | \ ( 1<< USIDC) | \

/* set USI to shift out 8 bits */ \

( 0x0<< USICNT0 ); \

}

/********************************************************************

Typedef's

********************************************************************/

typedef enum

{

USI_SLAVE_CHECK_ADDRESS = 0x00,

USI_SLAVE_SEND_DATA = 0x01,

USI_SLAVE_REQUEST_REPLY_FROM_SEND_DATA = 0x02,

} overflowState_t;

/********************************************************************

Local Variables

********************************************************************/

static uint8_t slaveAddress;

static volatile overflowState_toverflowState;

/********************************************************************

Public Functions

********************************************************************/

// initialise peripherals

void init_peripherals( )

{

//PORTS

DDRD = 0xFF;

PORTD = 0x00;

//INTERRUPTS

SREG = 0x80;

}

// initialise USI for TWI slave mode

void usiTwiSlaveInit( uint8_t ownAddress )

{

slaveAddress = ownAddress;

// In Two Wire mode (USIWM1, USIWM0 = 1X), the slave USI will pull SCL

// low when a start condition is detected or a counter overflow (only

// for USIWM1, USIWM0 = 11). This inserts a wait state. SCL is released

// by the ISRs (USI_START_vect and USI_OVERFLOW_vect).

// Set SCL and SDA as output

DDR_USI |= ( 1<< PORT_USI_SCL ) | ( 1 << PORT_USI_SDA );

// set SCL high

PORT_USI |= ( 1<< PORT_USI_SCL );

// set SDA high

PORT_USI |= ( 1<< PORT_USI_SDA );

// Set SDA as input

DDR_USI &= ~( 1 << PORT_USI_SDA );

USICR =

// enable Start Condition Interrupt

( 1<< USISIE ) |

// disable Overflow Interrupt

( 0<< USIOIE ) |

// set USI in Two-wire mode, no USI Counter overflow hold

( 1<< USIWM1 ) | ( 0<< USIWM0 ) |

// Shift Register Clock Source = external, positive edge

// 4-Bit Counter Source = external, both edges

( 1<< USICS1 ) | ( 0<< USICS0 ) | ( 0 << USICLK ) |

// no toggle clock-port pin

( 0<< USITC );

// clear all interrupt flags and reset overflow counter

USISR = ( 1<< USI_START_COND_INT ) | ( 1 << USIOIF ) |

( 1<< USIPF ) | ( 1<< USIDC );

} // end usiTwiSlaveInit

/********************************************************************

USI Start Condition ISR

********************************************************************/

ISR( USI_START_VECTOR )

{

// set default starting conditions for new TWI package

overflowState = USI_SLAVE_CHECK_ADDRESS;

// set SDA as input

DDR_USI &= ~( 1 << PORT_USI_SDA );

// wait for SCL to go low to ensure the Start Condition has completed (the

// start detector will hold SCL low ) - if a Stop Condition arises then leave

// the interrupt to prevent waiting forever - don't use USISR to test for Stop

// Condition as in Application Note AVR312 because the Stop Condition Flag is

// going to be set from the last TWI sequence

while (

// SCL his high

( PIN_USI & ( 1 << PIN_USI_SCL ) ) &&

// and SDA is low

!( ( PIN_USI & ( 1 << PIN_USI_SDA ) ) ) );

if ( !( PIN_USI & ( 1 << PIN_USI_SDA ) ) )

{

// a Stop Condition did not occur

USICR =

// keep Start Condition Interrupt enabled to detect RESTART

( 1<< USISIE ) |

// enable Overflow Interrupt

( 1<< USIOIE ) |

// set USI in Two-wire mode, hold SCL low on USI Counter overflow

( 1<< USIWM1 ) | ( 1<< USIWM0 ) |

// Shift Register Clock Source = External, positive edge

// 4-Bit Counter Source = external, both edges

( 1<< USICS1 ) | ( 0<< USICS0 ) | ( 0 << USICLK ) |

// no toggle clock-port pin

( 0<< USITC );

}

else

{

// a Stop Condition did occur

USICR =

// enable Start Condition Interrupt

( 1<< USISIE ) |

// disable Overflow Interrupt

( 0<< USIOIE ) |

// set USI in Two-wire mode, no USI Counter overflow hold

( 1<< USIWM1 ) | ( 0<< USIWM0 ) |

// Shift Register Clock Source = external, positive edge

// 4-Bit Counter Source = external, both edges

( 1<< USICS1 ) | ( 0<< USICS0 ) | ( 0 << USICLK ) |

// no toggle clock-port pin

( 0<< USITC );

} // end if

USISR =

// clear interrupt flags - resetting the Start Condition Flag will

// release SCL

( 1<< USI_START_COND_INT ) | ( 1<< USIOIF ) | ( 1 << USIPF ) |( 1 << USIDC )

|

// set USI to sample 8 bits (count 16 external SCL pin toggles)

( 0x0<< USICNT0);

} // end ISR( USI_START_VECTOR )

/********************************************************************

USI Overflow ISR

Handle all the communication.

Only disabled when waiting for a new Start Condition.

********************************************************************/

ISR( USI_OVERFLOW_VECTOR )

{

switch (overflowState )

{

// Address mode: check address and send ACK (and next

USI_SLAVE_SEND_DATA) if OK,

// else reset USI

case USI_SLAVE_CHECK_ADDRESS:

if ( ( USIDR == 0 ) || ( ( USIDR >> 1 ) == slaveAddress) )

{

if ( USIDR & 0x01 )

{

overflowState = USI_SLAVE_SEND_DATA;

SET_USI_TO_SEND_ACK( );

}//end if

}

else

{

SET_USI_TO_TWI_START_CONDITION_MODE( );

}//end if

break;

// Load data to USIDR and set USI to shift byte

// next USI_SLAVE_REQUEST_REPLY_FROM_SEND_DATA

case USI_SLAVE_SEND_DATA:

// Load data

USIDR = SLAVE_ADDRESS;

overflowState = USI_SLAVE_REQUEST_REPLY_FROM_SEND_DATA;

SET_USI_TO_SEND_DATA( );

break;

// After Sending data reset USI

case USI_SLAVE_REQUEST_REPLY_FROM_SEND_DATA:

SET_USI_TO_TWI_START_CONDITION_MODE( );

break;

} // end switch

} // end ISR( USI_OVERFLOW_VECTOR )

/********************************************************************

Main Functions

********************************************************************/

int main(void)

{

unsigned char i;

//Multiplying 2 and adding 1 to get all 128 odd values

//between 0 to 255 for matching to read condition only

i=SLAVE_ADDRESS*2+1;

// initialise peripherals

init_peripherals();

// initialise USI for TWI slave mode

usiTwiSlaveInit(i);

return 0;

}

APPENDIX B

COMMUNICATION RATE AND DATA RATE

B.1 Communication Rate between master and slave

Frequency of SCL line = 100 KHz

1 byte = 1 bit

1 packet = 1(start bit) +7(Address bit) +1W/R+8(Data bit) +Extra clock cycle for

which SCL remain low (Held by Slave)

1 packet = 50 bits (taking approximate value)

128 packet = 50*128 = 6.4 Kbits

Communication rate =100k/6:4k times/sec = 16 times/sec

B.2 Data rate on TWI protocol

SCL frequency = Clock Frequency of Master / 16+2(TWBR) 4^TWPS

TWBR = Value of the TWI bit rate register in ATmega32 microcontroller = 0x20

TWPS = Value of the prescaler bits in the TWI status register in ATmega32

microcontroller = 0x00

Clock frequency of master ATmega32 microcontroller = 8 MHz

SCL frequency = 8 MHz/ 16+2(32)4^0 = 100 KHz

APPENDIX C

MICROCONTROLLER INTRODUCTION

C.1 ATmega32 microcontroller

ATmega32 microcontroller is working as a master. Pin diagram of the ATmega32

microcontroller is shown below.

Atmega32 Pin Diagram

The ATmega32 is a low-power CMOS 8-bit microcontroller based on the AVR

enhanced RISC architecture. By executing powerful instructions in a single clock

cycle, the ATmega32 achieves throughputs approaching 1 MIPS per MHz allowing

the system designer to optimize power consumption versus processing speed.

It has high-performance and low-power RISC architecture, 131 Powerful Instructions

(Most Single Clock Cycle Execution), 32 x 8 general purpose working registers, fully

static operation 32K bytes of in-system self programmable flash, 1024 bytes in-

system programmable EEPROM, 2K bytes internal SRAM. For more detail about

ATmega32 microcontroller refer to [2].

C.2 ATtiny2313 microcontroller

ATmega2313 microcontroller is working as a slave. Pin diagram of the ATtiny2313

microcontroller is shown below.

Pin Diagram of ATtniy2313

The ATtiny2313 is a low-power CMOS 8-bit microcontroller based on the AVR

enhanced RISC architecture. By executing powerful instructions in a single clock

cycle, the ATtiny2313 achieves throughputs approaching 1 MIPS per MHz allowing

the system designer to optimize power consumption versus processing speed.

It has high-performance and low-power RISC architecture, 120 Powerful Instructions

(Most Single Clock Cycle Execution), 32 x 8 general purpose working registers, fully

static operation 2K bytes of in-system self programmable flash, 128 bytes in-system

programmable EEPROM, 128 bytes internal SRAM. For more detail about

ATtiny2313 microcontroller refer to [1].

REFERENCE

1. http://www.atmel.com/dyn/resources/prod_documents/doc2543.pdf for

ATtiny2313 Microcontroller datasheet.

2. http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf for

ATmega32 Microcontroller datasheet.

3. http://www.nxp.com/documents/application_note/AN10216.pdf or I2C protocol.

4. http://www.parallax.com/dl/docs/prod/audiovis/PIRSensor-V1.1.pdf for PIR

sensor datasheet.

5. http://www.esacademy.com/en/library/technical-articles-and-

documents/miscellaneous/i2c-bus.html

6. http://www.instructables.com/id/I2C_Bus_for_ATtiny_and_ATmega/step3/I2C-

Drivers/

7. http://www.avrfreaks.net/