A PROJECT REPORT

ON
DATA ACQUISITION SYSTEM

FOR THE PROCESS

& ENVIRONMENTAL CHAMBER
SUBMITTED IN PARTIAL FULFILLMENT OF THE
REQUIREMENT FOR THE AWARD OF THE DEGREE OF
MASTER OF SCIENCE

IN

INSTRUMENTATION

BY
G.SHIVA KUMAR ROLL NO: 2410867004

UNIVERSITY SCIENCE &INSTRUMENTATION CENTRE

SRI VENKATESHWARA COLLEGE OF MATHEMATICAL
AND PHYSICAL SCIENCES
SRI VENKATESHWARA UNIVERSITY
TIRUPATHI, CHITTOR Dist-517502
 2009

ACKNOWLEDGEMENT

We feel it as a great pleasure to acknowledge my

gratitude to all the people who had their roles in the successful
completion of my project.

First of all, I acknowledge without hesitation, the grace of GOD

the Almighty, in this arduous journey. Undoubtedly it is He alone who
deserves all the credit for this work.
I express my gratitude to my parents and all my friends for their
support and encouragement during the preparation of this manuscript

I am thankful my project advisor and guide Mr. G. Venugopala

Rao, Managing Director of ELEGANT ANALYTICAL SERVICES,
Hyderabad without whose support this project would not have been
possible. He carefully guided me throughout the pursuit of my
Masters degree. His ideas and suggestions have been invaluable to
this project

I sincerely thank. Mr. A. Suresh Kumar, H.O.D, University

science and Instrumentation centre for his able guidance and advice
while carrying out this project.

My sincere thanks to all the lecturers of my department and for

university science and instrumentation centre without whose support
this dissertation would have been incomplete.

We are thankful to all the Staff, Librarians and friends who have
directly or indirectly helped us in the completion of the project with
flying colors.

Page 2 of 84
 Certificate

This is to certify that Mr. G.SHIVA KUMAR, student of Sri

Venkateshwara University College of Mathematical and Physical
Sciences, Tirupathi , carried out the project work for five months
completed successfully his dissertation work titled “Data
Acquisition System For Process & Environmental Chambers”,
at ELEGANT ANALYTICAL SERVICES, Hyderabad.

This project work was carried out under my supervision

and submitted in partial fulfillment of the Master’s degree in M.Sc.
(Instrumentation), of Sri Venkateshwara University, Tirupathi.

EXAMINER CO-ORDINATOR Dr. A. SURESH KUMAR

Head
USIC

Page 3 of 84
List of Abbreviations

ISR - Interrupt Service Routine

LED - Light Emitting Diode

RTC - Real time clock

PC - Personal computer

MSB - Most Significant bit

RH - Relative Humidity

RTD - Resistive Temperature Devices

SCK - Synchronous Clock

CRC - Cyclic Redundancy Check

EEPROM - Electrically Erasable Programmable Read Only Memory

FAT - File allocation Table

MMC - Multimedia Cards

SD - Secure Digital

GUI - Graphical User Interface

USART - Universal Synchronous Asynchronous Receiver Transmitter

BCD - Binary Coded Decimal

Page 4 of 84
DATA ACQUISITION SYSTEM
FOR THE PROCESS
&ENVIRONMENTALCHAMBE
R

Page 5 of 84
INDEX

List of Abbreviations
Abstract
1. Introduction……………………………………………………………….09
1.1 Control Logic
1.2 Data communication9
1.3 Simultaneous sampling
1.4 Input Buffering
1.5 Transducer Interfaces
2. Data logger or universal process scanner……………………………19
2.1 Overview
2.2 Physical Implementation
2.3 Proposed Operation
3. Implementation…………………………………………………………….24
3.1 Measurement Module
3.1.1 Measurement Unit
3.1.2 Memory Unit
3.1.3 System Operation
3.1.4 Complete Circuit Diagram
3.1.5 Construction of Measurement Module
3.2 PC Interface Modules
3.2.1 Hardware Requirement
3.2.2 The Download Procedure
4. Analysis of Design…………………………………………………………59
4.1 The Measurement module
4.2 The PC Interface Module
4.3 RS-232 communication
4.4 Housing
5. Sensor Interface…………………………………………………………….65
5.1 Resistance temperature Detector
5.2 Strain Gauge
5.3 Thermocouple
6. Software of Data Logger…………………………………………………..68
7. Example of logged Data of stability Chamber……..…………………
76
7.1 Materials Used
7.2 Sensor Position in Stability Chamber
7.3 Data

Page 6 of 84
 8. Data Logger Technical
Specifications…………………………………..81
9. Applications of Data Logger……………………………………………...82
10. Conclusion…………………………………………………………………..83

List of Abbreviations

ISR - Interrupt Service Routine

LED - Light Emitting Diode

RTC - Real time clock

PC - Personal computer

MSB - Most Significant bit

RH - Relative Humidity

RTD - Resistive Temperature Devices

SCK - Synchronous Clock

CRC - Cyclic Redundancy Check

EEPROM - Electrically Erasable Programmable Read Only Memory

FAT - File allocation Table

MMC - Multimedia Cards

SD - Secure Digital

GUI - Graphical User Interface

USART - Universal Synchronous Asynchronous Receiver Transmitter

BCD - Binary Coded Decimal

Page 7 of 84
ABSTRACT:

This report covers the theoretical design and

implementation of a Data Logging device. The report aims
to highlight the design stages undertaken from initial
conception through to the testing of the end product
constructed. The design was initiated in order to aid
conservationists in researching the living conditions of bats.
Thus the procedure which was adopted to create a cost
effective and user-friendly device can be clearly seen, in
the report, as the system is developed. The data logger
created stores hourly samples of temperature and humidity
data for a period of 6 months.

In order to allow the system to operate off

batteries low power consumption was an important criterion
in the design process. PC software has also been created
that will enable the user to view the data in a suitable
format. Due to the environment in which the device will
have to operate a robust housing was created. The system
created was also tested and the results of these tests have
also been included in the report as well as a detail analysis
of the design which highlights areas of improvement.

Page 8 of 84
INTRODUCTION

Page 9 of 84
INTRODUCTION:

In process industries like chemical, Pharmaceutical etc., Real

time data recording plays a vital role. To improve results, detailed
data analysis is necessary. The real time data monitoring and
recording can be achieved through DATA ACQUISITION SYSTEM.
Data acquisition software in association with DATA LOGGER provides
a comprehensive and complete solution to data analysis and
presentation.

A data acquisition system (DAS) comprises a host computer,

control logic, a data converter and a number of input channels. Data
acquisition hardware is controlled by a host computer which,
depending on the application, could be anything from an embedded
single-board computer to a net-worked PC. Figure 1 shows the
principal functional units of a `complete' DAS.

There are a wide variety of ways in which communication

between the PC and the DAS hardware can be accomplished. For
laboratory and production floor applications, perhaps the most
common interface is by way of the host computer's system bus. The
principal advantage of putting a data acquisition (DA) card into the
host's system bus is that it provides both a high bandwidth and the
ability to apply the host's computational resources to data reduction
and analysis on a real-time basis .Another popular interface method is

Page 10 of 84
to use an external communications link to the host computer. RS-232
serial communications, IEEE-488 general purpose I/O bus, and the PC
parallel (printer) port are all mature, but still popular standards.
Universal serial bus (USB) is starting to be-come significant because it
is shipping as standard hardware on newer computer sand offers
generally high performance.

Three major advantages are provided by an external

communications link. The first is that the DAS hardware does not
have to reside inside the host computer, an electrically noisy
environment. The second ad-vantage is that the DAS hardware can be
disconnected quickly and easily from the host, simplifying
maintenance and increasing portability. The final advantage is that if
the DAS possesses enough on-board intelligence, it can run
autonomously of the host, and in the extreme case of a remote data
collector, need not even be connected to the host to operate. The
choice of what type of interface the DAS should use is complex, and is
driven by issues such as cost, performance, portability and ease of
maintenance .Table 1 lists some of the available options and a their
relative ad-vantages and disadvantages.

Table1. Comparison of DAS-to-host system interfaces.

Page 11 of 84
Figure1. A data acquisition system (DAS) comprises a host computer,
control logic, a data converter and a number of input channels.

1.1 Control logic

For the most simple in-host DA cards, control logic

may consist of just enough circuitry to send commands to the
analogue to digital (A/D) converter and read the results. More
sophisticated DA cards add functions that increase the ability of the
device to behave autonomously from the host. One such function is
the ability of a card to periodically acquire data and stream it to the
host computer's memory without host intervention. The features that
are needed to do this are a pacer clock and a direct memory access
(DMA) controller. The pacer clock directs the analogue-to-digital
converter (ADC) to perform conversions at uniform intervals, and
often allows for the control of multiple input channels. ADMA
controller allows the DA card to send data directly to the host's
memory during idle bus cycles. This allows for both high data transfer
rates, and frees the host processor from having to manage each
communication.

In some cases, particularly those requiring extremely

high sampling rates (greater than10 Msa/s), the host computer's bus
may not provide adequate bandwidth for real-time operation. In
situations such as these, analogue-to-digital conversion results are
stored in local high-speed memory on the DA card, and then read by

Page 12 of 84
the host process or when the sampling run is done. Local memory is
also used extensively in external DAS’s where the DAS-host band-
width may be relatively low compared with the peak sampling rate.
Specialized DAS systems may also contain on-board digital signal
processors (DSP’s) as well as logic for capturing and processing
specialized inputs, such as video signals from video cameras.

1.2 Data conversion

Although there are numerous techniques for

performing analogue-to-digital conversion, the most popular on
present-day general-purpose DA cards are successive approximation,
and flash conversion. Figure 2 shows the key components of a
successive approximation converter. Con-version of a signal from the
analogue to the digital domains requires a number of discrete and
sequential operations to be performed. A `conversion' is first
triggered by a signal fed into the `start' input. The first step in the
subsequent conversion cycle is that the input is sampled and held
stable, by means of the sample-and-hold amplifier at the input. This
step is particularly important because if the signal seen by the
converter core varies during the conversion cycle it can cause grossly
erroneous results. Throughout the conversion cycle this sampled
voltage is compared with a reference voltage generated by a DAC.
The DAC derives its output voltage based on a binary code received
from the successive approximation register (SAR).After the initial
sampling, the most significant bit of the SAR is set high. This causes
the DAC to output a voltage that is half of its full-scale range. The
comparator deter-mines if the input voltage is greater than the DAC
voltage. If this is the case, the SAR register holds the bit high; if not,
the SAR register drops the bit low. On subsequent cycles, the SAR and
control logic repeats this sequence with the next most significant bits,
all the while retaining the values of the previous ones. After `N' such
cycles the SAR contains a binary value corresponding to the input
voltage, at which point the control logic signals that the conversion is
complete and the data is valid.

The major drawback of successive approximation ADCs is

their requirement of performing `N' sequential analogue comparisons
to perform a conversion. In applications requiring maximum
conversion speed, such as video signal capture, the flash ADC
architecture is commonly employed. Figure 3 shows a block diagram
of an 8-bit flash ADC. In this type of converter, a reference voltage is
divided along a chain of reference resistors to provide sub-reference
voltages equivalent to the transitions between each output code; for
an 8 bit converter there would be 255 taps along the resistor chain.
The input signal is simultaneously compared to each of these sub-
references by an independent comparator. The result of this mass

Page 13 of 84
comparison is that the output of every comparator for which the input
signal exceeds its sub-reference is turned on.

Page 14 of 84
 The outputs of all the comparators are then fed into logic
referred to as a priority en-coder. This device takes the 255
comparator results and outputs an 8-bit code corresponding to the
`highest' comparator that has been activated. Because all the
comparisons are performed at once, this type of converter can be
made very fast. The major disadvantage of the flash ADC is its
complexity. Both the number of comparators and amount of logic
required increase as 2N with the number of bits of resolution which
are required. For this reason, most flash ADCs tend not to exceed 8
or10 bits of resolution.

1.3 Simultaneous sampling

Although DAS’s with very high conversion rates may

require the use of a separate ADC for each input channel, the more
typical case is to share a single ADC among a number of channels
using a multiplexer. A multiplexer is a switch, usually electronic, that
selects one input channel from among many, and connects it to the
ADC. While multiplexing multiple input channels into a single ADC
reduces the cost of a DA card, it also means that measurements of
multiple channels cannot be per-formed simultaneously. In cases
where this is required, a feature called simultaneous sampling is
available on many DA cards. On a card with simultaneous sampling,
each input channel is provided with an analogue sample-and-hold
amplifier. Upon receiving a `hold' command from the control logic,
each sample-and-hold amplifier will maintain an output value
corresponding to whatever was present on its input at the time the
command was issued. The multiplexer and ADC can then perform
sequential conversions on each channel. To the end-user, the
acquired data appears as if it were sampled simultaneously with a
dedicated converter for each input channel.

1.4 Input buffering

While most DAS’s are intended to monitor real-world

signals, the vast majority of DA cards, especially low-cost ones,
assume that the real-world consists of noiseless volt-age sources with
a range of +/- 10 V. To properly cope with signals resulting from
sensors, laboratory experiments, and the factory floor requires
circuitry which specially designed for that application. Figure 4 shows
a generic interface for volt-age-type signals. This circuit illustrates
four functions:
1. Radio frequency interface (RFI) rejection
2. Electro static discharge and static protection.
3. Anti-aliasing and
4. Selectable gain.

Page 15 of 84
 In today's communications-intensive world, electronic
equipment has to be de-signed from the outset to be able to operate
reliably in the presence of a wide range of radio frequency
interference (RFI) sources. While it may be obvious that RFI can
interfere with electronics that operate at radio frequencies, it can also
have effects on devices that process low-frequency and near DC
signals, such as most DA cards. The main problem in these cases is
that the individual transistors incorporated in even low-frequency
circuits have responses up into the hundreds of mega hertz, and will
rectify these RF signals into DC.RF injected into low-frequency
electronic systems usually manifests itself as offset and gain errors of
mysterious origin.

ESD and transient protection are additional features

needed to cope with a less-than-ideal world. In dry environments,
such as much of North America in the winter, it is not uncommon to
be able to develop 30 kV or higher discharges from normal activities.
When you also consider transients developed from nearby lighting
strikes and the power distribution system, it becomes clear that
electronic systems not designed specifically to survive these events
will have painfully short life-spans. This becomes even truer in really
nasty environments, such as a factory production floor.

An anti-aliasing filter is a feature that rarely appears on DA

cards, mostly because its required properties are so dependent on the
application for which the card is used. An anti-aliasing filter is used to
remove high-frequency components of an incoming signal. Unlike the
case of the RFI filter, the signals removed by the anti-aliasing filter
will not result in malfunctions of the DA card circuitry, but can result
in significant measurement errors. The whole problem of aliasing
arises because an ADC takes snapshots of the signal at discrete
moments in time. When these snapshots are taken at a frequency

Page 16 of 84
that is high compared to that of the signal of interest, it is possible to
reconstruct an accurate representation of the original signal from the
acquired data, as depicted in Figure 5a. When the sampling rate is too
low, however, the sampled data set will not give a good
representation of the original signal, and may even result in a grossly
inaccurate representation, as shown in Figure 5b.

For a given input signal, with a maximum frequency

component of `f', a theoretical minimum sampling rate of `2f' is
required to be able to accurately reconstruct that signal. This
sampling rate is referred to as the Nyquist rate. To adequately sample
a signal, one must either increase the sampling rate beyond the
Nyquist rate, or re-move all incoming signal components greater than

Page 17 of 84
the maximum allowed by a given sampling rate. Note, however, the
emphasis on both theoretical and mini-mum; it is usually a good idea
in practice to both limit the bandwidth of the incoming signal, and to
sample significantly faster than the Nyquist rate.

Finally, since real-world signals come in all sizes

(magnitudes), some means of control-ling gain is useful. The input
channels of a DA card may have a programmable gain amplifier or
attenuator, allowing the user to change the full-scale range of the
input channel. Adjustable gain is a common feature on all but the
least expensive DA cards.

1.5 Transducer interfaces

While the generic input buffer described above will

allow a DAS to deal with a variety of real-world voltage input signals,
the signals derived from transducers may require some specialized
interfaces before they become usable by a generic A/D card. This
section will describe interfaces for two of the more commonly
encountered transducers.

Page 18 of 84
2. Data logger (or) Universal Process Scanner:

Data loggers are essentially data acquisition systems,

which are used to record, store, interpret and retrieve data such as
electrical signals. Simply put, data loggers are data recording and
storage devices, and are built as either complete data acquisition
systems, or stand alone data recorders. A stand alone data logger is
usually used in large scale, where using complete data acquisition
systems will prove to be very expensive. ECG & EEG logger is one
such example of a standalone data logger. This data provided can be
referred at any future time, and can also be downloaded into a
computer.

Most conservation groups are non-profit organizations

and field researchers often run into the problem of insufficient funds
for technology capable of capturing and storing data. Besides the
exorbitant costs of the average data loggers currently available, these
devices are not always user friendly nor are they compact. It was thus
the objective of this design to create a data logging device that was
inexpensive, easy to use and convenient to transport to the site of
implementation.

For life sciences research project, usually extensive and

advanced data acquisition systems are used. Here cost is certainly
not a consideration, since, research projects involves huge sums of
money, huge personnel involvement and limited availability of time
for project completion. However, in health institutions, data loggers of
medium functionality are used to increase internal efficiency and
keep the costs down.

After consultation with various individuals that play an

integral role in research and conservation of bats, it was concluded
that the most sought after data, pertaining to the dwellings of
bats, is temperature and relative humidity. Thus the group set out to
design an autonomous product capable of measuring and storing
these parameters for a period of 6 months. Due to the sites of
implementation of the devices it was realized that these units would
have to be completely battery operated. A direct result of this is that
the device had to be designed for low power consumption.

In order for the data to be to functional to researchers it was

required that the temperature be accurate to 2°C and the humidity to

Page 19 of 84
4 % whilst the respective ranges of operation are 0°C-50°C and 0%-
100%.
Furthermore, the device would have to be in a robust housing which
provides water resistance and a measure of shock absorption. In
order for a prospective user to access the data on the device a simple
and user-friendly method of transferring the data to a PC would be
required. Facilities in order to process this data on the PC will also
have to be made available.

The table below provides a summary of the tasks and

constraints which the project is subject to.

2.1 Overview:

Using the tasks illustrated in Table 1 a system block diagram

was created.

Page 20 of 84
 Of the constraints displayed the most difficult to achieve is the
6 months of operation on standard batteries. In order to achieve this
goal all major design decisions were taken in order to minimize power
consumption. Evaluation of the tasks revealed that two major tasks
were required, namely the measurement and storage of data
(Memory Module) and the other being the downloading of data to the
PC and the processing of data (PC Interface Module) . These tasks are
made visible on the following block diagram.

Table 3: Tasks and Constraints of the PC Interface

Page 21 of 84
 The separation of the functions into different units highlights
a major factor. That is that the main constraint of the system, power
consumption, will only influence the design of the Measurement
Module. Limiting the constrained region of the project would allow for
greater design freedom and increased functionality in the PC Interface
Module. There are further benefits in terms of product usability that
will be illustrated.

2.2 Physical Implementation:

Evaluation of Figure 3 highlights that the memory

device is used by both modules. In order to increase the functionality
of the system the memory device was designed as an independent
unit which could be transferred between modules when required. To
create the required system three separate units were designed
and constructed, namely: Measurement Unit, Memory Unit and PC
interface Unit. The Measurement Unit in conjunction with Memory Unit
forms the Measurement Module. The PC Interface Unit connected to
the Memory Unit in conjunction with a PC forms the PC Interface
Module. The units and their associated modules are illustrated in the
following diagram.

Page 22 of 84
2.3 Proposed Operation :

The understanding of the systems operation is best

explained by use of an example of how a potential customer would
use the device. The Measurement Unit as well as the Memory Unit will
be placed in an area where temperature and humidity data are
required. The device will obtain measurements for 6 months after
which the client will return to the device and remove the Memory
Unit. The Memory Unit will then be docked with the PC interface unit
which is connected to a PC. The measurement data will then be
downloaded to the PC where it will be processed. By creating
separate units a potential customer has greater flexibility when
purchasing and using the product. For example a consumer wishing to
purchase multiple systems will only be required to purchase a single
PC Interface Unit. Further, if long term measurements were required a
user could simply refresh the Measurement Unit after 6 months have
elapsed. The versatility of the system when separated into units
cannot be emphasized enough.

Page 23 of 84
3. Implementation:
3.1 Measurement Module:

The Measurement Module consists of the Measurement

Unit and the Memory Unit. This module is placed in the field and will
operate for a period of 6 months. During this period the unit is
required to obtain time stamped temperature and humidity data.

3.1.1 Measurement Unit:

The Measurement Unit is tasked with gathering time
stamped temperature and humidity data. The major limiting factor in
the design of the measurement unit is power consumption.

Temperature and Humidity Measurement:

Temperature and Relative Humidity (RH) are very closely

related, with RH being dependent on temperature. If temperature
increases or decreases then the saturation vapor pressure has a
corresponding change, consequently there is a change in RH.
This change is due to a directly proportional relationship between
saturation vapor pressure and RH. Hence any slight change in
Temperature, especially at high humidity levels, has a significant
effect on relative humidity. For example a 1°C change at 50°C and a
RH of 80°C results in a 4% change in humidity. It would thus be an
advantage to have both the temperature and RH sensors in as close
proximity as possible to obtain an accurate relationship between
the two environmental conditions by avoiding the temperature
Gradient that would exist between two separate sensors. The
Spenserian SHT71 offers the closeness of Sensors that are required as
both are present on the same chip. This also minimizes the
component count and hence reduces hardware complexity.

The most accurate humidity measurement instruments

available are chilled mirror hygrometers. However, these devices
are extremely expensive and used rather as a reference for the
calibration of High precision sensor components. The best accuracy
available on the market comes with the calibrated sensor probes and
this is approximately 1.5% RH. Unfortunately, these sensors require
frequent recalibration. The SHT71 is a capacitive sensor with accuracy
between 2% and 3.5%. This may not be as accurate as the sensor
probe but it does not require frequent recalibration and for this
Particular application such high levels of accuracy are unnecessary.
Resistive sensors do not offer the same accuracy for RH
measurements, typically providing 3% to 5% accuracy. These sensors
are also more suited for use in non-condensing environments. The
temperature sensor on the SHT is also capacitive and provides an
accuracy of +/- 0.4°C at 25°C. Negative Temperature Coefficient
(NTC) thermistors and platinum Resistive Temperature Devices

Page 24 of 84
(RTD’s) are capable of a higher accuracy, offering 0.05°C-1.5°C and
0.1°C-1°C respectively, however for this application such high
accuracy is not imperative. Platinum RTD’s shortfall is in that it has a
very slow response time 1s-50s, unlike the SHT which has a response
time of between 5s and 30s. Thermistors are not perfect neither do
they perform very well in environments with significant moisture.
They are also prone to self-heating and are therefore not being
suitable for this design. The SHT71 was found to be the best suited for
application in this design.

The SHT71 has very low power consumption, approximately

30µW. This is integral to the overall objective of reducing power
requirements to meet the 6 month lifespan of the device. Another
major advantage of this sensor over the others is that it provides a
digital output. This allows for a simple two wire method of
communicating with the device. Since the analogue to digital
conversion takes place within the chip it reduces the risk of the data
being distorted by noise. The only shortfall of the device is its cost
and is by far the most expensive component employed.

The Sensor Configuration:

It was decided that the sensor would be setup to output

temperature data in a 12 bit format and RH in an 8 bit format. This
provides the microcontroller with a 0.04 temperature resolution and a
0.5 RH resolution. Temperature accuracy of the sensor varies with an
increase or decrease from 25°C, reaching levels of up +/- 1.25°C at
50°C whilst RH is stable at an accuracy of +/-3% over a wider range
of values, 20% to 80% RH. These accuracies are independent of
resolution as they are merely characteristics of the sensor itself that
cannot be altered.

The sensor and the microcontroller interact using 2

wire communication; hence only two pins on the microcontroller
are required. One of the pins will be used to create a synchronous
clocking signal whilst the other will be used for bidirectional
data transfer between the two devices. The pin on the micro-
controller that is used as the data line must be stable; hence the line
must be pulled up in order to prevent signal contention.

Page 25 of 84
 The sensor requires no other
peripheral hardware except for a
source, decoupling and connection
to the microcontroller.

Communicating with the Sensor

Overview

As previously stated the sensor

uses a two wire method of
communication. In order to interact
with the sensor a specific sequence
of events must be followed. The
flow chart alongside illustrates the
general order of events to be
followed to request the sensor to
take measurements and read the
information placed on the Data Line
by the sensor. The protocol used for
sensor communication is discussed
in detail in the sections to follow.

The Transmission Start

Sequence

At the start of a transmission

session with the sensor the
microcontroller has to initiate a
specific series of high and low
signals on the Data Line,
corresponding to the synchronous
clock. A transmission start
sequence is generated by pulling
the Data Line low during a positive
clock pulse and then releasing
the line on the following clock
pulse. The timing diagram in Figure
5 is a graphical representation of
this sequence.

Transmitting a Command:

Page 26 of 84
 Following the transmission start sequence a command can be
sent to the sensor. There is a limited set of commands available for
communicating with the sensor. Attached to the upper byte are three
address bits, which for this sensor, has to be set to ‘000’, as these are
the only address bits that are currently supported. The sensor will
acknowledge the reception of the command by pulling the Data Line
low on the falling edge of the 8th synchronous clock (SCK) and
releasing the line on the falling edge 9th SCK. The following timing
diagram demonstrates the command signal transmission as well as
the transmit start sequence. It should be noted that all data is sent
and received MSB first.

Measurement Process:

Page 27 of 84
 Once the microcontroller issues the command for the sensor to
measure RH it then has to wait whilst he sample is taken and the SCK
must be stopped. When the sensor has finished taking the reading it
pulls the data line low. Only then can the microcontroller start the
SCK once again. On the 5th SCK the sensor starts transmitting the
measurement data. After each byte is received the microcontroller
must end an acknowledge signal. Since the RH measurement, with
the current sensor configuration, is 8 bits then the sensor will transmit
one byte of zero’s and one byte for the actual data. Naturally only the
lower byte is stored and once this last byte is read in, sensor
transmission is stopped by omitting the final acknowledge signal.
Temperature sampling can then be requested by first sending
the transmission start sequence and then the command.
However, when the two bytes of data are downloaded from the sensor
both are used as the sensor is configured to send temperature data
as a 12 bit value. The upper nibble of the upper byte is set to zero
whilst the lower nibble contains the MSB’s of the temperature data.
Once this first byte is received by the microcontroller an acknowledge
signals sent to the sensor. Once this is achieved the lower byte
of data is then transmitted to the microcontroller and
communication with the sensor is ended. The timing diagram below
displays the sequence of flow of data.

Implementation of Sensor Communication:

Page 28 of 84
 The sensor has a specific protocol that has to be adhered to, in
order to be able to interact with it. This makes the communication
process more complex as receive and transmit procedures together
with acknowledge detection and transmission and clock signals have
to manually coded. It was thus decided that the communication
sequence would be broken down into smaller sections that could be
tested individually for correct execution rather than endeavoring
to write code for the entire communication process and
attempting to test the whole code. This allowed any errors in
programming or incorrect sequence of events to be quickly identified
and rectified.

The first task that required accomplishment was to

send a transmission start and then attempt to send a command to the
sensor. Successful completion of this task would be denoted by an
acknowledge signal from the sensor. This was a crucial first step in
the communication process as it would affirm the understanding of
the sensor protocol and mean effective interaction with the sensor
could be achieved. Fortunately, this task was successfully completed
without complications and progress with the sensor followed quickly.
The first command issued was to write to the status register and once
the acknowledge signal was returned to the microcontroller, the value
needed to configure the sensor was written and again the sensor
returned an acknowledge signal. This process of writing to the status
register was then converted to a callable routine. The method of using
functions and calling these subprograms was implemented for all the
operations of reading and writing to the sensor. This allowed for the
sensor code to be easily integrated into the overall system code.

A routine was created which sent the command to the sensor to

measure the temperature or humidity, depending on what was
requested. This subprogram also made use of two other routines that
were employed specifically for reading in 8 bits of data from the Data
line and placing 8 bits on the line. Both these programs were
individually tested by using them in writing to and reading from the
status register. The entire measurement routine was tested by
placing the returned measured values on a port and displaying this on
LEDs.

It was found that in working with the sensor and testing the
code a delay should be included between measurements to prevent
the sensor from heating up and producing inaccurate results. When
this problem occurred during the testing process a full connection
reset was performed on the sensor that reset all registers as well as
the serial interface. After this reset was carried out the status register
was reinitialized before measurements were taken.

Page 29 of 84
Testing the Sensor:

After the correct functioning of the code was tested, the ability
of the sensor to take measurements had to be qualitatively
investigated. These tests were crude and not calibrated but were
done with the intention of checking that if the ambient humidity or
temperature was increased or decreased then the sensor would
reflect an increase or decrease. The humidity change was effected by
exhaling on the sensor when a measurement was being taken. It is
known that exhaled air has high moisture content thus the humidity
reading, taken when the sensor is exposed to exhaled air, should be
elevated when compared to humidity of the room. The temperature
reading change was evoked by placing the sensor close to a
transformer that had become significantly hot during the process of
its operation and subsequently increased the temperature of the
surrounding air. Both these tests proved to be successful, proving
that the sensor was operational. More precise, calibrated tests were
carried out on the functioning of the measurement module in its
entirety and these tests will be discussed in Module Tests (Section 4).

Time Stamping:

In order to satisfy the task of time stamping sampled data,

a device which can keep time is required. Such a device is a real time
clock (RTC). A real time clock can be programmed with the actual
time during the product manufacture process and then keep time for
a substantial period. In a battery operated system, like a data logger,
a Low Power RTC is required. The RTC is required to transmit the
time from its internal registers to memory, via the microcontroller, in
order to time stamp the data. As such, the RTC is required to support
communications with a Microcontroller.

Real Time Clock Features:

There are a wide range of real time clocks available, with

different functions. Many real time clocks only keep time and upload
this time to the system. Other real time clocks have features like
programmable alarms, multiple power supply connections and trickle
charging. The selection of real time clock is important as the different
features available allow for different implementations of the data
logging system.
Programmable alarms allow the RTC to send a signal to a device like a
microcontroller on certain time match conditions. This feature allows
for the design of a system where the real time clock controls the
timing of data requests and data acquisition through interrupts
generated when the alarm is activated.

Page 30 of 84
 The selection of a real time clock is important as the different
features available allow for different implementations of the data
logging system. The group has decided on the Maxim DS1305 RTC,
which is discussed in the next section.

The DS1305 Real Time Clock:

The DS1305 offers low power consumption and two

programmable alarms. The alarm function is attractive as it allows
for the option of making the data logger interrupt driven, with
the microcontroller and sensor in power-down modes until an alarm
occurs. Communication with the microcontroller takes place through
three-wire interface or Serial Peripheral Interface, depending on the
capabilities of the microcontroller.

Three separate power supply configurations are available. Two

of the three configurations allow for the connection of a backup
battery in addition to the main power supply of the system; the third
method uses only a single battery to power up the real time clock.
This single battery method is the most power efficient method
available on the DS1305. Using the dedicated battery to power up the
DS1305 makes it possible to program the time into the real time clock
once during the data logger manufacturing process only. Once the
time has been written to the real time clock, the DS1305’s internal
algorithms controls timekeeping and alarm activation. Therefore, the
consumer is not required to enter time or date settings at any point in
the product life.

Power Comparison between Methods:

In order to compare the microcontroller based real time clock

and a dedicated real time clock, the currents drawn by each method
are compared.

The power calculations for the two methods are included in

Appendix A. The results yield a current consumption of 92.4µA for the
dedicated real time clock and 2mA for the microcontroller based
method. The current drawn for the real time clock is approximately 20
times less than that for the microcontroller based method. It is
apparent that in terms of power the dedicated real time clock is a
superior method.

Page 31 of 84
Hardware:

The real time clock requires a continuous power supply in order

to keep time. This requirement would increase the power
consumption of the device if it was connected to the system’s main
power supply. The real time clock, and any components necessary for
its operation, is therefore connected to a dedicated battery. As the
DS1305 requires a minimum of 2V to operate, the Vcc2 pin is
connected to a single 3V lithium ion battery.

The selected battery for the real time clock is the CR2016. The
CR2016 is rated at 90mAh at 2.0 volts. At this voltage, the real time
clock draws AI average=0.3 µA. Ignoring the non-linear voltage-
capacity
Behavior of the battery, the expected service life of the battery can
be calculated by:

The above figure translates into 34 years; however, the non-

linear behavior of the battery, coupled with climatic changes which
were ignored in the calculations implies that the battery will not last
for the calculated service life; however, it is capped at a shelf life of
the CR2016 which is 20 years.

Figure 8 below represents the hardware configuration of the

DS1305 real time clock. For simplicity, only the connections between
the microcontroller and the RTC are shown.

Communication between the DS1305 and the ATmega16L is

done via the Serial Peripheral Interface. . The microcontroller is the
master device, and as such, controls the timing of the
communication. The clock pulse is generated on the “SCK” pin of the
ATmega16L. The master uses the slave select (“SS”) pin to enable or
disable data transfer between itself and the RTC. The “MOSI” and
“MISO” pins of the microcontroller are used to clock out or clock in
data respectively.

Page 32 of 84
 Data Transfer between the Real Time Clock and the
Microcontroller:

The real time clock is

programmed once
during the
manufacture of the
data logger but is
accessed at
subsequent intervals
whenever the data
time stamp is
acquired. Integrating
the real time clock,
however, was
accomplished by first
implementing the SPI
protocol between two
microcontrollers which
is illustrated in the
following flow diagram.
Figure 9: SPI test procedure
between two .
microcontrollers

The SPI protocol involves the process

where one device must be configured as the
master and the other device being the slave.
The test was conducted by the team to
investigate the success in the transmission and

Page 33 of 84
reception of a byte of data (“main_data” in the above diagram). It was
effectively noted that “main _data” in the data register (SPDR) of the
slave device is ‘shifted’ to the master device only when the master
transmits an arbitrary byte of data (“arb_data”); this concept is
described in Figure10.

The idea of data transmission between a master and its slave can
be thought of as using a single 16-bit shift register. The slave clocks
out the data byte to its master when the master transmits the next
byte of data.

Figure 10: Data transfer between the master and slave.

Programming the Real-Time Clock:

Programming of the real time clock is performed as

part of the manufacturing process; hence the time and date settings
are not required to be entered by the user on initial start-up or any
subsequent start-ups. In the programming process, the time is written
to the appropriate registers in order to initialize the DS1305. For
timekeeping purposes, the seconds, hours, minutes, day, month and
year registers are written to. Timekeeping is done in the real time
clock’s internal registers and the current time is stored and read in
binary coded decimal (BCD) format. The initialization process of the
real time clock is shown in Figure 10.

Page 34 of 84
 In terms of the SPI protocol, the microcontroller is configured as
the master whilst the DS1305 real time clock is considered as the
slave device. Each time data byte (seconds, hours, minutes, day,
month and year byte) transmitted is preceded by its corresponding
RTC register address byte and this explains the reason for the
procedure “Transmit_data” being called twice. The RTC byte write
process is illustrated by the timing diagram in Figure 11 where ‘A’
represents the address byte and ‘D’ the data byte.

The initialization process includes writing to the RTC control

register to enable the alarm function and start the clock by enabling
the oscillator.

Page 35 of 84
Real-Time Clock Alarm functions and Read procedure:

The alarm feature of the DS1305 was used to effectively ‘wake

up’ the microcontroller in an hourly event and subsequently retrieve
the measurement samples from the sensor.

The setting of the ‘Alarm Interrupt Enable’ bit in the RTC’s

control register and the ‘Time of Day Alarm Mask’ bits generates an
active low alarm signal at time periods determined by the mask bits.
For instance, in the data logging demonstrating process it would be
efficient to generate an alarm interrupt every minute; whereas the
final product involves an hourly alarm interrupt.

The active low alarm signal requires an external pull-up resistor

which is provided by the internal pull-signal is up from the port pin on
the microcontroller. During each interrupt routine, the ‘low’ 0NTI
converted to a ‘high’ signal by writing to the RTC’s alarm register; this
procedure is done so as to disable the current alarm interrupt and
permits the execution of the next interrupt.

The real time clock read procedure (shown in Figure 13

below) takes place whenever the current timestamp is requested by
the microcontroller.

Note that the “Transmit_data” procedure is invoked twice as the

microcontroller reads the time-stamp data from the real time clock by
first transmitting the addresses of the corresponding time-field
registers, followed by transmitting an arbitrary byte.

Page 36 of 84
 The timing diagram for the SPI single byte read process is
illustrated in Figure 14 below.

Control:
Product Selection:
A microcontroller carries out all its tasks concerned with
the system control. The ATmega16Lproduced by the Atmel
Corporation was chosen for implementation primarily due to its
availability.
This is a low power device whilst having all the required
I/O functionality required to handle communication between the
other IC’s in the system as well as satisfying program memory
requirements. The ATmega 16L was, however, not the group’s first
choice. The MSP430 series manufactured by Mixed Signals
Controllers is a superior microcontroller in terms of power
consumptions with its active current requirement being a quarter of

Page 37 of 84
the ATmega16L. However, the decision to implement the ATmega16L
was based on Atmel’s release of their Pico Power Range. The device
known as the ATmega165p offers active and standby current which
are far superior to bothATmega16L and the MSP430 as well as
offering greater functionality in terms of program memory and I/O
ports. The implementation of the ATmega165p would significantly
reduce power consumption, however procurement of the device has
been difficult since it was launched in early March 2006. Thus by
using the ATmega16L the group would be able to upgrade to the
ATmega165p
with relative ease since both products are from the same family
of Atmel’s 8 – bit RISC microcontrollers.

Implementation Issues:

The hardware setup of the microcontroller was based on

the manufacturer’s recommendation documented in Atmel
application note “AVR042: AVR Hardware Design Considerations”. The
circuit diagram illustrating the microcontroller’s implementation is
depicted in the complete circuit diagram Figure 23. In order to reduce
the time taken for the micro-controller to transition from power down
mode to active mode a ceramic resonator was employed as an
external clock source. Further the microcontroller will be operated at
a frequency of 1 MHz in order to reduce power consumption. The
software issues relating to the microcontroller are discussed in
section 2.1.3.2.5.

3.1.2 Memory Unit:

The Memory Unit is an integral part of the measurement

module as it provides storage capability. The tasks and constraints of
the Memory Unit are illustrated in Table 4.

Page 38 of 84
Sampling Rate:
The sampling rate refers to period between each pair of
temperature and humidity measurements. The decision on the
device’s sampling rate was taken in conjunction with the researchers
who would use such a product, as the sampling rate is an important
criterion during research. The aim of the group was to select a
sampling rate which achieved a balance between power consumption
and data integrity.
Using an iterative process based on individual power consumptions, it
was found that an hourly sampling rate would provide the optimum
balance.

Data Storage:
Data storage refers to the process in which data is stored
in order to provide 6 months of time stamped measurements. There
are two types of data used in the system, time stamp data and
measurement data i.e. temperature and humidity data. Selection of
an optimum data storage process would not only reduce power
consumption but would also minimize the total memory required to
store 6 months of time stamped data. Memory is an expensive
commodity and its efficient usage will minimize the system costs.

Measurement Data:

The temperature and humidity sensor Sensirion SHT 71

provides temperature data in a 12 bit format. However, this caters for
a range of -40°C to 124°C, which is larger than the specified range of
this device.

Since the efficient use of memory space is integral to the

design of the device it was decided that this 12 bit format will be
reduced. This is possible because the raw data output of the sensor is
already scaled up by 25. Thus to obtain the actual temperature it is
required that the output of the sensor be divided by 25. However,
division in the microcontroller requires a large amount of processor
power which is not very efficient as well as the fact that division will
result in floating point numbers, requiring more than 12 bits of space
and thus defeating the point of reduction. Instead a shift operation
will be implemented that will involve a shift left of 5 bits resulting in a
final data length of 6 bits, as bit 11 is ignored since the temperature
of the unit measures a maximum of 50°C. This results in a resolution
of 1.28°C and a worst case accuracy of 1.4°C at 25.4°C. The humidity
data is received by the microcontroller in an 8 bit format. Similarly to
the temperature data this is reduced to 6 bits which results in
resolution of 2% and a worst case error of 4%, which is within
specifications.

Page 39 of 84
 Thus during every hourly cycle 12 bits of data would be
saved. Over a period of 6 months (183 days) with an hourly sampling
rate, 6588 bytes of memory would be required. Although this
requirement is high and compression methods exist to reduce this
number the group chose not to do so. (The compression method
investigated by the group was a method where data was only stored
if its value varied by certain figure from the previous data). The
reasons for this decision are as follows: the sampling rate is low by
design decision and further degradation of this may reduce the
integrity of the data. Use of compression methods often result in a
memory requirement which varies depending on the researched
environment. In order to guarantee 6 months of operation the group
would have to implement a worst case approximation of the memory
requirement. This would nullify the effect of the reduction process.
Further, a variable memory system would not allow for the simplistic
method of time stamping addressed in the following section.

Time Stamped Data:

The accurate time stamping of data is essential for data

integrity. However, the real time clock, DS1305, supplies up to 7
bytes of data per time stamp. Use of these 7 bytes, hourly, would
result in excessive memory usage and a memory efficient process
was required.

Initially the group proposed the use of a base time stamp

which could be offset depending on the number of a specific sample.
The alarm function provided by the RTC would be used to ensure that
samples are taken hourly, thus the number of any specific sample
could be used as an offset from the base time in order to provide an
accurate time stamp. However, it was decided that the use of this
method posed substantial risk to the integrity of the data. If the
microcontroller were to not respond to the alarm of the RTC an hourly
sampled would be missed and the entire data set would be offset. The
group thus modified the process, by obtaining the hour data from the
RTC every eight hours hence allowing regular time stamp
synchronization and eliminating the risk of losing six months of data.
Thus if the microcontroller were to skip an hourly sample the worst
case offset would be eight hours. The operation of assigning data sets
individual time stamps is carried out during the processing of the data
in a PC and is thus discussed in detail in the appropriate section.

Thus the memory requirement for time stamp data over a

six month period is 550 bytes. Combining this requirement with the
Data storage requirement of 6588 bytes yields a total memory
requirement of 7138 bytes.

Page 40 of 84
Physical Implementation:
Memory Options:
The options for data storage included the use of a Multimedia
Card (MMC), a Secure Digital Card (SD) or Electrically Erasable
Programmable Read Only Memory (EEPROM).

MMC and SD cards presented an attractive option to store data,

as cards are easily removable and replaceable when the end-user
requires the data. The cards also remove the user from dealing with
the internal hardware of a more complex memory system. The issues
surrounding the implementation of a MMC or SD card included the
high current consumption (approximately 150mA) of the device and
the requirement of File Allocation Table (FAT) 16 formatting. To
implement FAT 16 formatting a microcontroller with large program
memory, and thus large power consumption, would have been
required.

EEPROM offered lower power consumption than the MMC/SD

card alternative. Parallel communication EEPROM has shorter read
and write times than serial EEPROM. Serial EEPROM, however,
required fewer pins on a microcontroller, which allowed or the
use of a smaller microcontroller with lower power consumption.

The group chose the Atmel AT24C64A as the EEPROM device for
implementation based on its low power consumption and capacity.
The physical implementation of the EEPROM is designed to emulate
the operation of MMC/SD cards.

Hardware:

The group achieved the emulation of the MMC functionality by

attaching male headers to a printed circuit board and female
headers to the appropriate part of the PC Interface and
Measurement Modules.

Page 41 of 84
 The AT24C64A is a Two Wire Interface (TWI) device
communicates via this protocol with a master device, such as a
microcontroller. The master device is responsible for the control of
the communication timing and the flow of data. In order to interface
the EEPROM to the microcontroller, a pull-up resistor is required on
each of the Two-Wire lines. Figure 16 shows the physical interface
between the EEPROM and the microcontroller. For simplicity,
connections to other devices such as the main power supply and
other components are not shown. The connections shown in red
indicate the use of the microcontroller’s pull-up resistor.
The EEPROM requires a minimum of 1.8V for proper operation and
any voltage below 1.8V results in the EEPROM entering write protect
mode.

Power Consumption:

The average current consumed by the EEPROM from the main

power supply is 2.83µA. Appendix A shows the detailed power
calculation for the EEPROM. Of all devices connected to the main
power supply, the EEPROM is the second lowest consumer of power.

Page 42 of 84
Writing to EEPROM:

Writing to EEPROM involved the use of TWI, with the EEPROM

setup as a slave device and the microcontroller setup as the master.

Memory Mapping:

In order to efficiently use the available memory, as well as aid

in the writing process, it was decided that the measurement data
would be manipulated before storage. After every pair of hourly
samples there will exist four 8 bit registers containing six bits of data
each. The 6th bits of data in the 4 register will then be split between
groups of two bits. Each group of 2 bits will then be added to the
other 3 registers in a specific order. The process has been done in a
manner which will allow for the data to be recombined when the
downloading process were to take place. The process is most simply
described by the following diagram.

Figure 18: Figure Illustrating the Data Manipulation Procedure

The memory map is used to illustrate the addressing structure of the

memory. The measurement data comprises of 4 bytes, two hourly
samples of temperature and humidity which have been modified to
use 3 bytes of memory space.

Page 43 of 84
3.1.3 System Operation:

The overall flow of the system is designed to efficiently use the

individual components in order to achieve the desired system
operation. This is achieved by combining the functions discussed in
the previous section.

Memory Map of the AT24C64A Serial EEPROM

Tasks Required:
The tasks involved in the system are as follows:
• Sampling and Storage of Base Time Stamp
• Sampling and Storage of Synchronization Time Stamp
• Sampling Temperature and Humidity

Page 44 of 84
• Manipulation of Temperature and Humidity Data
• Storing of Temperature and Humidity Data
• Sample Counter
Sampling and Storage of Base Time Stamp:

This task is only carried out each time the device takes its first
sample. The task can be further broken into three functions:

• Request Time Stamp – the process in which the microcontroller

requests year, month, and date and hour data from the RTC.
• Download Time Stamp – the process where the RTC transmits
the requested data to the microcontroller.
• Store Time Stamp – the process of writing the downloaded data to
EEPROM.
Sampling and Storage of Synchronization Time Stamp:

The process of obtaining the synchronization time stamp is

similar to the previous process except for two differences, these being
that only hour data is requested from the RTC and the request
download and storage of this data to EEPROM takes place every 8
hours. The following functions were used:
• Request Synchronization – the process in which the microcontroller
requests hour data from the RTC.
• Download Synchronization – the process where the RTC transmits
the requested data to the microcontroller.
• Store Synchronization –the process of writing the downloaded
synchronization data to EEPROM.
Sampling Temperature and Humidity:

In order to achieve the sampling rate this task must be carried

out hourly. The functions used in order to carry out these tasks are:
• Request Temperature - process by which the microcontroller
requests temperature data from the temperature and humidity
sensor.
• Download Temperature - the process where the temperature and
humidity sensor transmits the requested temperature data to the
microcontroller.
• Request Humidity - process by which the microcontroller
requests humidity data from the temperature and humidity sensor.
• Download Humidity - the process where the temperature and
humidity sensor transmits the requested humidity data to the
microcontroller.
Details of these functions including the associated error handling
provided by the sensor have been discussed in the relevant section.

Page 45 of 84
Manipulation of Temperature and Humidity Data:

This task is accomplished by a single function previously

discussed in the section on memory. The function is used to convert 4
bytes of measurement data into 3 bytes before storage to EEPROM
takes place. Since 4 bytes of relevant data will be available after 2
hourly samples, this function will only be called every 2 hours.

Storing of Manipulated Temperature and Humidity Data:

The task of storing the manipulated temperature data is done

by a single function. This function will be called immediately after the
Manipulation of Temperature and Humidity Data function and will thus
run every 2 hours. A counter will be used in this function in order to
point to the required address in EEPROM. Since three bytes are being
stored the counter will increment by 3 every time the function is
called.

Microcontroller Operation:

The microcontroller will be used to control the use of the

functions described in the previous section. Since the system will only
sample data hourly the microcontroller can remain in a power down
mode for the majority of the system operation. The power down mode
is a low power mode where all unused modules of the microcontroller
are shut down thereby saving power. However, in this mode the
external interrupts are enabled allowing the microcontroller to enter
active mode on command.
Thus the microcontroller will operate in 3 modes:
• Initialization
• Active Mode
• Power down Mode

In order to use the microcontroller in a power down mode an

entirely interrupt driven system is required. The interrupt source will
be provided by the RTC, which by design decision has been selected
with an alarm function. The RTC can be set to provide this interrupt
signal hourly thus allowing the microcontroller to carry out the tasks
required to achieve an hourly sampling rate. The flow diagram below
illustrates the 3 modes of operation.

Page 46 of 84
 Flow Chart Illustrating States of the Microcontroller

The initialization process will be carried out each time the

system is powered up. It involves the setting of all ports and the
required interrupts as well as setting all counters to the desired initial
condition. On completion of this process the device enters power
down mode. The device will enter active mode hourly and execute the
interrupt routine. In this routine all the required tasks are performed.
The Interrupt Routine (ISR) is discussed with reference to Figure.
Upon entering the ISR the number of samples obtained is first
checked to determine if any previous samples have been taken. The
reason for this procedure is to allow for the base time stamp to be
taken on the first sample only. If no previous samples have been
taken the system will then carry out the tasks required to obtain the
initial base time stamp. Functions for the requesting and download of
temperature and humidity are then called. Once this is achieved a
counter is incremented which indicates that the tasks of sampling
temperature and humidity data have been completed. This counter is
then checked to determine if its value is equal to 43933. If so, then 6
months of samples has been completed and the system is disabled,
otherwise normal operations commence. This is done in order to
prevent the overwriting of stored data in EEPROM as the power supply
is designed to operate for periods in excess of 6 months, in order to
ensure the desired system requirements.

The manipulation and storage of data only takes place after two
samples have been taken. Thus if the sample counter is exactly
divisible by two the process of manipulating and storage of the
temperature and humidity data will commence. On completion of this
task the sample counter is tested for divisibility by 8. This test allows
for the process of time stamp synchronization to take place every
8hours. Once all processes are completed the system will also return
to power down mode.

Page 47 of 84
Hourly Interrupt Routine

Page 48 of 84
3.1.4 Complete Circuit Diagram:
Using the requirements of the individual components the
complete circuit diagram of the measurement module was created.

Complete Circuit Diagram of Measurement Module

Power Budget:

Here we use the normal 230VAC power supply for the data
logger operation.

Page 49 of 84
3.1.5 Construction of Measurement Module:

On completion of testing and verification of the individual

components, the process of integration commenced. This process was
broken down into phases where devices were connected one-by-one
to the microcontroller and all connections were done on bread board
with the microcontroller on a STK 500 development board. The first
phase involved the use of the RTC to generate an interrupt and within
this interrupt time stamp data was requested and downloaded. A
simple serial port routine was written to allow the data to be viewed
on a PC. For testing purposes the RTC was programmed to generate
an interrupt every minute as this allowed for a more practical testing
process. In phase 2 the temperature and humidity sensor was
connected and the functions for the request and download of the data
were included in the interrupt routine generated by the RTC. Again
the downloaded data was transmitted to a PC where it was validated
by comparison to an independent sensor. Phase 3 involved the
connection of the EEPROM and the storage of data to the device
within the interrupt routine generated by the RTC. In order to test for
the successful storage of data, a routine which could read from
EEPROM and transmit data to the PC was created. This phase of
testing did pose significant problems as the group was unable to write
data to the EEPROM. It was discovered that this problem was caused
by a faulty bread board track which prevented the write protect pin of
the EEPROM from being correctly set. Phase 4 involved the
programming of the microcontroller routines for manipulation of
the data as well as the setting of the requirement counters in order to
allow for the required functions to be called in their specific
sequence. The required EEPROM data was downloaded to a PC for
validation, which once successful marked the end of the prototyping
phase for the Measurement Module. This allowed for PCB’s to be
designed manufactured and produced.

3.2 PC Interface Module:

The PC interface module consists of units which allow the client

to conveniently retrieve the data samples stored in memory. Since
the PC serves as a medium between the client and the product, it is
imperative that a suitable Graphical User Interface be developed
to ensure a user friendly environment. Client preferences and
product reliability are considered indispensable to the design team;
therefore the form of data communication between the PC and the PC
interface unit had to be thoroughly reviewed.

3.2.1 Hardware Requirements:

It is essential, in the design, to implement a simple and efficient

method in which the data would download from the memory module
to the PC at the request of the user. The PC Interface Unit provides a

Page 50 of 84
bridge between the Memory Unit and a PC. The Memory Unit is
connected using the standard two-wire interface. However, the
connection between the PC Interface Unit and the PC required careful
consideration. Two such options were considered, namely the serial
port and the Universal Serial Bus (USB) port. Whilst the serial port
does provide the benefits of cost efficiency as well as a simplistic
implementation, it has a major disadvantage - the serial port is being
phased out and most laptops no longer provide this port.

The USB interface was chosen due to the ease with which the
USB peripheral device (in this case, the PC interface device) is
“automatically” recognized and configured by the PC. This
communication interface benefits the user as it results in the
compatible PC interface device being a “plug and play” device.
Another advantage of implementing the USB interface is the fact that
the PC Interface Unit would not have to contain its own power supply.
The only period at which the device would be in use is when data is
being downloaded; this implies that the module can be powered off
the PC via the USB port.

There are various ways in which USB communication can be

implemented; hence the design team considered each possible
avenue. One of the options was to implement a microcontroller (for
the PC interface module) which has an embedded USB interface. This
however results in a costly design solution.

The most cost effective solution is to use a standard 8-bit

microcontroller which will be programmed to handle all protocol
requirements. However, development of such software would be time
consuming and problematic. Further, the group would be required to
create its own PC drivers. The group decided to instead use a UART to
USB interface device, as it requires minimal programming and
provides a complete solution, including drivers, for a relatively low
price. The group selected the FT232RL USB-UART IC. This product,
manufactured by Future Technologies, handles all protocol
requirements in order to interface to a USB port. Drivers for the
following operating systems will be provided, thus making the system
compatible with virtually any computer with a USB port:

• Windows 98, 98SE, ME, 2000, Server 2003, XP.

• Windows Vista / Longhorn*
• Windows XP 64-bit.*
• Windows XP Embedded.
• Windows CE.NET 4.2 & 5.0
• MAC OS 8 / 9, OS-X
• Linux 2.4 and greater

The device has been designed in order to allow simple integration

with any microcontroller that has a UART function. The chip, in

Page 51 of 84
conjunction with its associated drivers, creates a virtual
communications port which allows the PC to interface with a
microcontroller as if it were using a standard serial port. Figure
illustrates the hardware configuration of the PC Interface Unit and
Memory Unit.

The ATmega16L microcontroller was chosen on the basis of its low

cost and familiarity (as it is also implemented in the measurement
module). The MCU, FT232RL and AT24C64A (EEPROM) are each
powered off the PC via the USB port.

3.2.2 The Download Procedure:

The download procedure is the process from which the client

initiates the download event (through the PC GUI) to the point at
which all the data stored in EEPROM is saved in a particular format on
a PC. It requires minimal user interaction through the Visual Basic
GUI, thus creating a user friendly environment. The procedure
consists of the following modules which are discussed in greater
detail:
• Communication Protocol
• The Visual Basic Graphical User Interface
• USART communication
• Actual download procedure
• Data manipulation

Communication Protocol:

The communication protocol implemented by the design team

is substantially different to that of the original design. The group
initially proposed the use of y checking as means of error handling.

However, as this method provides only limited capabilities

alternatives were found. Further, the original protocol lacked
handshaking mechanisms which were also redefined. In order to
increase efficiency the protocol was designed to handle blocks of data
instead of single bytes. The modified protocol has been designed to
handle two data types:

Page 52 of 84
Hardware configuration of the PC interface unit and Memory Unit

• Initialization Data – six bytes of data containing the total number of

samples taken as well as the base time stamp data. The diagram
below illustrates the initialization data block.

Page 53 of 84
 Initialization Data Block

Measurement Data – 12 bytes of data, containing eight hours of

temperature and humidity data as well as the synchronization time
stamp as illustrated below.

Measurement Data Block

Error Handling:

One of the major tasks of the protocol is to provide error

checking of the transmitted data. The error check is accomplished by
adding a check sum byte to each block of data. The check sum value
is computed by adding the numerical value of each byte in the data
block and storing only the lower 8 bits of the accumulated value. The
check sum is then appended to the data blocks before transmission
as illustrated below.

Page 54 of 84
Handshaking:

Handshaking is employed in order to ensure that the receiver

and transmitter are synchronized. This is accomplished with the use
of an acknowledge byte. The receiver transmits the acknowledge byte
in order to indicate to the transmitter that a block of data has been
received correctly i.e. the checksum value computed by the receiver
equals the

USART Communication:

The ATmega16L USART feature allows data to be transmitted in

both directions (commonly known as half duplex operation).
Asynchronous transmission was chosen over synchronous
transmission as a separate clock signal and data line is not required.
The TXD and RXD pins on Port D are used for the transmission and
reception of data respectively. Checksum value received.

Data Blocks with Checksum

The process of serial communication involves the

initialization of parameters such as type of transmission, baud
rate and number of bits transmitted (including the start, stop and
parity bits). The baud rate indicates the number of bits that would be
transferred in one second. A baud rate of 19200bps was chosen. It is
vital that the PC and the microcontroller baud rates be equal for
proper data transmission. The PC is therefore configured through
Visual Basic with the same baud rate.

Page 55 of 84
The data consists of one start bit, the eight bits followed by a stop bit.
The start bit indicates that the next eight bits contain information.
The stop bit indicates that the information has been transmitted.

The above flow chart shows the initialization of the USART

(baud rate, asynchronous operation and frame structure). When the
download procedure begins, the PC would send a signal to the
microcontroller which activates the “receive” interrupt routine,
initializing serial communication. A check is then done to ensure that
no other data is stored in the buffer or is being transmitted. When the
buffer is empty, the data is transferred from a register to the transmit
buffer which is then transmitted to the PC.

Actual download procedure:

The sequence of events involved in the download procedure is
as follows:

The data download procedure.

Page 56 of 84
 The above diagram illustrates an ideal transmission sequence in
which all checksum values were verified correct. In the event that a
corrupted data block was detected by the PC, the PC would not send
an acknowledge signal and the entire block would have to be
retransmitted by the microcontroller.

The microcontroller tasks required to achieve the following

events are as follows:

• Download required Block of Data from EEPROM

• Compute Checksum for associated block
• Transmit block of data with checksum
• Wait for acknowledge

The downloading of the correct data from EEPROM was done by

implementing a counter which points to the required address in
EEPROM where data would be downloaded from. This counter is
incremented by six after initialization data is read and by 13 each
time measurement data is read from EEPROM. The process of waiting
for the acknowledge signal is accomplished using a timer-driven
interrupt. On completion of transmission the timer is started and the
system waits for the acknowledge signal. If the timer runs for a period
in excess of 50ms can interrupt would occur. This interrupt prompts
the microcontroller to resend the previous block of data. This process
is highlighted in the following flow chart.

Process describing block data transfer.

Page 57 of 84
 The diagram beside indicates the entire microcontroller
operation in the PC Interface Module. The PC works in conjunction
with the microcontroller to download data via the develop
communication protocol. The user initializes the download procedure
by clicking on the “Download” button on the GUI.
A start condition is then
transmitted to the microcontroller.
In turn, the microcontroller
transmits the data packet with a
corresponding checksum value
appended to it. The checksum
value is then recalculated on the
PC side and compared to the
checksum value that was received
with the packet. If these values
are equal, then an acknowledge
signal is transmitted to the
microcontroller to inform it that
the data received is valid.
However, if the checksum Values
differ, then the PC will discard
that data packet and an
acknowledge signal will not be
transmitted. This will cause the
microcontroller’s timer to “time-
out” and the microcontroller will
have to re-transmit the packet.

Microcontroller operation in the

PC Interface Module

4. Analysis of Design:

Testing has shown that the data logger works according to the
required specification. However, there are still areas of concern that
the group would have liked to have improved upon, given more time.

4.1 The Measurement Module:

Page 58 of 84
 A problematic area of the design related to the theoretical
calculations of the lifespan of the battery. Even though it was
calculated that the system would last for more than 6 months there
were numerous factors affecting the lifespan of the battery that could
not be taken into consideration. For example temperature effects and
impulse currents were not included in calculations; this was due to
the lack of information from the supplier. The only way in which the
theoretical calculations could be verified is to perform long term tests,
which is not a viable option in this case. In an attempt to counter the
uncertainty related to these calculations the group has added extra
cells to increase the effective rating of the battery and thus guarantee
the user with a period of 6 months of operation.

Another area of concern is related to the accuracy of the

stored data. Due to a design decision of minimum memory capacity,
an amount of accuracy in the measurement data had to be
relinquished in order to meet the memory constraint. However, if the
end user requires a higher level of accuracy the group proposed that
user settings be included, which would allow for the accuracy and
sampling rate to be selected from certain predefined combinations.
These predefined combinations would correspond to a different period
of operation for the device. Another solution to this problem is to
merely increase the size of the memory. However, this was not
implemented as it would defeat one of the group’s overall objectives -
cost reduction.

4.2 The PC Interface Module:

The PC Interface Module has two main areas that could be

improved upon, namely: protocol and error handling. An apparent
problem with regard to the protocol is that there is no procedure to
handle the case of a lost acknowledge signal. Currently, if the
microcontroller does not receive an acknowledge signal and its
internal timer expires, it retransmits the data packet to the PC. This
results in the PC having two identical sets of data. There are two
methods in which this problem could be solved. The first method
would be to compare synchronization bytes, since these bytes should
not be identical for two blocks of data. Once a duplicate block of data
is identified it can then be discarded. However, the best solution to
this problem would be to implement an Automatic Repeat Request
(ARQ) protocol which would ensure that a reliable data link is created.
The use of Checksum as a method of error checking, whilst
providing data protection, is not the best error checking method.
Cyclic Redundancy Checking error checking methods provide better
data protection by applying a more complex algorithm to the data to
obtain the final checking value. The PC Interface Module also requires
the user to install a Virtual Communications Port (VCP) driver onto
their PC. This process is quite complex for individuals with minimal
computer experience thus the group has created a detailed user

Page 59 of 84
manual in an attempt to alleviate any problems. The optimal solution
though would have been to create an installation wizard that would
eliminate any driver installation uncertainties. Another problem that
arose with the use of VCP was that the assigned communication port
varied from PC to PC. This problem was addressed by having the user
manually enter the communication port being used upon request by
the software. A better solution, however, would be to create an auto-
detect sequence that would be capable of updating the port number
in the software without requiring input from the user. This would
create a self-sufficient initialization procedure which is highly
desirable.

4.3 RS-232 COMMUNICATION:

INTRODUCTION:

Line drivers and receivers are commonly used to exchange data

between two or more points (nodes) on a network. Reliable data
communications can be difficult in the presence of induced noise,
ground level differences, impedance mismatches, failure to effectively
bias for idle line conditions, and other hazards associated with
installation of a network.

The connection between two or more elements (drivers and

receivers) should be considered a transmission line if the rise and/or
fall time is less than half the time for the signal to travel from the
transmitter to the receiver.

Standards have been developed to insure compatibility

between units provided by different manufacturers, and to allow for
reasonable success in transferring data over specified distances
and/or data rates. The Electronics Industry Association (EIA) has
produced standards for RS485, RS422, RS232, and RS423 that deal
with data communications. Suggestions are often made to deal with
practical problems that might be encountered in a typical network.
EIA standards where previously marked with the prefix "RS" to
indicate recommended standard; however, the standards are now
generally indicated as "EIA" standards to identify the standards
organization. While the standards bring uniformity to data
communications, many areas are not specifically covered and remain
as "gray areas" for the user to discover (usually during installation) on
his own.

SINGLE-ENDED DATA TRANSMISSION:

Electronic data communications between elements will

generally fall into two broad categories: single-ended and differential.
RS232 (single-ended) was introduced in 1962, and despite rumors for
its early demise, has remained widely used through the industry. The
specification allows for data transmission from one transmitter to one

Page 60 of 84
receiver at relatively slow data rates (up to 20K bits/second) and
short distances (up to 50Ft. @ the maximum data rate).

Independent channels are established for two-way (full-

duplex) communications. The RS232 signals are represented by
voltage levels with respect to a system common (power / logic
ground). The "idle" state (MARK) has the signal level negative with
respect to common, and the "active" state (SPACE) has the signal
level positive with respect to common. RS232 has numerous
handshaking lines (primarily used with modems), and also specifies a
communications protocol. In general if you are not connected to a
modem the handshaking lines can present a lot of problems if not
disabled in software or accounted for in the hardware (loop-back or
pulled-up). RTS (Request to send) does have some utility in certain
applications. RS423 is another single ended specification with
enhanced operation over RS232; however, it has not been widely
used in the industry

DIFFERENTIAL DATA TRANSMISSION:

When communicating at high data rates, or over long distances

in real world environments, single-ended methods are often
inadequate. Differential data transmission (balanced differential
signal) offers superior performance in most applications. Differential
signals can help nullify the effects of ground shifts and induced noise
signals that can appear as common mode voltages on a network.

RS422 (differential) was designed for greater distances and

higher Baud rates than RS232. In its simplest form, a pair of
converters from RS232 to RS422 (and back again) can be used to
form an "RS232 extension cord." Data rates of up to 100K bits /
second and distances up to 4000 Ft. can be accommodated with
RS422. RS422 is also specified for multi-drop (party-line) applications
where only one driver is connected to, and transmits on, a "bus" of up
to 10 receivers.

While a multi-drop "type" application has many desirable

advantages, RS422 devices cannot be used to construct a truly multi-
point network. A true multi-point network consists of multiple drivers
and receivers connected on a single bus, where any node can
transmit or receive data.

"Quasi" multi-drop networks (4-wire) are often constructed using

RS422 devices. These networks are often used in a half-duplex mode,
where a single master in a system sends a command to one of
several "slave" devices on a network. Typically one device (node) is
addressed by the host computer and a response is received from that
device. Systems of this type (4-wire, half-duplex) are often

Page 61 of 84
constructed to avoid "data collision" (bus contention) problems on a
multi-drop network (more about solving this problem on a two-wire
network in a moment).

RS485 meets the requirements for a truly multi-point

communications network, and the standard specifies up to 32 drivers
and 32 receivers on a single (2-wire) bus. With the introduction of
"automatic" repeaters and high-impedance drivers / receivers this
"limitation" can be extended to hundreds (or even thousands) of
nodes on a network. RS485 extends the common mode range for both
drivers and receivers in the "tri-state" mode and with power off. Also,
RS485 drivers are able to withstand "data collisions" (bus contention)
problems and bus fault conditions.

To solve the "data collision" problem often present in multi-drop

networks hardware units (converters, repeaters, micro-processor
controls) can be constructed to remain in a receive mode until they
are ready to transmit data. Single master systems (many other
communications schemes are available) offer a straight forward and
simple means of avoiding "data collisions" in a typical 2-wire, half-
duplex, multi-drop system. The master initiates a communications
request to a "slave node" by addressing that unit. The hardware
detects the start-bit of the transmission and automatically enables
(on the fly) the RS485 transmitter. Once a character is sent the
hardware reverts back into a receive mode in about 1-2 microseconds
(at least with R.E. Smith converters, repeaters, and remote I/O
boards).

Any number of characters can be sent, and the transmitter will

automatically re-trigger with each new character (or in many cases a
"bit-oriented" timing scheme is used in conjunction with network
biasing for fully automatic operation, including any Baud rate and/or
any communications specification, egg. 9600,N,8,1). Once a "slave"
unit is addressed it is able to respond immediately because of the fast
transmitter turn-off time of the automatic device. It is NOT necessary
to introduce long delays in a network to avoid "data collisions."
Because delays are NOT required, networks can be constructed, that
will utilize the data communications bandwidth with up to 100%
through put.

Page 62 of 84
SPECIFICATIONS RS232 RS423 RS422 RS485
SINGLE SINGLE DIFFERENT
DIFFERENTIA
Mode of Operation
-ENDED -ENDED IAL L

Total Number of Drivers and Receivers

1 DRIVER 1 DRIVER 1 DRIVER 32 DRIVER
on One Line (One driver active at a time
1 RECVR 10 RECVR 10 RECVR 32 RECVR
for RS485 networks)

Maximum Cable Length 50 FT. 4000 FT. 4000 FT. 4000 FT.
Maximum Data Rate (40ft. - 4000ft. for 10Mb/s- 10Mb/s-
20kb/s 100kb/s
RS422/RS485) 100Kb/s 100Kb/s
-0.25V to
Maximum Driver Output Voltage +/-25V +/-6V -7V to +12V
+6V
Driver Output Signal +/-5V to +/-
Loaded +/-3.6V +/-2.0V +/-1.5V
Level (Loaded Min.) 15V

Driver Output Signal

Unloaded +/-25V +/-6V +/-6V +/-6V
Level (Unloaded Max)

Driver Load Impedance (Ohms) 3k to 7k >=450 100 54

Max. Driver Current in
Power On N/A N/A N/A +/-100uA
High Z State
Max. Driver Current in +/-6mA @
Power Off +/-100uA +/-100uA +/-100uA
High Z State +/-2v
Slew Rate (Max.) 30V/uS Adjustable N/A N/A
-10V to
Receiver Input Voltage Range +/-15V +/-12V -7V to +12V
+10V
Receiver Input Sensitivity +/-3V +/-200mV +/-200mV +/-200mV
Receiver Input Resistance (Ohms), (1
3k to 7k 4k min. 4k min. >=12k
Standard Load for RS485)

Page 63 of 84
4.4 Housing:

The last area where improvements could be made is the

housing of the modules. The primary focus for the housing was the
Measurement Module. Naturally, due the environmental conditions
that the device would possibly have to withstand, the housing for this
unit was designed to be water resistant and robust. The only problem
was that the housing had to be modified to create an aperture large
enough to allow the sensor to the exposed to the environment. The
group planned to make use of a filter cap, designed to protect the
sensor, and create a seal around the filter cap. Unfortunately,
procurement of the cap was not possible hence this had to be omitted
and instead a water resistant seal was created around the sensor
using silicon. Two other problems relating to the housing are that it
lacks sufficient shock resistance and there is no mounting point. Both
these problems are not particularly difficult to solve. Due to time
constraints, however, these tasks could not be carried
Out.

A further improvement that is imperative be made, is to include

some manner of indicating to the user that the device has been
successfully activated. This would have to be a low power method
such as flashing an LED for a short period. In addition to this a
method of indicating a safe turn off period for the device should be
included as if by chance the device had to be switched off, midway
through a write sequence; it would result in unpredictable behavior of
the EEPROM upon start up.

The Memory Module was designed to emulate the likeness of

the SD or MMC card. The problem is that the device is subject to
damage, if dropped in water, and the data could be corrupted if the
pins of the EEPROM were to be shorted, during a downloading
process. The groups’ solution to this problem is a housing small
enough to hold the EEPROM and PCB, allowing only the male header
pins to protrude from the casing.

5. Sensors:
5.1 Resistance Temperature Detector:

The RTD incorporates pure metals Electrical Resistance-

Temperature Curves or certain alloys that increase in resistance as

Page 64 of 84
temperature increases and, conversely, decrease in resistance as
temperature decreases. RTD act somewhat like an electrical
transducer, converting changes in temperature to voltage signals by
the measurement of resistance. The metals that are best suited for
use as RTD sensors are pure, of uniform quality, stable within a given
range of temperature, and able to give reproducible resistance-
temperature readings. Only a few metals have the properties
necessary for use in RTD elements.

RTD elements are normally constructed of platinum, copper, or

nickel. These metals are best suited for RTD applications because of
their linear resistance-temperature characteristics (as shown in Figure
1), their high coefficient of resistance, and their ability to withstand
repeated temperature cycles

5.2 Strain gauge:

A strain gauge is a bridge formed from four thin-film metal

resistors, arranged so that when the strain gauge is mechanically
deformed the resistors vary as a function of the deformation. Figure
shows a basic interface circuit for a type of transducer. The DAS must
provide a high-accuracy voltage reference signal, often called the
excitation, to bias the bridge. The bridge then provides a differential
voltage signal in response to deformation.

Because the difference voltage is typically very small, on the

order of a few mill volts, and is riding on a much larger common mode
signal, feeding the two inputs directly into a pair of DA card input
channels will result in low-quality measurements. It is preferable to
first subtract off the common mode voltage and amplify the
difference signal to match the input range of the DA card. This can be
accomplished with the use of an instrumentation amplifier, whose
output is then sampled by a single DA card channel.

Page 65 of 84
Figure: A strain gauge produces a small differential signal riding on a
DC offset. An instrumentation amplifier can be used to make this
signal more palatable to a data acquisition card.

5.2 Thermocouple:

Thermocouples (Figure) also provide small differential signals

that generally must be amplified before being processed by an ADC.
Unlike a strain gauge, a thermocouple is self-powered and does not
require a bias voltage source, relying on a junction of two dissimilar
metals to develop a voltage. The temperature at the junction can be
inferred from the voltage developed.

Figure: Parasitic thermocouple junctions interfere with temperature

measurements. Although correction can be done in software,
specialized hardware is available to interface between thermocouples
and data acquisition systems.

Page 66 of 84
 The challenge in interfacing to a thermo-couple is that there
are also unwanted thermocouple junctions at the points where the
thermocouple wires are attached to the DAS. To accurately develop a
temperature measurement from the voltage measured by the DAS, it
is necessary to monitor the temperature at the point of wire
attachment, and compensate the readings for this temperature. While
it is possible to do all the necessary corrections in software in the
host, thermocouples are sufficiently ubiquitous so as to justify special
single-chip amplification and processing circuits to handle all the
details of calibration and correction.

Page 67 of 84
6. Software of Data Logger:

We use the special soft ware to down load the data from the
data logger EEPROM. On using the RS232 port we can connect port to
the computer, we can easily down load the data from the data logger.
Here we are using the 16 channel data logger soft ware to down load
the data. This soft ware has saved on the program files of the system.

When the data logger is connected to the computer then the system
shows the following diagram when communication between both
devices is not ok. The communication status button on the screen
shows FAIL in red color as shown in the figure,

Page 68 of 84
 When the data logger is connected to the computer then the
system shows the following diagram when communication between
both devices is ok. The communication status button on the screen
shows OK in green color as shown in the figure.

To down load the data from the data logger we can select the
DOWNLOAD LOG button in soft ware from the above screen we can
get the options &we have to enter the password to down load the
data.

Page 69 of 84
After enter the password it will shows the total no. of logged records
and now it will ask us to save the logged data in the log data folder
which was in the program files. And the saved data will be in the ldf
format, it will be opened with the help of the Microsoft Excel. The
diagrams for the above process as shown below:

Page 70 of 84
Page 71 of 84
 When we connect the sensors to the data logger in online mode
then we may also having the graphical representation of the data
which is similar to as shown below. Here temperature is taken along
y-axis and time is taken along X-axis.

Page 72 of 84
Page 73 of 84
When we are going to take the online data we may have to set the
print settings. These settings are done on using the print settings
button on the main menu. On that time the screen displays as shown
below.

Page 74 of 84
 Data loggers are available with different type of
configurations. For different type of data loggers they have different
type of baud rate settings, soft ware settings& configuration settings.
These settings are done with the help of the configuration settings
button. On using this mode we may have display as shown below.

Page 75 of 84
 7. Example of logged data of stability chamber:

The mapping procedure serves to check the Walk in Humidity

Chamber functioning with the specifications given by the manufacturer. The
Walk in Humidity Chamber is mainly used for storing different samples under
the set temperature & RH 25°C(± 2°C); 60 RH %(± 5% RH). So, the Walk In
Humidity Chamber should maintain the set (required) temperature & RH and
the distribution throughout the Walk In Humidity chamber should be uniform
(within the limits of tolerances specified by the manufacturer) so that the
samples kept in any part of the Walk in Humidity chamber will also have the
same temperature & RH.

Our aim is to check whether the temperature & RH

distribution in the Walk in Humidity chamber is uniform (within the
limits specified by the manufacturer) or not. According to the
manufacturer the Chamber temperature & RH is different at each
position inside the chamber. The set temperature & RH represents the
temperature & RH at center of the inside Walk in Humidity chamber.

Here we can collect the data with every ten minutes

Interval and we are given the data of six hours of the stability
chamber.

Page 76 of 84
7.1 Materials Used:

Equipment Details : Digital Data logger

Make : Ace Instruments

Model : AI1600D

Temperature Range : -100 0C to 1200 0C

Accuracy : ± 0.1% FS

Resolution : ± 0.1 0C

Calibration Standard : Universal Calibrator

Serial No : 991556864

Sensors used : RH Transmitters

Power supply for

RH Transmitters : 24V

Arrange the RH transmitters as shown in figure. Arrange connections

to the data logger. Program settings have to be done for the data
logger according to the specifications. On the screen of the data
logger we may watch how many channels are connected. And the
specific channel shows the reading at that point.

Page 77 of 84
7.2 Sensor position in stability chamber:

7.3 Data:

Page 78 of 84
ELEGANT ANALYTICAL
SERVICES

Instrument Name : Walk in Humidity

Chamber
Instrument ID No : QC-150
Make : Newtronic
Set Temperature& R.H% : 25(+/-2)°C & 60(+/-5)%

Date Time T-1 RH%-1 T-2 RH%-2 T-3 RH%-3 T-4 RH%-4 T-5 RH%-5
09-03-2009 11:30:20 25.5 61.3 24.9 60.5 26.1 60.2 24.8 62.4 24.6 60.7
09-03-2009 11:40:20 24.6 60.5 25.3 61.1 26.5 60.8 24.6 60.5 24.0 60.4
09-03-2009 11:50:20 24.3 61.4 25.7 60.0 26.2 61.3 26.5 61.1 24.5 59.9
09-03-2009 12:00:20 25.0 62.4 25.5 61.4 25.8 59.0 25.1 60.0 24.3 59.5
09-03-2009 12:10:20 24.1 62.1 24.6 62.4 25.4 59.7 24.8 61.4 25.0 60.2
09-03-2009 12:20:20 24.8 61.6 24.3 62.1 25.3 60.0 25.4 62.4 24.1 60.8
09-03-2009 12:30:20 24.6 60.7 25.0 61.8 25.0 60.2 25.4 62.1 24.8 61.3
09-03-2009 12:40:20 26.5 60.4 24.9 61.5 24.9 62.1 25.9 61.8 24.6 59.2
09-03-2009 12:50:20 25.1 59.9 24.6 61.2 24.6 63.5 24.5 61.5 25.4 59.4
09-03-2009 13:00:20 24.8 59.5 25.8 60.9 24.2 61.9 26.1 62.4 25.6 59.0
09-03-2009 13:10:20 25.4 60.2 26.5 62.8 25.4 63.1 26.5 62.1 25.7 59.7
09-03-2009 13:20:20 25.4 60.8 25.1 63.2 25.1 62.8 26.2 61.8 25.2 60.0
09-03-2009 13:30:20 25.9 61.3 24.8 63.3 25.6 60.8 25.8 60.9 24.2 60.2
09-03-2009 13:40:20 24.5 59.2 25.4 63.5 25.3 61.3 25.4 60.5 26.2 60.0
09-03-2009 13:50:20 24.9 59.4 25.5 63.6 26.1 59.2 25.3 59.8 25.8 62.2
09-03-2009 14:00:20 25.0 59.0 24.2 61.4 25.9 63.5 25.0 59.5 25.4 62.4
09-03-2009 14:10:20 25.6 59.7 25.7 62.4 26.3 60.0 24.2 63.4 24.2 61.8
09-03-2009 14:20:20 25.4 60.0 25.2 62.1 26.4 60.2 24.3 62.7 26.2 60.5
09-03-2009 14:30:20 24.8 60.2 25.4 61.8 24.7 62.1 25.5 62.1 25.1 61.5
09-03-2009 14:40:20 26.3 60.0 25.3 61.5 25.1 61.3 24.6 62.4 24.8 62.4
09-03-2009 14:50:20 25.2 62.2 25.7 62.4 26.1 60.5 24.3 60.5 25.4 62.1
09-03-2009 15:00:20 24.3 62.4 25.9 62.8 26.0 61.4 24.6 61.1 25.4 61.8
09-03-2009 15:10:20 25.0 61.8 25.2 62.1 25.8 62.4 25.4 60.0 24.8 61.5
09-03-2009 15:20:20 24.1 61.5 24.2 61.6 25.1 62.1 25.6 61.5 26.3 61.2
09-03-2009 15:30:20 24.8 61.3 26.2 60.7 24.7 61.6 25.7 60.3 25.2 60.9
09-03-2009 15:40:20 24.6 61.0 25.8 60.4 24.1 60.7 25.2 61.0 24.3 62.0
09-03-2009 15:50:20 25.4 60.9 24.1 59.9 24.8 60.4 24.2 63.5 25.0 61.5
09-03-2009 16:00:20 25.0 60.5 24.8 59.5 24.6 59.9 26.2 62.5 24.1 62.7
09-03-2009 16:10:20 24.1 60.7 24.6 60.7 26.5 59.5 25.8 62.0 24.8 62.1
09-03-2009 16:20:20 24.8 60.4 25.4 60.4 25.1 60.2 25.4 61.5 24.6 62.4
09-03-2009 16:30:20 24.6 59.9 25.6 60.6 24.8 60.8 25.3 61.2 25.4 60.5

ELEGANT ANALYTICAL
SERVICES

Page 79 of 84
 Instrument Name : Walk in Humidity
Chamber
Instrument ID No : QC-150
Make : Newtronic
Set Temperature& R.H% : 25(+/-2)°C & 60(+/-5)%

Date Time T-6 RH%-6 T-7 RH%-7 T-8 RH%-8 T-9 RH%-9 CH-9 CH-10
09-03-2009 18:40:25 24.3 61.4 24.9 60.5 26.5 60.2 25.5 62.4 Open Open
09-03-2009 18:50:25 25.0 62.4 24.6 61.1 25.1 60.8 25.1 60.5 Open Open
09-03-2009 19:00:25 24.1 62.1 24.0 60.0 24.8 61.3 24.9 61.1 Open Open
09-03-2009 19:10:25 24.8 61.6 24.5 61.4 25.4 59.0 24.6 60.0 Open Open
09-03-2009 19:20:25 24.6 60.7 24.3 62.4 26.1 59.7 24.0 61.4 Open Open
09-03-2009 19:30:25 26.5 60.4 25.0 62.1 26.3 60.0 24.5 62.4 Open Open
09-03-2009 19:40:25 25.1 59.9 24.1 61.8 26.5 60.2 24.3 62.1 Open Open
09-03-2009 19:50:25 24.8 59.5 24.8 61.5 26.1 62.1 25.0 61.8 Open Open
09-03-2009 20:00:25 25.4 60.2 24.6 61.2 25.9 63.5 24.1 61.5 Open Open
09-03-2009 20:10:25 25.4 60.8 25.4 60.9 26.3 61.9 24.8 61.2 Open Open
09-03-2009 20:20:25 25.9 61.3 25.6 62.0 26.4 63.1 24.6 60.9 Open Open
09-03-2009 20:30:25 24.5 59.2 25.7 61.5 24.7 62.8 25.4 62.0 Open Open
09-03-2009 20:40:25 26.1 59.4 25.2 62.7 25.1 60.8 25.6 61.5 Open Open
09-03-2009 20:50:25 25.4 59.7 24.8 61.4 25.0 60.2 25.7 63.5 Open Open
09-03-2009 21:00:25 25.3 60.0 25.4 62.4 24.1 60.8 25.2 59.5 Open Open
09-03-2009 21:10:25 25.0 60.2 25.4 62.1 24.8 61.3 24.6 60.7 Open Open
09-03-2009 21:20:25 24.9 62.1 25.9 61.8 24.6 59.2 24.3 60.4 Open Open
09-03-2009 21:30:25 24.6 63.5 24.5 61.5 25.4 59.4 25.0 59.9 Open Open
09-03-2009 21:40:25 24.2 61.9 26.1 62.4 25.6 59.0 24.9 59.2 Open Open
09-03-2009 21:50:25 25.4 63.1 26.5 62.1 25.7 59.7 24.6 59.4 Open Open
09-03-2009 22:00:25 25.1 62.8 26.2 61.8 25.2 60.0 25.8 59.0 Open Open
09-03-2009 22:10:25 25.6 60.8 25.8 60.9 24.2 60.2 26.5 59.7 Open Open
09-03-2009 22:20:25 25.3 61.3 25.4 60.5 26.2 60.0 25.1 60.0 Open Open
09-03-2009 22:30:25 26.1 59.2 25.3 59.8 25.8 62.2 24.8 60.2 Open Open
09-03-2009 22:40:25 25.9 63.5 25.0 59.5 25.4 62.4 25.4 60.0 Open Open
09-03-2009 22:50:25 26.3 60.0 24.2 63.4 24.2 61.8 25.5 62.2 Open Open
09-03-2009 23:00:25 24.5 59.2 25.7 61.5 24.7 62.8 24.3 61.0 Open Open
09-03-2009 23:10:25 26.1 59.4 25.2 62.7 25.1 60.8 25.5 61.5 Open Open
09-03-2009 23:20:25 25.4 59.7 24.8 61.4 25.0 60.2 24.6 62.4 Open Open
09-03-2009 23:30:25 25.3 60.0 25.4 62.4 24.1 60.8 24.3 62.1 Open Open
09-03-2009 23:40:25 25.0 60.2 25.4 62.1 24.8 61.3 24.6 61.8 Open Open

Page 80 of 84
8. Data logger Technical Specifications:

MAX MIN NORMAL FULL SCALE

RTD PT-100(3 WIRE) -199.9°c 400.0°c 0.1 +/-0.25%
RTD(Cu-53) -50.0°c 150.0°c 0.1 +/-0.25%
J-Type(Fe-CON) -50.0°c 600.0°c 0.1 +/-0.25%
K-Type(Cr-Al) -50.0°c 500.0°c 0.1 +/-0.25%
K-Type(Cr-Al) -100.0°c 1300.0°c 1 +/-0.25%
R-Type(pt-13%Rh/PT) 0°c 1750.0°c 1 +/-0.25%
S-Type(PT-13%Rh/PT) -200.0°c 400.0°c 0.1 +/-0.25%
T-Type, E-Type(Cu/CON) 0°c 1300.0°c 1 +/-0.25%
B-Type(PT6%Rh/PT30%Rh) 400°c 1820.0°c 1 +/-0.25%
4to 20 ma/0 to 20 ma -9999 15000 Programmable by +/-0.25%
user
Voltage(0to1VDC/oto10VDC) -9999 15000 Programmable by +/-0.25%
user

Supply : 230 VAC +/-10%, 50HZ, 24VDC or 12VDC

Memory : Max.2995 reading storing capacity.

Logging Interval: 1to9999 sec. programmable by user

Control Action : High& Very high, High & low& very low
Programmable.

Optional : 1).RS-232/RS-485 serial port with MODBUS RTU

Protocol output for PC interface.
2).Parallel port foe direct print out on 80/132 column
Dot matrix, DeskJet & laser printer without need of
PC.
3).Individual relay O/P can be given for each channel
or with grouping output.
4).DATALOG windows based data acquisition
software for real time graph, history data.

Weight : 2.05kg

Scan time : Channel scan time 1to 59sec.Field programmable by

User.

Page 81 of 84
9. Applications of the data logger:

a. ISO certification records validation process certifying.

b. Pharmaceutical process validation with graph& excel report.
c. Online profile recording for oven &BOD, incubator, Humidity
chamber.
d. To know heat profile in furnaces, foundries for heat treatment
application.
e. Chemical & Hazardous area where data monitoring is essential.
f. Iron & steel industry for soaking pits oxygen plate, smelter
plant.
g. Cement plants for process automation.
h. Water purification & Treatment plants.
i. Primary & auxiliary temperature scanning of boilers.
j. Pulp& paper industry for washers, head box feed, bleachers etc.
k. Chemical & petro chemical industries.
l. Water pumping stations.
m. Power plants.

Data loggers find applications in almost every field where the

temperature monitoring or parameter plays an important role,
1. In chemical process, data loggers can keep track of all the
vital points, where temperature is a very significant factor. They can
scan the temperature at 16 or 64 different ( depending upon the
model ) places. At some point, it may be critical that the temperature
should be maintained below certain limits. If the temperature exceeds
the limits, this can lead to dangerous explosions. Data loggers can be
set for safe limits, lower as well as upper limits. In case either of the
limits, this will give an alarm and caution the operator. One can have
a complete record of the process during one shift of for 24 hours as
the hard copy of the readings of the parameter ( with respect to
time ) is made available which may extremely useful for the manager
or the supervisor and even for analyzing in future.

2. Data loggers can monitor temperature of winding of high HP

motors and high voltage transformers.

3. The bearing temperatures of motors and pumps used in

continuous processes such as hard water plants for automatic energy,
and atomic reactors can also be monitored.

4. The data logger can also monitor voltage, current and other
parameters like pressure, flow, relative humidity, etc. In short, the
data logger will have a complete supervisory control on the process
and act as a link between operator and management.

Page 82 of 84
10. Conclusion:

The fundamental objective of the design was to create a system that

could take temperature and humidity measurements for a period of 6 months
and store all this data till such time that it is needed. This objective was
successfully achieved within the low power consumption condition. The desired
accuracy, for temperature measurements, were also achieved and validated by
comparing the measured temperature results to a calibrated digital
thermometer. The group also tested the ability of the system to measure
humidity. However, the hygrometer used, as an independent means of
comparing system readings, was unfortunately not very accurate. The
hygrometer readings were thus used as a rough estimate of humidity and it was
ensured that the system readings were approximately the same.

The main change in operation of the Measurement Unit was with regard
to the Time Stamping Method employed. It was decided that rather than taking
only an initial base time stamp and incrementing this based on the number of a
sample, a time stamp would be taken every 8 hours. This change was effected
in order to eliminate the risk of losing 6 months worth of data, which was a
threat that the initial method posed.

The PCI module which is responsible for the downloading and processing
of stored data was successfully designed, constructed and tested. The design
was achieved with a degree of user friendliness and provides hassle free
operation. Added technical support is provided by way of user manuals and help
files. However, methods of further simplifying this process do exist but due to a
lack of sufficient time these methods could not be implemented.

The design was achieved using a modular design approach which

optimized the efficiency of the system, increased its versatility as well
significantly aided in troubleshooting during the prototyping stage.

The main expense in the design is the sensor that was implemented.
However, it was decided that this expenditure was worth cost to ensure low
power consumption and dependability in the environments that the device
would be exposed to.

The product has been designed with the potential user always in mind.
Thus a versatile cost effective and off course user friendly system with a high
level of robustness has been achieved. Further the group has evaluated the
potential flaws in the design and given the time for further development the
group is confident that a market ready product can be achieved.

Page 83 of 84
References:

Books & websites referred to consolidate this project report

1. Design of a Data Logger (Phase 3 Report) - Corresponding Author:

Muhammad Simjee

2. Ace Instruments-Hyderabad

3. “Choosing an RTD, Thermocouple or Thermister” www.dataloggerstore.com.

4. Atmel Corporation- “Interfacing AT24CXX Serial EPROM’s with AT89CX051

Microcontrollers”, www.atmel.com

5. www.scribd.com.

6. DOE FUNDAMENTALS HANDBOOK INSTRUMENTATION AND CONTROL by U.S

Department of Energy (DOE).

Page 84 of 84